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.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on DigiCert's blog post: Stale locally cached intermediates can break trust even when the active installation is otherwise correct.
Why it matters: It matters because certificate lifecycle failures can create avoidable outages and trust errors across client platforms, servers, and application chains, which is an IAM and NHI governance problem as much as a PKI problem.
Context
Expired intermediate TLS certificates expose a lifecycle problem, not just a chain validation error. When a legacy intermediate remains cached on a client or installed on a server, the trust path can fail even though the certificate in active use was issued correctly.
That makes certificate management a governance issue across the full identity lifecycle of machine credentials. In practice, the weak point is often not issuance but removal, cleanup, and ensuring that old intermediates no longer influence verification on endpoints, servers, and application stacks.
The article is mainly about certificate trust failure caused by stale intermediates on OS X, Windows, and Apache environments. For teams managing workload identity and machine trust, that is a familiar pattern: trust breaks when lifecycle state is inconsistent across systems.
Key questions
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. The client or server may trust or present an old chain element from a local keychain, trust store, or backend installation, which produces untrusted-certificate errors and disrupts secure connections.
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. If old intermediates remain in local stores or compatibility chains, the environment keeps making trust decisions against stale artefacts instead of the current certificate path.
Q: How should teams manage certificate offboarding after a compatibility chain is retired?
A: They should treat retirement as a governed lifecycle step, not a side effect of reissuing certificates. That means removing the legacy intermediate from clients, servers, and configuration files, then confirming that no cache or trust store still references it. Without that cleanup, the retired chain can continue to influence validation.
Q: How can security teams tell whether certificate trust cleanup is actually working?
A: By verifying that the intended chain resolves consistently across endpoints, server-to-server connections, and web server configuration after the old intermediate is removed. If one platform still throws an untrusted-certificate error, the cleanup is incomplete. Successful validation must be consistent across every trust boundary that uses the certificate.
Technical breakdown
Why cached intermediate certificates still break TLS trust
A TLS chain is only as reliable as the certificates a client uses to build trust at verification time. If a locally cached or installed intermediate remains present after it expires, the client or server may still try to use it when constructing the path to the root. That creates an untrusted-certificate error even when the live site or service is otherwise configured correctly. The problem is especially visible when older compatibility intermediates linger on endpoints, keychains, or backend systems.
Practical implication: inventory and remove stale intermediates from every place trust stores can persist, not just from current server configurations.
Why operating systems and servers fail differently
The article shows two distinct failure surfaces. On OS X, the issue sits in the local Login keychain, where an expired intermediate can remain visible to certificate validation. On Windows server-to-server links, one server may still present or retain the legacy certificate, causing the peer to reject the chain. Apache adds a third pattern, where the chain file itself points to the wrong intermediate. The underlying issue is the same, but the remediation point differs by platform.
Practical implication: validate certificate chain state on clients, servers, and web server configuration separately instead of assuming one fix covers all platforms.
Why certificate lifecycle is a governance control, not a one-time install
Certificate installation and certificate lifecycle are not the same control. Installation gets a chain working at a point in time, but lifecycle governance determines whether obsolete intermediates are actually retired everywhere they exist. That includes local caches, keychains, application stores, and server configuration files. When the old intermediate still exists in any of those places, trust decisions can diverge across systems and the environment behaves as if multiple certificate states are active at once.
Practical implication: treat certificate retirement, not just issuance, as part of your machine identity lifecycle and PKI governance process.
Breaches seen in the wild
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
- GitHub code signing certificate theft 2022: A machine account's compromised token cloned GitHub's Desktop and Atom repos, exposing encrypted signing certificates later revoked.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Expired intermediates are a lifecycle failure mode, not a cryptography failure. The certificate and the trust model may both be valid, yet stale local copies can still override the intended chain. That means the real control gap is governance over certificate retirement across every trust store and server path. Practitioners should read this as a machine identity lifecycle issue, not a pure PKI hygiene issue.
Trust breaks when the environment contains more than one authoritative certificate state. OS X keychains, Windows server stores, and Apache chain files can each preserve a different version of the same relationship. That creates inconsistent validation outcomes across platforms, which is why chain cleanup must be verified at each trust boundary. The practitioner lesson is to govern certificate state as an inventory problem, not a single deployment event.
Certificate lifecycle management needs an explicit offboarding model. Legacy intermediates that are no longer used still matter if they remain reachable in caches or configuration. This is the same governance problem that appears in NHI offboarding: a credential can be retired on paper while remaining effective in practice. Teams should treat retirement as a control objective equal to issuance.
Expired intermediate certificate chains create trust debt. The debt accumulates when short-term compatibility fixes are left behind after the compatibility need ends. Over time, that increases the chance that trust verification will fail in one layer while appearing healthy in another. For identity programmes, the lesson is that trust cleanup has to be continuous, not event-driven.
Certificate trust is a distributed governance problem. The article’s OS X, Windows, and Apache examples show that no single console can prove the chain is clean everywhere. That is why certificate lifecycle oversight belongs with broader identity governance and machine identity controls, where inventory, retirement, and validation are linked into one operating model.
What this signals
Expired intermediates expose a trust-state drift problem: the environment can retain old certificate material long after operations believe the chain has moved on. That is a governance failure as much as a technical one, because validation behaviour becomes dependent on stale local state rather than intended policy.
Teams managing workload identity and machine certificates should assume that retirement is harder than issuance. The operational question is not whether a new certificate exists, but whether every cached copy, keychain entry, and chain file has actually been removed from circulation.
For practitioners
- Audit cached intermediate certificates Search keychains, trust stores, server certificate stores, and application configuration for obsolete intermediates that are no longer part of the active chain.
- Validate chain state on each platform Test certificate verification separately on macOS clients, Windows server-to-server paths, and Apache deployments because the failure point can differ by environment.
- Remove legacy intermediates from trust stores Delete expired intermediates from local keychains and server stores, then confirm that new validation uses the intended intermediate and root certificates.
- Govern certificate retirement as lifecycle work Add certificate offboarding to PKI operations so that retired intermediates are removed from endpoints, applications, and infrastructure when compatibility needs end.
Key takeaways
- Expired intermediate certificates can still break trust when old copies remain in local caches, keychains, or server stores.
- The article shows that the same certificate problem can surface differently on macOS, Windows, and Apache because each platform handles chain state differently.
- The control that matters most is lifecycle retirement, because certificate trust only stabilises when legacy intermediates are removed everywhere they can still be used.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Expired intermediates persist because legacy certificate offboarding was incomplete. |
| NHI-07 — Long-Lived Secrets | The expired intermediate remained present long after its compatibility purpose ended. | |
| Recommendation — Retire obsolete NHI certificates from every trust store and configuration path before they remain usable. Shorten the lifetime of compatibility certificates and remove them from production trust paths when they expire. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Certificate lifecycle cleanup is part of managing authenticators and their retirement. |
| Recommendation — Apply IA-5 to enforce certificate retirement, rotation, and revocation across infrastructure and endpoints. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Stale intermediates behave like lingering authorisations in trust stores and server configs. |
| Recommendation — Review certificate-authority paths and remove outdated trust permissions from every environment. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Expired certificate material represents lingering credential material in the trust chain. |
| Recommendation — Track stale certificate exposure as credential access risk and prioritise removal from all systems. | ||
Key terms
- Intermediate Certificate: An intermediate certificate sits between a root CA and a leaf certificate to extend trust without exposing the root directly. In practice, it must be installed and chained correctly or clients will reject the connection, even when the leaf certificate itself is valid.
- Certificate Chain: The linked sequence of trust relationships that lets a browser or client verify a certificate back to a trusted root authority. If any link in the chain fails, the certificate may be treated as untrusted even when the endpoint itself is correctly configured.
- Trust Store: A set of certificates that a system accepts as trusted for authentication or encryption decisions. If the store is stale or poorly maintained, systems may continue accepting identities that should no longer be valid, which turns trust management into an operational security risk.
- Certificate Lifecycle Management: The governance of digital certificates from issuance through renewal and revocation, ensuring certificates are valid, monitored, and rotated before expiry. Expired certificates are a leading cause of outages and unplanned security gaps.
Deepen your knowledge
NHI governance, machine identity security, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or machine identity programme, it is worth exploring.
Published by the NHIMG editorial team on June 25, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org