Certificate & PKI FAQ

X.509 is the standard format for public-key certificates — the structure behind TLS, code signing, S/MIME and most machine identity. A certificate binds a public key to an identity (a domain, a device, a person) and is signed by a certificate authority. When your browser shows a padlock, it has validated an X.509 chain up to a root it already trusts.

Public if anything outside your organisation must trust it: websites, APIs consumed by third parties, publicly distributed software. Private if the trust boundary is internal: service-to-service mTLS, device identity, internal dashboards. Most organisations run both, and the mistake is using a public CA for internal traffic because it is the familiar tool.

No. The cryptography is identical, and a free Let’s Encrypt certificate and a $400 one give the same TLS. What you pay for is validation depth (OV and EV assert a vetted legal entity), warranty, support, longer validity and management tooling. If you need domain-validated TLS on a site you can automate, free is not a compromise.

CLM is the layer above issuance: finding every certificate you already have, enforcing which CAs and key types are allowed, renewing before expiry, installing the result where it belongs, and reporting on all of it. It matters once you have more certificates than a person can track in a spreadsheet — which arrives far sooner than most teams expect.

Because revocation has never worked reliably at internet scale, and a short lifetime limits the damage of a compromised key without depending on it. Public TLS maximum validity has fallen repeatedly and continues to; the CA/Browser Forum has agreed on further reductions. The practical consequence is simple: manual renewal stops being viable, and automation stops being optional.

ACME is the protocol that lets a server prove it controls a domain and collect a certificate without a human. It is what makes Let’s Encrypt work. It matters beyond public TLS because private CAs such as step-ca and Keyfactor also speak it, so internal services can use the same clients and the same habits as public ones.

If you run a private CA whose compromise would be serious, yes — the root key should live in hardware that will not export it. Regulated environments often mandate FIPS 140-3 validated modules. For a small internal CA issuing short-lived certificates to a handful of services, a well-protected software key with a documented recovery plan is usually the proportionate answer.

Far more than it thinks. Discovery scans routinely surface several times the number of certificates a team can name, because certificates accumulate in load balancers, forgotten test environments, container images and vendor appliances. That gap between believed and actual inventory is the single most common cause of expiry outages.