Are people starting to wake up to shorter TLS certificates?
A certificate issued at the new 200-day maximum on 15 March is due to expire around 1 October. This is the first time some teams are doing a renewal job they used to do once a year twice in the same year. If that job still ends with somebody copying a PEM file to HAProxy or IIS, the awkward part is happening now.
Sectigo called out this first renewal wave on 23 September. Its list of likely gaps is familiar: incomplete inventory, unclear ownership, manual domain control validation (DCV), and no automated route from issuance to installation. The warning is useful, but the certificate on your listener is a better test.
The next date is 15 March 2027
CA/Browser Forum ballot SC-081v3 set the maximum validity for newly issued publicly trusted TLS certificates at 200 days from 15 March 2026, 100 days from 15 March 2027, and 47 days from 15 March 2029. The limits apply to new issuance; an existing certificate does not suddenly lose its original expiry date. The ballot also reduces how long a CA can reuse validation data. Your private PKI has its own policy.
For a name that needs continuous coverage, those maximum lifetimes mean roughly two, four, then eight issuance cycles per year, before allowing for an early renewal margin. That is why a calendar reminder is a poor plan for the 100-day step. A successful ACME order is only one part of the work. You still need to know who owns the name, whether DCV can run again, where the new certificate and key go, whether the service reloads, and what the public listener actually presents afterward.
Try this on one real endpoint this week: compare the certificate fingerprint in your inventory with the fingerprint served over TLS. If they differ, find the delivery step that failed. If nobody can name the owner or renewal path, that is the issue to fix before March.
Meanwhile, the certificate format is moving
There is a second change underway. Google's Chrome team is developing Merkle Tree Certificates (MTCs) with other WebPKI operators. The idea is to put issued certificates in a public Merkle tree, sign a tree checkpoint, and let a client verify a compact inclusion proof. It avoids carrying a chain of large post-quantum signatures in every TLS handshake. MTCs remain an IETF work in progress; they are a proposed form of X.509 certificate, not a general replacement available to every browser and server today.
Cloudflare's 29 September update says it is building a CA that will support classical certificates and MTCs, targeting early 2027 for inclusion in Chrome's quantum-resistant root program. Its Chrome experiment served MTCs to real traffic, but used a bootstrap CA backed by traditional certificate chains. Let's Encrypt is also developing MTC support and targets a production-ready environment in 2027. Sectigo's recent MTC article makes the same operational point: the format is still developing, while the need for automation and visibility is already here.
The 100-day rule and MTCs are separate changes. The former is an adopted validity limit for public TLS issuance. The latter is an emerging way to make post-quantum authentication workable at WebPKI scale. Both put more pressure on the same renewal, delivery, and verification path.
What we have actually done with TrustAsia
In August, we ran CertLocker against TrustAsia's MTC interoperability staging environment. A CertLocker ACME workflow using TrustAsia's mtc-47d profile reached Certificate Issued, waited for the landmark, then reached Landmark Issued and Complete for mtc.certlocker.dev. The workflow record shows both issuance steps and links to the resulting certificate records.
That is a real interoperability pilot on a staging CA. It is not a claim that CertLocker is a public CA, that TrustAsia staging certificates have general browser trust, or that an MTC badge makes the whole TLS connection quantum safe. We built the pieces an operator will need: ACME profile selection, paired standalone and landmark certificate records, inventory metadata, and probes that can recognise an MTC presented by a live endpoint. The issuer creates the MTC; CertLocker manages the workflow and the resulting assets.
We started this work before the latest Cloudflare announcement. That gives us useful hands-on experience with the less glamorous questions: what happens while the landmark is pending, how the two records stay linked, and how an operator checks what the listener serves. We still have to follow the final standard and browser rollout as they change.
A practical check for this quarter
- Reconcile public certificate inventory against live listeners, including HAProxy, IIS, supplier portals, and anything behind a load balancer.
- Give each name an owner and a repeatable DCV path. Test the path, including expired authorization and failed DNS updates.
- Automate issuance and delivery, then confirm the service presents the new certificate. Keep an alert for a failed probe or a fingerprint mismatch.
- Run one renewal as though the certificate had 100 days of validity. Measure every manual handoff.
- Track MTC pilots separately from production trust. Keep classical certificate delivery working while browsers and CAs build out support.
If you want to walk through one of your renewal paths with us, arrange a face-to-face meeting or video call. We can show the hosted CertLocker workflow, including the TrustAsia staging pilot, and look at where issuance, delivery, or verification currently needs a person.