The 2025 Certificate Authority Security Assessment Checklist: Surviving 90-Day Lifespans and Quantum Threats

The landscape of Public Key Infrastructure (PKI) and Certificate Authorities (CAs) is undergoing a seismic shift. For decades, managing certificates was treated as a routine, albeit tedious, IT operations task. Today, driven by the exponential growth of machine identities, the looming transition to Post-Quantum Cryptography (PQC), and aggressive new baseline requirements from major browsers, CA security has become a critical pillar of Zero Trust Architecture (ZTA).

If your organization operates an internal CA, relies heavily on public trust providers, or manages dynamic microservices, the rules of engagement have changed. Google's proposal to reduce the maximum validity of public TLS certificates from 398 days to just 90 days means manual certificate management is officially dead. Furthermore, the high-profile distrust of legacy CAs like Entrust by major browsers in 2024 proves that no authority is "too big to fail" when it comes to compliance and security audits.

Whether you are auditing a third-party vendor or securing your internal PKI, this comprehensive Certificate Authority Security Assessment Checklist will ensure your infrastructure is resilient, automated, and ready for the challenges of 2025.

The Four Pillars of CA Security Assessment

A rigorous CA assessment extends far beyond checking expiration dates. It requires deep inspection across physical hardware, logical access, cryptographic standards, and operational lifecycle management.

A. Physical & Hardware Security

The foundation of any CA is the protection of its private keys. If a Root CA key is compromised, the entire chain of trust collapses, allowing attackers to forge identities, intercept encrypted traffic, and bypass authentication mechanisms entirely.

• Hardware Security Modules (HSMs): Are all CA private keys generated and stored within a dedicated HSM? Software-based key storage is unacceptable for production CAs. Your assessment should verify that the HSM meets FIPS 140-2 or FIPS 140-3 Level 3 standards, which mandate physical tamper-resistance and identity-based authentication.
• The Offline Root CA: The Root CA must be physically air-gapped, powered off, and stored in a secure vault. It should only be brought online during highly controlled key ceremonies to sign Subordinate (Issuing) CAs or Certificate Revocation Lists (CRLs).
• Tiered Access Control: Physical access to the CA hardware must require multi-person integrity. Implementing an "M-of-N" access control scheme (e.g., requiring 3 out of 5 authorized key holders to be physically present with smart cards) prevents unilateral rogue actions.
• Environmental Resilience: The physical facility housing the online Issuing CAs must be protected against fire, flood, and power loss, with tested redundant systems in place.

B. Logical Security & Zero Trust Access

Once physical security is established, you must defend the CA against network-based attacks and lateral movement.

• Strict Network Segmentation: Online Issuing CAs must reside in highly restricted network enclaves. Firewalls should operate on a strict "Deny All" default, only permitting necessary inbound traffic (like API requests for issuance) and explicitly required outbound traffic.
• Role-Based Access Control (RBAC): Administrative roles within the CA environment must be strictly segregated. The System Administrator, Security Officer, Internal Auditor, and Key Manager must be different individuals. No single account should have end-to-end control over the CA configuration.
• Phishing-Resistant MFA: Passwords are insufficient for CA administration. Enforce phishing-resistant Multi-Factor Authentication, such as FIDO2/WebAuthn hardware keys, for all logical access to the CA infrastructure.
• Micro-segmentation: Apply Zero Trust principles to prevent lateral movement. If an attacker breaches a web server in your DMZ, they should hit an impenetrable wall when attempting to scan or access the CA subnet.

C. Cryptographic Controls & Crypto-Agility

With NIST finalizing the first three Post-Quantum Cryptography standards (FIPS 203, 204, and 205) in August 2024, assessing a CA's cryptographic posture is no longer just about checking RSA key sizes.

• Modern Cryptographic Baselines: Ensure the CA enforces modern standards for all new issuances. This means a minimum of RSA 3072-bit/4096-bit or Elliptic Curve Digital Signature Algorithm (ECDSA) P-384.
• Crypto-Agility and PQC Readiness: Can your CA infrastructure seamlessly swap out classical algorithms for quantum-resistant ones? A modern assessment must verify if the CA supports hybrid certificates (combining classical and PQC algorithms) to maintain compatibility while transitioning to quantum-safe standards.
• Audited Key Generation Ceremonies: Root CA key generation ceremonies must be meticulously documented, video-recorded, and audited by independent third parties.
• Proactive Key Rotation: There must be a defined, heavily tested process for rotating Issuing CA keys before they expire, as well as an emergency rotation playbook in the event of a suspected compromise.

D. Operational Security & Lifecycle Management

Operational failures are the most common cause of PKI disasters. The push for 90-day lifespans makes automated lifecycle management the most critical operational requirement.

• Automated Issuance Protocols: The CA must support modern automation protocols like ACME (Automated Certificate Management Environment), SCEP, or EST. Manual generation and email distribution of private keys and CSRs (Certificate Signing Requests) is a critical security vulnerability.
• Robust Revocation Infrastructure: Are your OCSP (Online Certificate Status Protocol) and CRL endpoints highly available? If your revocation infrastructure goes offline, browsers may either hard-fail (breaking your applications) or soft-fail (allowing compromised certificates to be trusted). These endpoints must be protected against DDoS attacks.
• Immutable Logging & Auditing: Every CA event—issuance, revocation, configuration changes, and failed access attempts—must be logged to an immutable, centralized SIEM (Security Information and Event Management) system.
• Disaster Recovery (DR): Assess the DR plan. Can the team restore the CA from secure backups to entirely new hardware without compromising key material? This must be tested annually.

Real-World Implementation: Automating the Chaos

To survive the impending 90-day certificate lifecycle, automation is your ultimate safety net. Consider the 2024 Let's Encrypt TLS-ALPN-01 incident. Let's Encrypt discovered a bug in how they validated domain ownership and was forced to revoke over 2 million certificates within 5 days. Because Let's Encrypt forces ACME automation, the vast majority of affected users had their certificates automatically renewed without human intervention.

Here is how you implement that level of resilience in your own infrastructure.

1. Enforcing Certificate Authority Authorization (CAA)

To prevent "Shadow PKI" where developers spin up unauthorized CAs that leak into production, you should enforce CAA records in your DNS. This explicitly tells the world which CAs are allowed to issue certificates for your domain.

Here is an example of implementing CAA records using Terraform for AWS Route53:

resource "aws_route53_record" "caa_record" {
  zone_id = aws_route53_zone.primary.zone_id
  name    = "example.com"
  type    = "CAA"
  ttl     = 300

  records = [
    "0 issue \"letsencrypt.org\"",
    "0 issue \"pki.your-internal-ca.com\"",
    "0 issuewild \";\"", # Disallow wildcard certificates entirely
    "0 iodef \"mailto:security@example.com\"" # Report violations here
  ]
}

2. Automating Issuance with Kubernetes and cert-manager

For cloud-native environments, cert-manager is the industry standard for automating TLS in Kubernetes. By integrating it with an ACME-compliant CA (like Let's Encrypt or an internal Step-CA), you eliminate the risk of manual expiration.

Here is a ClusterIssuer configuration that automates certificate provisioning via ACME:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-production
spec:
  acme:
    # The ACME server URL
    server: https://acme-v02.api.letsencrypt.org/directory
    # Email address used for ACME registration
    email: pki-admin@example.com
    # Name of a secret used to store the ACME account private key
    privateKeySecretRef:
      name: letsencrypt-production-account-key
    # Enable the HTTP-01 challenge provider
    solvers:
    - http01:
        ingress:
          class: nginx

3. Implementing OCSP Stapling

To reduce the load on your CA's revocation infrastructure and improve client privacy and connection speed, implement OCSP Stapling at your web servers. This allows your web server to proactively fetch the OCSP response from the CA and "staple" it to the TLS handshake.

Here is how to configure OCSP Stapling in Nginx:

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate /etc/ssl/certs/example.com.crt;
    ssl_certificate_key /etc/ssl/private/example.com.key;

    # Enable OCSP Stapling
    ssl_stapling on;
    ssl_stapling_verify on;

    # Point to your trusted root/intermediate chain
    ssl_trusted_certificate /etc/ssl/certs/ca-chain.crt;

    # Use a reliable DNS resolver to fetch the OCSP response
    resolver 8.8.8.8 1.1.1.1 valid=300s;
    resolver_timeout 5s;
}

The Blind Spot: Why Automation Isn't Enough

While transitioning to ACME protocols and utilizing tools like HashiCorp Vault for dynamic secrets is mandatory for modern CA operations, automation creates a dangerous new blind spot: Silent Failures.

When a certificate is set to auto-renew every 60 days, your operations team stops looking at it. But what happens when the ACME client crashes? What happens when a firewall rule change blocks outbound traffic to the CA's directory URL? What happens when the API token used by cert-manager expires?

The automation fails silently, and 30 days later, your production application goes offline. Massive service outages caused by expired certificates continue to plague even the most sophisticated tech companies because they trusted their automation blindly.

This is where independent monitoring becomes a critical component of your CA security assessment. You must decouple your monitoring from your issuance infrastructure.

Using a dedicated tracking platform like Expiring.at provides that necessary safety net. By monitoring your endpoints externally, Expiring.at acts as the ultimate source of truth. It doesn't care how the certificate was issued or what automation tool was supposed to renew it; it simply tracks the cryptographic reality of what is currently served to your clients and alerts your team via Slack, Email, or Webhooks