Certificate Management and PKI

# Certificate Management and PKI

Definition

Certificate management is the operational discipline of issuing, renewing, revoking, and monitoring digital certificates across an organization's technology environment. Public Key Infrastructure (PKI) is the system of certificate authorities (CAs), registration authorities, certificate policies, and cryptographic protocols that makes certificate-based authentication and encryption possible.

Digital certificates are the trust anchors of the internet. When a browser connects to a website over HTTPS, it verifies the server's certificate to confirm the server is who it claims to be. When two services authenticate via mutual TLS (mTLS), each presents a certificate to the other. When a user connects to the corporate Wi-Fi with EAP-TLS, the device presents a certificate to the RADIUS server. When a developer signs code, the signature includes a certificate that identifies the signer.

Certificate management is invisible when it works and catastrophic when it fails. An expired certificate causes an outage: the service is still running, but clients reject the connection because the certificate is no longer valid. A compromised certificate authority undermines the trust of every certificate it issued. A misissued certificate enables an attacker to impersonate a legitimate server. The most visible certificate failures have caused global outages: Equifax's breach went undetected partly because a network monitoring tool's certificate had expired, disabling the traffic inspection that would have caught the exfiltration.

How It Works

How Certificates Work

A digital certificate binds a public key to an identity (a domain name, an organization, a person, or a device). The binding is attested by a Certificate Authority that verifies the identity and signs the certificate with the CA's own private key. Relying parties (browsers, applications, devices) trust the certificate because they trust the CA that signed it.

The trust model is hierarchical. Root CAs are the top of the trust chain. Their certificates are pre-installed in operating systems and browsers (the "trust store"). Root CAs issue certificates to Intermediate CAs, which issue certificates to end entities (websites, servers, users, devices). The chain of trust flows from the end entity certificate, through the intermediate CA, to the root CA that the relying party trusts.

Certificate contents. A standard X.509 certificate contains: the subject (the identity the certificate represents, typically a domain name for TLS certificates), the issuer (the CA that signed the certificate), the public key, the validity period (not-before and not-after dates), the serial number, the signature algorithm, and extensions (Subject Alternative Names for additional domains, Key Usage, Extended Key Usage).

Certificate types by validation level:

Domain Validation (DV): the CA verifies that the requester controls the domain. DV certificates are issued in minutes, cost nothing (Let's Encrypt) to moderate amounts, and are appropriate for most web servers. DV certificates confirm "this server controls this domain." They do not confirm who operates the domain.

Organization Validation (OV): the CA verifies the organization's legal identity in addition to domain control. OV certificates display the organization name in the certificate details. OV provides moderate assurance that the server is operated by a verified organization.

Extended Validation (EV): the CA performs thorough identity verification including legal entity verification, physical address verification, and operational existence confirmation. EV certificates historically displayed the organization name in the browser's green address bar, though most browsers have removed this visual distinction.

Certificate Lifecycle

Issuance. The entity generates a key pair and creates a Certificate Signing Request (CSR) containing the public key and subject information. The CSR is submitted to the CA. The CA validates the request (domain ownership for DV, organizational identity for OV/EV) and issues the signed certificate. Automated issuance (ACME protocol, used by Let's Encrypt and other CAs) eliminates manual CSR generation and validation for DV certificates.

Deployment. The issued certificate and its private key are installed on the server, device, or application. For TLS certificates: the certificate, intermediate CA certificate(s), and private key are configured in the web server (Nginx, Apache, IIS) or load balancer. For client certificates: the certificate is deployed to the device's certificate store through MDM, GPO, or manual installation.

Monitoring. Certificates are monitored for approaching expiration, configuration errors (incomplete chain, weak cipher suites, protocol mismatches), and certificate transparency log entries (unauthorized certificates issued for the organization's domains). Certificate monitoring tools (Venafi, Keyfactor, DigiCert CertCentral, open-source tools like certspotter) provide visibility into the certificate landscape.

Renewal. Before a certificate expires, it must be renewed: a new certificate is issued (with the same or updated subject information) and deployed to replace the expiring certificate. Manual renewal is error-prone because it depends on a human remembering the expiration date and executing the renewal process in time. Automated renewal (ACME protocol with tools like Certbot, Caddy, or cloud-native certificate services) eliminates expiration-related outages by renewing certificates automatically before they expire.

Let's Encrypt issues certificates with 90-day validity specifically to encourage automation: a 90-day certificate that is renewed automatically every 60 days is always current. A 1-year certificate that requires manual renewal is at risk of expiration every 12 months.

Revocation. When a certificate's private key is compromised, the certificate must be revoked: marked as invalid before its expiration date. Revocation is published through Certificate Revocation Lists (CRLs) or the Online Certificate Status Protocol (OCSP). Relying parties check the revocation status before trusting the certificate.

Revocation has a practical limitation: not all clients check revocation status reliably. Some browsers do not check CRLs. OCSP responses can be cached (meaning a revoked certificate may still be accepted until the cache expires). OCSP stapling (where the server includes a fresh OCSP response in the TLS handshake) improves revocation checking reliability but requires server-side configuration.

Decommission. When the certificate is no longer needed (the server is decommissioned, the domain is transferred, the user leaves the organization), the certificate is revoked and the private key is securely destroyed.

Enterprise PKI

Organizations with internal PKI operate their own Certificate Authority hierarchy for internal use: issuing certificates for internal servers, VPN authentication, Wi-Fi authentication (EAP-TLS), code signing, email encryption (S/MIME), and device authentication.

Internal CA architecture. A typical enterprise PKI includes: an offline Root CA (powered off and stored in a secure location, activated only to issue intermediate CA certificates), one or more online Intermediate CAs (also called Issuing CAs) that issue certificates to end entities, and Registration Authorities or automated enrollment services (Active Directory Certificate Services, SCEP, EST) that process certificate requests.

The Root CA is kept offline to protect the trust anchor. If the Root CA's private key is compromised, every certificate in the hierarchy is compromised. Offline storage ensures the Root CA is not accessible to network-based attacks.

Active Directory Certificate Services (AD CS). Microsoft's enterprise PKI platform, integrated with Active Directory. AD CS enables automated certificate enrollment for domain-joined devices, certificate-based Wi-Fi authentication (EAP-TLS), and smart card authentication. AD CS is widely deployed in enterprise Windows environments.

AD CS security is critical because a compromised CA can issue certificates for any identity, enabling authentication as any user or service in the domain. The ESC (Escalation) series of AD CS attacks (ESC1 through ESC13, documented by SpecterOps) exploit misconfigurations in AD CS certificate templates to escalate privileges to domain admin. AD CS misconfigurations are among the most impactful findings in Active Directory security assessments.

Certificate Management Challenges

Certificate sprawl. Organizations accumulate certificates across web servers, load balancers, CDNs, cloud services, internal applications, IoT devices, and developer environments. A mid-market organization may have hundreds to thousands of certificates across dozens of platforms. Without centralized visibility, certificates expire without warning, creating outages.

Shadow certificates. Certificates issued outside the organization's managed PKI process: developers obtaining Let's Encrypt certificates for test environments, cloud teams provisioning certificates through AWS ACM without informing security, and SaaS applications managing their own certificates. Shadow certificates are the certificate equivalent of shadow IT: unmanaged, unmonitored, and potentially misconfigured.

Short validity periods. The industry trend toward shorter certificate lifetimes (Google proposed reducing public TLS certificate validity to 90 days; Apple implemented 398-day maximum in 2020; the trajectory is toward shorter periods) increases the operational burden of certificate management. Organizations that renew certificates manually face quarterly renewal cycles for every certificate. Automation is the only viable approach at scale.

Private key protection. The certificate is public. The private key is the secret that must be protected. A private key stored in plaintext on a file share, committed to a code repository, or shared between servers without access controls is a compromised private key. Private keys should be stored in HSMs, TPMs, or managed key vaults. Certificate management platforms automate key generation and storage, reducing the risk of key exposure.

Why It Matters

TLS Underpins Everything

Every HTTPS connection, every TLS-encrypted API call, every VPN tunnel, and every encrypted email depends on certificates. A certificate failure (expiration, misconfiguration, revocation) disrupts the encrypted communication that every modern application depends on. Certificate management is infrastructure management: invisible when it works, service-disrupting when it fails.

Authentication and Zero Trust

Certificates are the strongest authentication mechanism available. Certificate-based authentication (mTLS, EAP-TLS, smart card) is phishing-resistant (the private key never leaves the secure store), replay-resistant (each authentication uses a unique challenge-response), and does not depend on shared secrets (no password to steal). Zero trust architectures use certificates for service-to-service authentication (mTLS in service mesh), device authentication (managed device certificates), and user authentication (smart cards, passkeys backed by certificates).

Compliance

Certificate management is addressed by multiple compliance frameworks. PCI DSS Requirement 4 mandates encryption of cardholder data in transit using strong cryptography and valid certificates. NIST CSF 2.0 PR.DS includes encryption controls. ISO 27001 A.8.24 addresses cryptographic controls including certificate management. SOC 2 CC6.1 includes encryption of data in transit.

Related Articles

• Cryptographic Key Management
• Encryption at Rest and in Transit
• Zero Trust Architecture
• Active Directory Security
• Wireless Network Security
• Data Protection and Sovereignty (DPS): The Geological Core

Sources

1. Internet Engineering Task Force. "RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile." IETF, May 2008.
2. Internet Engineering Task Force. "RFC 8555: Automatic Certificate Management Environment (ACME)." IETF, March 2019.
3. SpecterOps. "Certified Pre-Owned: Abusing Active Directory Certificate Services." SpecterOps, June 2021 (updated 2024).
4. Let's Encrypt. "Let's Encrypt Statistics and Documentation." letsencrypt.org, updated continuously.
5. National Institute of Standards and Technology (NIST). "Cybersecurity Framework (CSF) 2.0: PR.DS (Data Security)." U.S. Department of Commerce, 2024.

Word count: 1,983