Your certificates expire on the earliest date in their chain

A certificate stops working on the earliest expiry date anywhere in its chain, which is often not its own. In our lab, two leaf certificates with 25 days left failed verification one second after the intermediate CA above them expired.

A leaf fails on its CA's date

We built a small private hierarchy: a root valid for ten years, an intermediate valid for five days, and two leaf certificates valid for thirty. While the intermediate was valid, both leaves verified. We then moved the validation clock to one second past the intermediate's expiry, and both leaves failed with the same line.

error 10 at 1 depth lookup: certificate has expired

Depth 1 is the intermediate. Each leaf's own notAfter was still about 25 days away, and the root verified fine at the same clock, so the failure came from the intermediate and nothing else (2026-09-06-p3-ca-expiry).

So a leaf's effective expiry is the minimum of its own notAfter and every notAfter above it. A renewal calendar built from leaf dates schedules the work for the wrong day. In this run it would have found the outage 25 days after it started.

The lead time is set by the CA

Renewing a leaf is quick. Replacing a CA means a new hierarchy, the new trust distributed to every client that relies on the old one, and every leaf reissued under it. We didn't rehearse that part, but its shape is why a private root needs months of warning, and why "the leaves renew automatically" doesn't cover it. An ACME client renews leaves. Nothing renews the CA it chains to.

You can test this today without waiting for anything to expire. openssl verify takes an -attime flag, so you can ask whether a chain will still verify on any future date.

openssl verify -CAfile root.crt -untrusted intermediate.crt -attime <epoch> leaf.crt

Set <epoch> one second past each CA certificate's expiry and run it against a leaf. If it fails, that's the date your estate stops working.

A broken chain hides the expiry

The second run looked at what a server actually sends. With the full chain, a client verifies. When the server sends only its own certificate and leaves out the intermediate, verification fails with error 20 … unable to get local issuer certificate (2026-09-06-p8-chain-validation).

Then we moved the clock past the leaf's expiry. With the full chain, the client reported the expiry, error 10. With the intermediate missing, it still reported error 20. The issuer path is checked before the dates are, so a certificate whose chain is already broken never reaches "expired". Its expiry goes unnoticed, and the error people see is a trust problem they may have been working around for months.

A monitor that checks a certificate's own dates sees nothing wrong here, because the dates are fine. The served chain is what's broken.

Cross-signing gives one certificate two trust paths

In the same run a second root signed the same intermediate key. The identical leaf then verified under either root. That's how a CA migration is usually done, and it means a certificate can have more than one path and more than one expiry above it. When the old root is retired, clients that trust only the old root break, and clients that trust the new one carry on. An inventory that records only "issuer: Intermediate" has missed which clients are on which path.

What to check before your private root expires

1. List every CA certificate above each leaf, and its notAfter. The earliest one is the date that matters.
2. Run openssl verify -attime against that date for one leaf under each intermediate.
3. Check the chain each server actually sends, as well as the certificate it holds.
4. For each root, record which clients trust it. That list is the work a root change creates.
5. Start a root change with months in hand, because distributing the new trust is the slow part.

These runs had limits. Both are at the openssl verify layer, so no live server refused a connection. We expired an intermediate. A root expiring works the same way one level up. And we didn't run the remediation.

Is a private CA in your estate inside its last year, or does nobody know when it expires? That's the work we do. We map the hierarchy, find who trusts what, and run the change. Talk to us about your private CA.