Editor’s note: The original post attached to this title contained unrelated content about China’s digital economy. The article below is an independent, accurate explanation of the topic indicated by the title and slug: common misunderstandings about Public Key Infrastructure (PKI).
What Is PKI and Why Does It Keep Getting Misunderstood?
Public Key Infrastructure (PKI) underpins nearly every secure connection on the internet — TLS certificates, code signing, SSH authentication, and more. Despite its ubiquity, PKI is routinely misunderstood by developers and even by operations teams who work with certificates every day. The consequences range from expired certificates causing outages to badly configured trust chains creating silent security gaps.
Below are four of the most persistent and consequential misunderstandings about PKI.
Misunderstanding 1: “A Certificate Is the Same as a Key”
This is the most foundational confusion. A private key and a certificate are two distinct objects with different roles.
- The private key is a secret cryptographic value that must never leave the system that owns it. It is used to sign data or decrypt messages.
- The certificate is a public document — essentially a signed statement by a Certificate Authority (CA) that binds a public key to an identity (a domain name, an organization, or a person).
When you install a TLS certificate on a web server, you install both: the certificate (public) and the corresponding private key (secret). Mixing up which is which, or treating them as one object, leads to mistakes like accidentally exposing a private key or failing to renew a certificate because the team thought “we already have the keys.”
Practical takeaway
Keep private keys in a secrets manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or similar). Never commit them to source control. Treat the certificate separately as a renewable, distributable artifact.
Misunderstanding 2: “Once Issued, a Certificate Is Trusted Forever”
Certificates have an expiry date, but expiry is only one of several ways a certificate can stop being trusted. The two main mechanisms for revoking trust before expiry are:
- Certificate Revocation Lists (CRLs): A CA publishes a periodically updated list of revoked certificate serial numbers. Clients download this list and check whether a certificate appears on it.
- Online Certificate Status Protocol (OCSP): A client queries the CA’s OCSP responder in real time to check whether a specific certificate is still valid.
Many teams assume that because a certificate has not yet expired, it is trusted. In practice, if the private key is compromised, the certificate must be revoked immediately — expiry alone is not a safety net. Equally, many client implementations have historically failed to enforce revocation checks strictly, which has eroded real-world revocation effectiveness.
Practical takeaway
Build certificate lifecycle management into your CI/CD pipeline. Monitor certificates for upcoming expiry and have a documented runbook for emergency revocation if a private key is ever suspected to be compromised.
Misunderstanding 3: “Our Internal CA Is Good Enough — We Don’t Need to Manage It Carefully”
Many organizations run an internal (private) CA for service-to-service communication, developer tools, and internal APIs. A common assumption is that because the CA is not public-facing, it requires less rigor than a commercial CA. This is wrong for several reasons.
- Compromise of the root CA key is catastrophic. Any certificate signed by a compromised root CA is suspect. Rotating a root CA across a large microservices environment is an expensive, error-prone operation.
- Certificate sprawl is a real problem. Without inventory and lifecycle tooling, internal certificates expire silently, causing hard-to-diagnose service outages.
- Trust distribution is non-trivial. Every service, container image, and client that needs to trust your internal CA must have its root certificate installed. Managing this at scale requires automation.
Practical takeaway
Treat your internal CA with the same operational discipline as a public CA. Store the root CA key offline or in an HSM (Hardware Security Module). Use an intermediate CA for day-to-day issuance so the root key is rarely, if ever, used. Automate certificate issuance and renewal — tools like CFSSL, step-ca, or HashiCorp Vault’s PKI secrets engine are commonly used for this.
Misunderstanding 4: “PKI Is Only About HTTPS”
Web TLS is the most visible use of PKI, but the same infrastructure underpins a much wider set of security controls that DevOps engineers encounter daily:
- Mutual TLS (mTLS): Both client and server present certificates to authenticate each other. This is the basis of zero-trust service meshes such as Istio and Linkerd.
- Code signing: Container images, software packages, and deployment artifacts can be signed with PKI certificates to guarantee integrity and provenance.
- SSH certificate authentication: OpenSSH supports CA-signed certificates as an alternative to distributing individual public keys, making key management at scale far more tractable.
- Document and email signing: S/MIME and PDF signing rely on PKI for legally binding signatures.
- VPN authentication: Many enterprise VPN solutions use PKI certificates instead of, or in addition to, passwords.
Practical takeaway
Audit how PKI is used — or should be used — across your entire stack. If you are running microservices without mTLS, consider whether your service-to-service communication relies entirely on network perimeter controls. If it does, PKI-based mutual authentication is worth evaluating.
Building a Healthier PKI Practice
PKI is not a “set and forget” technology. Sustainable management requires:
- A complete, up-to-date inventory of all certificates and their expiry dates.
- Automated renewal pipelines (Let’s Encrypt / ACME for public certificates; Vault or step-ca for internal ones).
- Clear ownership: every certificate should have a named team responsible for it.
- Revocation procedures documented and tested before they are needed in an emergency.
- Root and intermediate CA keys stored in hardware security modules or offline cold storage.
Understanding what PKI actually is — and what it is not — is the prerequisite for getting these practices right.