TLS and PKI Hygiene: The Certificates You Forgot

TLS is the one piece of security nearly everyone gets right at the level of the algorithm — modern ciphers, forward secrecy, strong key exchange are largely solved and on by default. The failures are almost never cryptographic. They are operational: the certificate that expires at 2 a.m. and takes down checkout, the private key copied onto a laptop, the internal certificate authority nobody documented, the wildcard cert shared across forty services so that one compromise exposes them all. PKI hygiene is where the real risk lives.

A TLS certificate is a statement of identity vouched for by a trusted authority, and its security rests on two things: the secrecy of the private key, and the integrity of the trust chain. Everything that goes wrong is a lapse in one of those. A leaked private key lets an attacker impersonate the service or decrypt captured traffic. A sloppy trust chain — an over-trusted internal CA, an unexpected intermediate, a certificate issued for a name it should never have covered — lets an attacker mint trust they should not have. The maths holds; the key management does not.

Expiry is a security event, not just an outage

The most common certificate failure is the dullest: it expires. Teams treat this as an availability problem — the site goes down — but it is also a discovery problem in disguise. An unexpected expiry almost always means a certificate nobody was tracking, which means an asset nobody was managing. As certificate lifetimes shrink industry-wide toward much shorter validity, manual renewal stops being viable at all. Automated issuance and renewal is no longer a nicety; it is the only way to run PKI without regular self-inflicted outages.

• Inventory every certificate and CA. You cannot manage what you have not enumerated. Certificate transparency logs and network scanning both surface certs your spreadsheet missed.
• Automate issuance and renewal. Short lifetimes make manual renewal untenable; automation removes both the outage risk and the temptation to issue long-lived certs to avoid the chore.
• Protect private keys like the crown jewels they are. Generate keys where they will live, store them in an HSM or a secrets manager, never email or copy them, and rotate on any suspicion of exposure.
• Right-size your wildcards and SANs. A wildcard shared across every service turns one key compromise into a total impersonation; scope certificates to reduce blast radius.
• Govern your internal CA. A private CA that can issue for any name is a master key; restrict who can request certificates and constrain what names each can cover.

The trust store no one audits

Beyond your own certificates sits a quieter risk: what your systems trust. Every server and endpoint carries a store of trusted root authorities, and anything signed by any of them is accepted. An attacker who can slip a rogue CA into that store — through a compromised device build, a careless internal root, or malware — can forge trusted certificates for anything. Trust-store hygiene is the neglected mirror image of certificate hygiene: managing not just the certificates you present, but the authorities you are willing to believe.

Make it boring, on purpose

Good PKI is invisible: certificates renew themselves before anyone notices, keys live in hardware, expiries never surprise, and a full inventory is one query away. The organisations that suffer certificate incidents are not the ones with weak cryptography — they are the ones who lost track. Turn PKI into an automated, inventoried, monitored system and an entire class of outages and impersonation risks simply stops happening.

Certificates you cannot see are certificates you cannot renew, revoke or trust-check. Every PKI incident traces back to something that fell off the inventory — which is only the field's oldest rule wearing a certificate: you can't defend what you haven't discovered.