Are 47-day certificates in force now?

No. The current maximum is 200 days, in force since 15 March 2026. It drops to 100 days on 15 March 2027 and to 47 days on 15 March 2029. Any vendor email telling you that 47 days requires action today is overstating it — though the inventory work it would take genuinely does take that long.

Do my existing certificates get revoked?

No. Every certificate stays valid until its own expiry date. The limits apply to certificates issued on or after each date, so the change reaches you at your next renewal rather than all at once.

Does this affect self-signed or internal CA certificates?

No. SC-081v3 and the Chrome Root Program apply to publicly trusted certificates. Private CAs set their own lifetimes, which is a large part of why the clientAuth change pushes mutual TLS towards private CAs.

How do I know whether a certificate carries clientAuth?

It is in the extended key usage extension of the certificate itself, so it can be read from outside without access to the server. If an integration authenticates with a certificate and that certificate came from a public CA, assume it is affected and check.

Why does shorter domain validation reuse matter more than shorter certificates?

Because renewal is already automated for most people and revalidation often is not. From 2029 a 47-day certificate outlives its 10-day validation, so almost every renewal needs a fresh DNS or HTTP check — and those fail for DNS reasons, weeks after whoever made the DNS change has forgotten about it.

Does AstraVerify renew certificates for me?

No, and that is deliberate. We check from outside with no credentials and tell you what changed: which hosts present certificates, which ones stopped renewing on their usual cadence, and which DNS or redirect changes are likely to break a future validation. Renewal itself belongs to your ACME client or certificate lifecycle tool.

47-day TLS certificates: the dates, and what actually breaks

If you run anything on the internet you have probably had the email by now. Salesforce sent one on 29 October 2026; AWS, Google, Microsoft, Cloudflare and most CAs have sent their own versions. They all describe the same industry change, usually in the same urgent register, and they rarely separate the part that is already true from the part that is three years out.

The change is real and the dates are fixed. This page is the schedule, the two companion changes that get less attention, and an honest account of which of your hosts will break first — which is almost never the one you are thinking of.

The schedule, in one table

In April 2025 the CA/Browser Forum passed ballot SC-081v3, proposed by Apple and carried 29 to 0. It cuts two things on the same timetable: how long a publicly trusted TLS certificate may be valid, and how long a certificate authority may reuse an existing domain control validation before it has to check again.

Both columns matter, and the second one is the one most summaries leave out.

SC-081v3: maximum certificate lifetime and domain validation reuse
From	Max certificate lifetime	Max validation reuse
Before 15 March 2026	398 days	398 days
15 March 2026 (in force now)	200 days	200 days
15 March 2027	100 days	100 days
15 March 2029	47 days	10 days

The change under the change: validation expires before the certificate

Read the last row again. From March 2029 a certificate lasts 47 days and the validation behind it lasts 10. The arithmetic is the whole story: your CA can no longer reuse the proof that you control the domain, so nearly every renewal needs a fresh domain control check — a DNS TXT record it can read, or an HTTP path it can fetch.

That moves the failure mode. Today a certificate problem is usually "nobody renewed it". From 2029 it is usually "the renewal ran and the validation failed", and validation fails for reasons that have nothing to do with certificates: a DNS record edited during an unrelated migration, a CAA record added by someone tightening security, a wildcard redirect that swallows the /.well-known/acme-challenge/ path, a DNS provider change that silently dropped a TXT record nobody could see the purpose of.

If you are planning for this, plan for DNS and redirect stability, not for certificate paperwork. The certificate is the symptom.

The second notice: dual-use certificates, and why it is not about your website

The same ballot, together with the Chrome Root Program policy, ends the practice of issuing one publicly trusted certificate carrying both serverAuth and clientAuth extended key usages. No newly disclosed intermediate CA may carry both from 15 June 2026, and no newly issued public TLS leaf certificate may carry clientAuth from 15 March 2027.

This one is widely misread, so be precise about who it affects. If you use certificates the ordinary way — a public certificate on a web server, visitors connecting to it — nothing here touches you. It affects you only if somewhere you have taken a public TLS certificate and used it as a client credential: mutual TLS to a partner API, a payment gateway, an EDI link, a Salesforce or MuleSoft integration that authenticates with a certificate you also serve on a website.

Certificates already issued keep working until they expire. The break happens at renewal, when the replacement comes back without clientAuth and the mTLS handshake that depended on it stops. Private and self-signed certificates are unaffected, and for most mTLS the right answer is a private CA rather than a public one — which is what this change is pushing people towards.

Root certificates and trust stores

The third item in most of these notices is about the other direction: not the certificate you present, but the ones you trust. Large platforms are reserving the right to rotate between root certificate authorities, or to serve chains from several at once, without individual notice.

For anything that connects outbound from your own servers, that means your trust store has to carry the full public root set rather than a handful of roots someone pinned years ago. Pinned roots and hand-curated trust stores are where this bites, and they tend to live in the oldest, least-documented integration you have.

What actually breaks first, and it is not the main site

Your main website will be fine. It is behind a CDN or a platform that renews automatically, somebody would notice within minutes, and it has been renewing itself for years.

What breaks is the host nobody owns. The load balancer configured in 2021 by someone who has left. The mail host whose certificate is managed separately from the web one. The api. or vpn. or legacy. subdomain that was set up manually because the automation did not cover it. The vendor-hosted microsite on your domain. A certificate lifecycle tool inventories what it manages; by definition it cannot tell you about the host it was never pointed at.

At 398-day certificates an unmanaged host is a once-a-year scramble that someone remembers. At 47 days it is eight outages a year. The transition does not create these hosts — it just stops letting you get away with them.

What to do, in order

Inventory first, automate second. List every hostname on your domain that presents a certificate — web, mail, API, VPN, admin, vendor-hosted — and mark which ones a renewal tool actually manages. The gap between those two lists is your exposure, and it is the only step you cannot skip.
Check for clientAuth. If any integration authenticates with a certificate rather than a key or a token, find out whether that certificate is publicly trusted. If it is, plan to move it to a private CA before March 2027.
Treat DNS as part of the certificate system. Once validation reuse drops, a DNS change can take out a renewal weeks later with no obvious connection between the two. Whoever can edit DNS needs to know that.
Stop hand-curating trust stores. Use the platform root set and let it update.
Then automate renewal. ACME everywhere it fits. This is the step every vendor email leads with, and it is the one that works only after the first step is done — automation cannot renew a certificate on a host it has never heard of.

Where AstraVerify fits, and where it does not

We do not issue, rotate or manage certificates, and we are not going to. Renewal automation means holding keys and standing in the critical path of your TLS, and an outage we caused would be an outage of your business. ACME clients and certificate lifecycle platforms do that job and do it well.

What we do is the outside-in half, with no credentials and no agent: we check your domain the way a stranger does, every day, and tell you when something changed. For this transition that is worth exactly three things.

The inventory, from outside. Every host under your domain presenting a certificate, including the ones your renewal tool has never been pointed at — which is the one list a tool working from its own inventory cannot produce.
Renewal that silently did not happen. We already watch certificate expiry and alert on change. A host that rolled every sixty days and has not rolled in ninety is a failing automation, and it is visible from outside long before the certificate expires.
The DNS changes that break validation later. We already alert within a day on DNS records, redirects and crawler access changing. As validation reuse shortens, those are the changes that quietly cost you a renewal, and the alert you want is the one that fires when the record changes — not six weeks later when the handshake fails.

Frequently asked questions

Are 47-day certificates in force now?: No. The current maximum is 200 days, in force since 15 March 2026. It drops to 100 days on 15 March 2027 and to 47 days on 15 March 2029. Any vendor email telling you that 47 days requires action today is overstating it — though the inventory work it would take genuinely does take that long.
Do my existing certificates get revoked?: No. Every certificate stays valid until its own expiry date. The limits apply to certificates issued on or after each date, so the change reaches you at your next renewal rather than all at once.
Does this affect self-signed or internal CA certificates?: No. SC-081v3 and the Chrome Root Program apply to publicly trusted certificates. Private CAs set their own lifetimes, which is a large part of why the clientAuth change pushes mutual TLS towards private CAs.
How do I know whether a certificate carries clientAuth?: It is in the extended key usage extension of the certificate itself, so it can be read from outside without access to the server. If an integration authenticates with a certificate and that certificate came from a public CA, assume it is affected and check.
Why does shorter domain validation reuse matter more than shorter certificates?: Because renewal is already automated for most people and revalidation often is not. From 2029 a 47-day certificate outlives its 10-day validation, so almost every renewal needs a fresh DNS or HTTP check — and those fail for DNS reasons, weeks after whoever made the DNS change has forgotten about it.
Does AstraVerify renew certificates for me?: No, and that is deliberate. We check from outside with no credentials and tell you what changed: which hosts present certificates, which ones stopped renewing on their usual cadence, and which DNS or redirect changes are likely to break a future validation. Renewal itself belongs to your ACME client or certificate lifecycle tool.

Check your own domain. The scan shows your live records, a score out of 100 and the exact record to publish for each fix.