Most certificate incidents are not cryptographic failures: they are management failures, where a certificate nobody owned expired, a private key sat in a readable file, or a trust decision made years ago broke when the outside world changed. This list ranks the ten PKI and certificate management mistakes that most often cause outages and compromises, with how to spot each one in your own estate and how to fix it. It is written for PKI owners, platform and infrastructure engineers, identity teams and the security leads who answer for them. Certificates are machine identities, so every item here is also a non-human identity problem. For the full lifecycle model read the Machine Identity, PKI and Certificate Lifecycle Guide; this page is the short list of what goes wrong.
Key takeaways
- Inventory comes first. You cannot renew, rotate or revoke a certificate you do not know exists, and most expiry outages start with an unknown certificate.
- Public TLS lifetimes are falling to 47 days. Under CA/Browser Forum Ballot SC-081 the maximum drops to 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029, which ends manual renewal.
- Private keys are the real asset. A leaked key with a valid certificate is a working identity until it is revoked and every relying party stops trusting it.
- Trust decisions age badly. Hard-coded roots, pinned certificates and a single CA all fail when a root expires or a CA is distrusted, as Entrust customers found in 2024.
- Internal PKI is an attack surface. Misconfigured Active Directory Certificate Services templates let an ordinary user obtain a certificate that authenticates as an administrator.
The Top 10 at a glance
| # | Mistake | What it leads to | Typical first sign |
|---|---|---|---|
| 1 | No complete certificate inventory or owner | Surprise expiry, unrevoked certificates after staff leave | A certificate nobody recognises in a scan or CT log |
| 2 | Manual renewal driven by calendars and spreadsheets | Production outages when a certificate expires | Renewals done in the last week, by one person |
| 3 | Not ready for shorter certificate lifetimes | Renewal workload multiplies, outages rise from 2026 | Systems that cannot install a certificate without a change ticket |
| 4 | Private keys stored and moved carelessly | Impersonation, signed malware, intercepted traffic | Key files in repositories, shared drives or tickets |
| 5 | Misconfigured AD CS templates and CA permissions | Domain privilege escalation with a forged identity | Templates that let the requester set the subject |
| 6 | Hard-coded trust, pinning and stale trust stores | Clients that break on root expiry or CA change | Devices and apps with their own bundled CA lists |
| 7 | Wildcard and shared certificates across many systems | One key compromise exposes every host | The same certificate serial on many endpoints |
| 8 | Weak algorithms, short keys and no crypto agility | Forgeable or breakable certificates, painful migrations | SHA-1 signatures or RSA keys below 2048 bits in scans |
| 9 | Revocation that does not work in practice | Compromised certificates stay trusted | No tested revocation runbook, clients that ignore CRLs |
| 10 | Single-CA dependency with no replacement plan | Mass reissue under deadline when a CA is distrusted | Every public certificate from one issuer, no second ACME account |
The ranking is our judgement of how often each mistake causes a real outage or compromise and how hard it is to recover. Items 1 and 2 cause the most incidents; items 4 and 5 cause the most damaging ones.
1. No complete certificate inventory or owner
The mistake: certificates are issued by several public CAs, an internal Microsoft CA, cloud certificate services, service meshes and individual teams, and nobody holds a single list with the owner, location, issuer, key type and expiry of each.
Why it matters: every other item on this list depends on knowing what exists. NIST SP 1800-16, Securing Web Transactions: TLS Server Certificate Management, treats certificate incidents as a problem of managing certificates at scale and sets out practices to prevent, detect and recover from them. An unknown certificate is never renewed on purpose, never rotated after an incident and never revoked when its system is retired.
How to check: compare three views. Scan your network ranges and cloud load balancers for TLS endpoints; export issued certificates from every CA you run; query Certificate Transparency logs for all public certificates naming your domains. Anything in one view but missing from your inventory is a gap.
How to fix: make the inventory a system, not a spreadsheet, fed automatically by CA exports, CT monitoring and discovery scans. Require an owning team (not a person) for every certificate and refuse issuance without one. Treat it as part of the asset inventory required by NIST SP 800-53 CM-8. See the Certificate Transparency Monitoring Guide for Web Teams.
2. Manual renewal driven by calendars and spreadsheets
The mistake: renewals depend on a reminder email, a calendar entry or one engineer who remembers. The certificate is renewed at the CA but not deployed to every host, or deployed but the service is never reloaded.
Why it matters: expiry is the most visible certificate failure. On 6 December 2018 Ericsson reported network disturbances for customers in several countries running two software versions of its SGSN-MME core network node, with the initial root cause pointing to an expired certificate in the installed software. One certificate in a vendor build took down mobile data for operators that had no direct control over it.
How to check: list every certificate expiring in the next 30 days and ask how each will be renewed. If the answer is a named person, the process is manual. Check for certificates that were renewed at the CA but still show the old serial number on the live endpoint.
How to fix: automate the full chain: issue, deploy, reload and verify. Use ACME (RFC 8555) for public and, where supported, internal certificates. Monitor the certificate actually served by each endpoint, not the one in the CA, and alert at 30, 14 and 7 days. Ask suppliers how certificates embedded in their products are renewed. See the ACME and Automated Certificate Management Guide and the Certificate Expiry Outages and 47-Day TLS Certificates Guide.
3. Not ready for shorter certificate lifetimes
The mistake: assuming public TLS certificates will keep lasting about a year, and planning renewal capacity on that basis.
Why it matters: CA/Browser Forum Ballot SC-081, passed in April 2025 with all four certificate consumers (Apple, Google, Microsoft and Mozilla) voting yes, changes Section 6.3.2 of the TLS Baseline Requirements. The maximum validity of a publicly trusted TLS certificate is set out below. The same ballot cuts the period for which domain validation can be reused to 10 days by 2029.
| Certificate issued | Maximum validity | Renewals per year (approx.) |
|---|---|---|
| Before 15 March 2026 | 398 days | 1 |
| 15 March 2026 to 14 March 2027 | 200 days | 2 |
| 15 March 2027 to 14 March 2029 | 100 days | 4 |
| From 15 March 2029 | 47 days | 8 or more |
How to check: for each system holding a public certificate, record how a certificate is installed today: ACME client, API, configuration management, or a person with a console. Anything needing a person or a change ticket will fail at 47 days.
How to fix: move every public endpoint to automated issuance before the 100-day step in March 2027. Add ACME Renewal Information (ARI, RFC 9773, Standards Track, June 2025), which lets the CA suggest a renewal window, so clients renew early when a CA needs to revoke at scale. Terminate TLS at load balancers or gateways where legacy hosts cannot automate.
4. Private keys stored and moved carelessly
The mistake: private keys generated on a laptop and emailed to the server team, exported as PFX files with weak passwords, committed to repositories, baked into container images, or kept on build servers where many people and pipelines can read them.
Why it matters: the certificate is public; the private key is the identity. Whoever holds the key can impersonate the server, decrypt or intercept traffic, or sign code. In March 2023 GitHub replaced its RSA SSH host key after the private key was briefly exposed in a public repository, forcing every client to update its known hosts (see the GitHub RSA SSH host key exposure). In 2021 attackers used a stolen Mimecast certificate to authenticate to customers' Microsoft 365 tenants (see the Mimecast certificate compromise). MITRE ATT&CK tracks this as T1649 Steal or Forge Authentication Certificates and T1588.004 Digital Certificates.
How to check: run secret scanning across repositories, images and file shares for PEM private key headers and PFX or P12 files. List which keys are exportable on Windows hosts and which signing keys are not held in a hardware security module.
How to fix: generate keys where they will be used and never move them; mark keys non-exportable; hold CA keys, code signing keys and high-value TLS keys in an HSM or cloud KMS; issue short-lived certificates so a leaked key expires quickly. See the Code Signing Security Guide and Signing keys and certificates in breaches.
5. Misconfigured AD CS templates and CA permissions
The mistake: Active Directory Certificate Services templates that allow the requester to supply the subject name, include a client authentication usage, need no manager approval and are enrollable by Domain Users; or CA and template permissions that let ordinary accounts edit templates.
Why it matters: a certificate with client authentication usage can be used to log on through Kerberos PKINIT. If a low-privileged user can request one naming a domain administrator, the CA will issue a valid identity for that administrator. These conditions were catalogued publicly in 2021 as the ESC1 to ESC8 escalation paths and remain common in older domains. The certificate survives a password reset (T1649).
How to check: review every published template for the "Supply in the request" subject setting combined with client authentication and broad enrolment rights; review write permissions on templates and the CA object; check whether strong certificate mapping is enforced on domain controllers.
How to fix: unpublish templates that are not used; build subject names from Active Directory instead of the request; require CA manager approval for any template that allows a supplied subject; restrict enrolment to the groups that need it; enforce strong certificate mapping. See the AD CS Security Guide and the Kerberos PKINIT and Certificate Mapping Guide.
6. Hard-coded trust, pinning and stale trust stores
The mistake: applications, IoT devices and appliances that ship their own root list, pin a specific certificate or intermediate, or run TLS libraries that never receive updates.
Why it matters: trust stores need maintenance as roots expire and CAs change. When the DST Root CA X3 cross-signature expired on 30 September 2021, Let's Encrypt warned that typical websites would see little difference but that API clients and IoT devices were most likely to need attention, along with older devices that did not trust ISRG Root X1 and clients on OpenSSL 1.0.x, which failed to verify the alternative chain. Pinning makes the same failure certain on the day the pinned certificate is replaced.
How to check: list every client that does not use the operating system trust store, and every app that pins. Ask device suppliers how root updates are delivered.
How to fix: use the platform trust store and keep it updated; pin, if at all, to a set of public keys including a backup, never to a leaf certificate; build trust store updates into device firmware plans. See Certificate trust stores and root CA management.
7. Wildcard and shared certificates across many systems
The mistake: one wildcard certificate and key copied to dozens of web servers, load balancers, appliances and third-party services, because it is cheaper and easier than issuing per host.
Why it matters: the key now lives in as many places as the certificate, and the weakest of those systems decides its safety. A compromise anywhere allows impersonation of every name the wildcard covers, and every renewal becomes a coordinated change across all copies.
How to check: group your discovery results by certificate serial number or public key; any key seen on more than a handful of endpoints is a shared key.
How to fix: once renewal is automated, issue per-service certificates with only the names each service needs. Keep wildcards, if at all, to tightly controlled termination points and never hand them to third parties.
8. Weak algorithms, short keys and no crypto agility
The mistake: internal CAs still issuing SHA-1 signed certificates or RSA keys below 2048 bits, long-lived internal roots built with old parameters, and no way to change algorithms without rebuilding systems by hand.
Why it matters: the TLS Baseline Requirements already require RSA moduli of at least 2048 bits for public certificates (Section 6.1.5), but internal PKI has no browser policing it. Algorithm changes, including the move to post-quantum signatures, are large re-issuance events.
How to check: report signature algorithm, key type and key length from your inventory; flag SHA-1, RSA 1024 and any root or intermediate expiring after 2035 that uses parameters you would not choose today.
How to fix: set a minimum crypto profile in your certificate policy, enforce it in CA templates and issuance tooling, and treat automated rotation (items 2 and 3) as the foundation of crypto agility. See the Enterprise PKI Design and CA Hierarchy Guide.
9. Revocation that does not work in practice
The mistake: assuming that revoking a certificate stops it being trusted, without a runbook, without knowing which relying parties check revocation, and with internal CRLs that expire or are published where clients cannot reach them.
Why it matters: many clients soft-fail or do not check revocation at all, so a revoked but unexpired certificate may still work. For public certificates the Baseline Requirements oblige the CA to revoke within 24 hours on key compromise (Section 4.9.1.1), and CA/Browser Forum Ballot SC063 made OCSP optional while requiring CRLs. Revocation is a CA obligation; stopping use of a compromised key is yours.
How to check: run a tabletop: a TLS key is in a public repository, what happens in the next hour? Check that each internal CA's CRL is current, reachable from every network zone and monitored for expiry.
How to fix: write and test a key compromise runbook (replace first, then revoke); monitor CRL publication; prefer short-lived certificates where revocation is unreliable. See the Certificate Revocation Guide.
10. Single-CA dependency with no replacement plan
The mistake: buying every public certificate from one CA, with its tooling built into deployment scripts, and no tested way to switch.
Why it matters: browsers can and do withdraw trust. In June 2024 Google announced that Chrome would stop trusting TLS certificates chaining to certain Entrust and AffirmTrust roots whose earliest Signed Certificate Timestamp fell after 11 November 2024, citing a pattern of compliance failures and unmet improvement commitments. Affected sites faced a full-page warning in Chrome 131 and later unless they moved CA, a forced migration on a fixed date.
How to check: count public certificates by issuer. If one issuer exceeds most of the estate and moving would need code changes, you have a single point of failure.
How to fix: keep ACME accounts with at least two CAs and test issuance from the second; set CAA records listing the CAs you actually use; rehearse a mass replacement. See the CA Compromise and Mass Certificate Replacement Playbook.
Detection: what to monitor
| Signal | Source | What it catches |
|---|---|---|
| Certificates expiring within 30 days, measured on the live endpoint | Endpoint monitoring, discovery scans | Items 1, 2, 3 |
| New public certificates for your domains from an unexpected issuer | Certificate Transparency monitoring | Items 1, 10, mis-issuance |
| Private key files or PEM headers in code and images | Secret scanning | Item 4 |
| Certificate requests with a supplied subject or SAN differing from the requester | AD CS issuance events (Windows Security log on the CA) | Item 5 |
| Template and CA permission changes | AD CS and directory audit logs | Item 5 |
| Root certificates added to endpoint trust stores outside change control | EDR, configuration management | Item 6, ATT&CK T1553.004 Install Root Certificate |
| Internal CRL next-update approaching | CRL monitoring | Item 9 |
Metrics that show progress: percentage of certificates in the inventory with a named owning team; percentage of public certificates issued and deployed automatically; number of expiry incidents per quarter (target zero); median certificate lifetime in the estate; number of private keys found outside approved stores; time to replace every certificate from one CA in a rehearsal.
Common failure patterns
- Automating issuance but not deployment: the CA renews on time but the new certificate never reaches the appliance, so the outage happens anyway.
- Monitoring the CA, not the endpoint: dashboards show a healthy renewed certificate while the server still presents the old one.
- Inventory without owners: a complete list of certificates that no team acts on when alerts fire.
- Revoking before replacing: pulling a compromised certificate before its replacement is deployed turns a security incident into an outage.
Mapping to frameworks
| Framework | Reference | Items |
|---|---|---|
| NIST SP 800-53 Rev. 5 | SC-17 Public Key Infrastructure Certificates; SC-12 Cryptographic Key Establishment and Management; SC-13 Cryptographic Protection; IA-5 Authenticator Management; CM-8 System Component Inventory | All; 4, 8; 1 |
| NIST CSF 2.0 | ID.AM-08 lifecycle management; PR.AA-03 users, services and hardware are authenticated; PR.DS-02 data in transit protected | 1 to 3; 4, 5; 6 to 9 |
| CA/Browser Forum TLS Baseline Requirements | Section 6.3.2 validity periods; 6.1.5 key sizes; 4.9.1.1 revocation reasons | 3; 8; 9 |
| MITRE ATT&CK | T1649 Steal or Forge Authentication Certificates; T1588.004 Digital Certificates; T1553.004 Install Root Certificate; T1557 Adversary-in-the-Middle | 4, 5; 4; 6; 6, 9 |
Where to start
- Week 1 to 2: build a first inventory from CA exports, CT logs and a network scan; assign owning teams to everything expiring in the next 90 days.
- Week 2 to 4: scan repositories, images and shares for private keys; replace and revoke anything exposed; review AD CS templates for supplied-subject client authentication and fix them.
- Month 2 to 3: automate issuance, deployment and endpoint verification for public certificates with ACME, starting with the systems that renew most often or failed before; add ARI.
- Month 3 to 6: set up a second CA, set CAA records, write and rehearse the key compromise and CA replacement runbooks.
- Before March 2027: confirm every public endpoint can handle 100-day certificates without a person, and set a date for 47-day readiness.
Practitioner checklist
- Every certificate in one inventory with owning team, location, issuer, key type and expiry.
- Expiry monitored on the live endpoint with alerts at 30, 14 and 7 days.
- Public certificates issued and deployed by ACME with ARI, ready for 100-day and 47-day lifetimes.
- No private keys in repositories, images, tickets or shares; high-value keys in an HSM or KMS.
- AD CS templates reviewed: no supplied subject with client authentication for broad groups; strong certificate mapping enforced.
- Clients use maintained platform trust stores; no leaf pinning.
- Wildcards limited to controlled termination points and never shared with third parties.
- Minimum crypto profile enforced at issuance; no SHA-1 or sub-2048-bit RSA.
- Tested key compromise runbook: replace, then revoke; internal CRLs monitored.
- At least two CAs usable, CAA records set, mass replacement rehearsed.
Standards and references
- CA/Browser Forum: Baseline Requirements for TLS Server Certificates
- CA/Browser Forum: Ballot SC-081v3, Schedule of Reducing Validity and Data Reuse Periods
- NIST: SP 1800-16, Securing Web Transactions: TLS Server Certificate Management
- NIST: SP 800-53 Rev. 5
- IETF: RFC 9773, ACME Renewal Information (ARI) Extension
- MITRE ATT&CK: Steal or Forge Authentication Certificates
- Google Security Blog: Sustaining Digital Certificate Security, Entrust Certificate Distrust
- Let's Encrypt: DST Root CA X3 Expiration (September 2021)
Related NHI Mgmt Group resources: Machine Identity, PKI and Certificate Lifecycle Guide · Certificate Expiry Outages and 47-Day TLS Certificates Guide · AD CS Security Guide · Top 10 NHI Risks