Notifications
Clear all
Topic starter
25/06/2026 10:35 pm
TL;DR: An expired legacy intermediate certificate can still trigger untrusted-certificate errors when it remains cached locally on clients or servers, affecting OS X keychains, Windows server-to-server links, and Apache chains, according to DigiCert’s guide. The deeper lesson is that certificate trust breaks when lifecycle cleanup lags behind installation and revocation hygiene.
NHIMG editorial — based on content published by DigiCert: Fix for an expired intermediate SSL certificate chain
Questions worth separating out
Q: What breaks when expired intermediate certificates are still cached on clients or servers?
A: Expired intermediates can break TLS validation even when the active certificate is still valid.
Q: Why do expired intermediates create recurring trust failures in certificate programs?
A: They create recurring failures because certificate lifecycle processes often stop at issuance and overlook retirement.
Q: How do security teams know whether a certificate chain problem is local or systemic?
A: Teams should compare the chain presented by the server with the trust stores and cached certificates on affected endpoints.
Practitioner guidance
- Audit all local trust stores Search client keychains, server stores, and application hosts for expired intermediate certificates, then remove any legacy chain elements that no longer support current installations.
- Validate the full certificate chain on each platform Check Windows, Exchange, ISA, TMG, Lync, and Apache environments for the exact intermediate chain being presented or trusted, and replace outdated chain files where they persist.
- Assign ownership to certificate retirement Make retirement and local-store cleanup a tracked lifecycle task, with explicit ownership for removing expired intermediates after replacement or compatibility changes.
What's in the full article
DigiCert's full post covers the operational detail this post intentionally leaves for the source:
- Step-by-step remediation for Mac OS X keychains, including how to locate and delete the expired intermediate certificate.
- Windows, Exchange, ISA, TMG, and Lync repair guidance using the DigiCert utility and manual cleanup options.
- Apache chain replacement instructions showing how to swap in the correct SSLCertificateChainFile.
- Platform-specific troubleshooting notes for administrators who need to confirm the exact certificate path in use.
👉 Read DigiCert's guide to fixing an expired intermediate SSL certificate chain →
Expired intermediate certificate chains: what trust teams missed?
Explore further
25/06/2026 11:11 pm
Certificate lifecycle is only as strong as the cleanup step. This post shows that expired intermediates remain dangerous when local stores, backend servers, and chain files are not actively retired. The issue is not issuance alone, but whether every copy of the old trust artefact is removed from the environment. Practitioners should treat retirement and validation as part of the same lifecycle control.
A few things that frame the scale:
- Only 38% have automated certificate lifecycle management in place, according to The Critical Gaps in Machine Identity Management report.
- 69% of organisations now have more machine identities than human ones, which is why certificate lifecycle gaps scale faster than most programmes expect.
A question worth separating out:
Q: Who should own expired certificate cleanup in identity and security programmes?
A: Ownership should sit with the team responsible for certificate lifecycle and trust-store hygiene, not only with the team that issued the certificate. Cleanup must be treated as a tracked operational task because expired intermediates can continue to affect validation until every copy is removed.
👉 Read our full editorial: Expired intermediate TLS certificate chains expose trust failures
