Public TLS certificates are now capped at 200 days: what changed in 2026

From 15 March 2026, a newly issued publicly trusted TLS subscriber certificate may be valid for at most 200 days. That sentence is the whole policy change. It is not a rumour, and it is not “certificates are now 200 days for everyone.”

Certificates issued before that date keep the notAfter they were given. A 90-day Let’s Encrypt leaf issued on 14 March 2026 still expires 90 days later. A 398-day commercial leaf issued in 2025 is not rewritten. The cap applies to new issuance.

Validation data reuse also moved. CA/Browser Forum Baseline Requirements §4.2.1 shrinks how long a CA may reuse domain and IP validation: 200 days from 15 March 2026, 100 days from 15 March 2027, and 10 days from 15 March 2029. Short-lived subscriber certificates are a separate definition (at most 7 days from 15 March 2026).

What this means operationally:

• Calendar reminders were already a weak control. They are weaker now.
• A renewal job that only talks to a CA is incomplete if production still serves the previous leaf.
• Teams that issued 397-day certificates as a habit must change the issuance request, not just the wiki.
• Inventory must name every hostname that terminates TLS, including customer-owned SaaS names.

Issued ≠ installed ≠ served

A CA can return 200 and a PEM while port 443 still presents the previous fingerprint. Treat deploy verification as a required stage, not an optional extra.

Timeline (subscriber certificate maximum validity for new public issuance):

• 15 March 2026 — 200 days
• 15 March 2027 — 100 days
• 15 March 2029 — 47 days

sslcertificates.io schedules auto-renew from next_renewal_at, default 30 days before notAfter. That default is a platform setting, not a CA/B number. Do not tell an auditor you are “already on 47-day certificates” unless you chose that lifetime.

Sources: CA/Browser Forum TLS Baseline Requirements. Fact-checked 21 September 2026.