# 200-day TLS certificate limit in force since 15 March 2026

> From 2026-03-15 publicly trusted TLS certificates are capped at 200 days and domain validation reuse at 200 days. Next step: 100 days in March 2027.

Source: https://ssl.sh/news/200-day-certificate-limit-in-effect/
Last updated: 2026-11-10

Since 15 March 2026, newly issued publicly trusted TLS certificates are valid for at most 200 days, down from 398. The period in which a CA may reuse an earlier domain validation fell to 200 days on the same date. Certificates issued before the cutoff run to their original expiry date.

## What happened

The change comes from [Ballot SC-081v3](https://ssl.sh/news/ballot-sc-081-shorter-certificate-lifetimes/), adopted in April 2025, which wrote a stepped schedule into the [Baseline Requirements](https://ssl.sh/glossary/baseline-requirements/). As of November 2026 the 200-day maximum applies to every new certificate from every publicly trusted CA, whatever the product is called and however long the subscription runs.

Two numbers changed on 15 March 2026:

- maximum [validity period](https://ssl.sh/glossary/validity-period/): 200 days, previously 398;
- reuse of [domain control validation](https://ssl.sh/glossary/dcv/): 200 days, previously 398.

A second rule tightened on the same date. Ballot SC-063 defines a [short-lived certificate](https://ssl.sh/glossary/short-lived-certificate/) and exempts it from carrying [OCSP](https://ssl.sh/glossary/ocsp/) or [CRL](https://ssl.sh/glossary/crl/) revocation information. For certificates issued from 15 March 2026, short-lived means valid for 7 days or less; before that the threshold was 10 days. Let's Encrypt's [six-day certificates](https://ssl.sh/news/lets-encrypt-six-day-and-ip-certificates/) fit within the new definition.

The next scheduled step is 100 days for certificates issued on or after 15 March 2027 (upcoming), followed by 47 days from 15 March 2029.

## Who is affected

The change hits organisations that buy certificates once a year and install them by hand. A one-year subscription can no longer be covered by one certificate, so each term needs at least one reissue and redeployment. Appliances, older load balancers and hosting panels that only accept manual uploads are the usual weak points, as are certificates that were installed by someone who has since left.

Domain validation is the less visible change. A domain that was validated once in 2025 can no longer back new certificates for a full year, so organisations that pre-validate domains through a CA portal may be asked to validate again sooner than they expect.

[ACME](https://ssl.sh/glossary/acme/) users are mostly unaffected for now: 90-day Let's Encrypt certificates were already well under 200 days, and ACME clients validate on every order anyway.

## What you should do

Find every certificate that still renews by hand and automate it before the 100-day step in 2027. Start by checking the lifetime of a recently issued certificate:

```bash
openssl x509 -in cert.pem -noout -startdate -enddate
```

Check whether a live site expires within the next 30 days (exit code 1 means it does):

```bash
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -checkend 2592000
```

Then:

- List every certificate that will need replacing within the next 200 days and make sure each has an owner and a renewal path.
- Treat 200 days as the rehearsal for 100 days in 2027: if a renewal still needs a person to log in and upload files, [automate it](https://ssl.sh/learn/automate-certificate-renewal/) now.
- Use the [bulk SSL checker](https://ssl.sh/tools/bulk-ssl-checker/) to audit many hosts at once and the [validity calculator](https://ssl.sh/tools/validity-calculator/) to see the maximum lifetime for any issuance date. The full schedule is on the [certificate validity timeline](https://ssl.sh/timeline/certificate-validity/).