The 2025 Certificate Authority Security Assessment Checklist: Surviving the 90-Day Era and PQC

Public Key Infrastructure (PKI) and Certificate Authorities (CAs) are the foundational trust mechanisms holding together Zero Trust Architecture, IoT device security, and secure software supply chains. But if you are still treating your CA security assessment as a static, check-the-box annual audit, your infrastructure is already falling behind.

The 2024-2025 landscape has fundamentally altered how we must approach certificate security. Google’s push to reduce maximum public TLS certificate validity from 398 days to 90 days is forcing a massive shift toward absolute automation. Simultaneously, the finalization of NIST's Post-Quantum Cryptography (PQC) standards (FIPS 203, 204, and 205) means your cryptographic infrastructure is officially on a ticking clock.

Furthermore, browser root programs have lost their patience. The 2024 distrust of Entrust certificates by Google Chrome and Mozilla proved that no CA is "too big to fail." A pattern of compliance failures and delayed incident reporting will result in total excommunication from the trusted web.

Whether you are managing an internal Private CA for your Kubernetes clusters using HashiCorp Vault, or preparing your enterprise for the impending 90-day reality, this comprehensive Certificate Authority Security Assessment Checklist will help you harden your infrastructure against modern threats.

1. Physical & Hardware Security (The Root of Trust)

For any CA, the private key is the literal keys to the kingdom. If the Root CA key is compromised, every single certificate issued beneath it is invalidated.

• Hardware Security Modules (HSMs): Are your root and issuing keys generated and stored within certified HSMs? For enterprise environments, you must ensure your HSMs meet FIPS 140-2 or FIPS 140-3 Level 3 certification. This ensures physical tamper-resistance and cryptographic isolation. Cloud-native teams should be leveraging managed HSMs like AWS CloudHSM or Azure Key Vault Managed HSM.
• Strict Air-Gapping: Is your Root CA strictly offline? A Root CA should only be powered on during a formal key signing ceremony to sign a Subordinate (Issuing) CA or a Certificate Revocation List (CRL). It should reside in a physically secure vault, often requiring biometric access and protected by a Faraday cage.
• Multi-Person Control (Quorum): Never allow a single administrator to activate a CA key. Implement "m-of-n" access controls (e.g., requiring 3 out of 5 designated key custodians to present physical smart cards to unlock the HSM).

2. Logical Security & Access Control

While the Root CA is offline, your Issuing CAs are connected to the network and highly vulnerable to lateral movement from attackers.

• Privileged Access Management (PAM): Direct SSH or RDP access to CA servers should be disabled. All administration interfaces must be protected by a PAM solution that enforces Multi-Factor Authentication (MFA), limits session duration, and records session activity for auditing.
• Role-Based Access Control (RBAC): Enforce strict separation of duties. The engineer who configures the CA (CA Administrator) should not be the same person who approves certificate requests (Certificate Manager), nor the person who reviews the logs (Auditor).
• Network Segmentation: Issuing CAs must reside in highly restricted network enclaves. Use strict firewall rules to ensure the CA only communicates with approved endpoints (like an ACME server or an API gateway).

3. Cryptographic Controls & Key Management

Cryptographic standards decay over time. What was secure in 2015 is vulnerable today.

• Algorithm Strength: Ensure your CAs are enforcing modern key lengths. RSA keys must be at least 3072-bit (though 4096-bit is strongly recommended for Root CAs). If using Elliptic Curve Cryptography (ECC), enforce at least NIST P-384.
• Crypto-Agility: This is the most critical check for 2025. Can your CA infrastructure issue hybrid certificates that combine classical algorithms (like ECC) with new quantum-resistant algorithms (like ML-KEM)? If your PKI relies on hardcoded cryptographic assumptions, the PQC migration will break your infrastructure.
• Key Generation Ceremonies: Root CA key generation must be a heavily scripted, video-recorded event audited by independent third parties, adhering strictly to the CA/Browser Forum Baseline Requirements.

Practical Audit Check: Inspecting Internal CA Strength

You can quickly audit an internal CA certificate's cryptographic strength using OpenSSL. Run this command against your internal Root or Subordinate CA:

openssl x509 -in internal-root-ca.crt -text -noout | grep -E "Public-Key|Signature Algorithm|Not After"

Expected Output: You want to see Signature Algorithm: sha256WithRSAEncryption (or stronger, like SHA-384) and a Public-Key of (4096 bit).

4. Operational & Lifecycle Management

Operational failures cause far more outages than cryptographic breaks. The Let's Encrypt TLS-ALPN-01 incident of 2022—where millions of certificates had to be revoked and reissued within 5 days due to a validation bug—proved that rapid revocation and automated reissuance are non-negotiable.

• Revocation Infrastructure: Are your OCSP (Online Certificate Status Protocol) responders and CRL distribution points highly available? If your OCSP responder goes down, browsers may hard-fail, taking your applications offline. Place OCSP responders behind robust CDNs to protect against DDoS attacks.
• Logging & Monitoring: All CA events (successful issuance, failed requests, key access) must be forwarded to an immutable Security Information and Event Management (SIEM) system. Configure immediate alerts for any unauthorized issuance attempts.
• Automated Certificate Lifecycle Management (CLM): With 90-day lifespans approaching, manual tracking via spreadsheets is professional negligence. You must implement continuous discovery and tracking.

Common CA Pitfalls and Real-World Solutions

Pitfall 1: "Shadow PKI" and Rogue Internal CAs

Developers moving fast often spin up self-signed CAs for testing. Eventually, these rogue CAs end up in production environments, completely bypassing corporate security policies.

The Solution: Implement network-wide certificate discovery. You can use tools like nmap alongside testssl.sh to actively scan your internal subnets for rogue certificates. Furthermore, implement Certificate Authority Authorization (CAA) records in your internal DNS to strictly dictate which CAs are authorized to issue certificates for your internal domains.

# Scan a subnet for SSL/TLS services and identify the issuer
nmap -p 443 --script ssl-cert 192.168.1.0/24

Pitfall 2: Outages Due to Expired Internal CA Roots

Organizations routinely forget when their internal Root or Subordinate CA expires. Because these certificates often have 5-to-10 year lifespans, the original engineers who deployed them have usually left the company by the time they expire, leading to catastrophic, enterprise-wide outages.

The Solution: You need dedicated, proactive monitoring that extends beyond simple endpoint checks. This is exactly where Expiring.at becomes critical to your infrastructure. By tracking the entire certificate chain—from the leaf certificate up to the internal root—Expiring.at ensures your DevOps and Security teams receive actionable alerts months before a core infrastructure certificate expires, giving you ample time to orchestrate a complex root rotation.

Pitfall 3: Weak Domain Validation

Relying on outdated domain validation methods (like simple HTTP-01 checks from a single location or email-based validation) makes your infrastructure susceptible to BGP hijacking.

The Solution: Enforce Multi-Perspective Domain Validation. Ensure your internal ACME servers and public CA providers are checking domain control from multiple geographic network vantage points, as now mandated by recent CAB Forum updates.

Automating the Chaos: Embracing ACME

To survive the 90-day certificate lifespan, your internal PKI must operate exactly like Let's Encrypt. You must deploy the Automated Certificate Management Environment (ACME - RFC 8555) protocol across your enterprise.

If you are running an internal CA using a tool like Smallstep (step-ca) or HashiCorp Vault, you can easily enable ACME endpoints. Once enabled, your servers can automatically request, validate, and renew their own certificates without human intervention.

Here is a practical example of how a server requests an internal certificate using certbot pointed at an internal ACME CA:

# Requesting a certificate from an internal ACME-enabled CA
REQUEST_DOMAIN="internal-api.company.local"
INTERNAL_ACME_URL="https://ca.company.local/acme/acme/directory"

certbot certonly --standalone \
  --server $INTERNAL_ACME_URL \
  --domain $REQUEST_DOMAIN \
  --email security@company.local \
  --agree-tos \
  --non-interactive

By pairing automated issuance (via ACME) with automated expiration tracking (via Expiring.at), you create a self-healing PKI environment. The ACME client handles the routine 60-day renewals, while Expiring.at acts as your safety net, alerting you instantly if an automation script fails, a cron job dies, or an underlying Subordinate CA is approaching the end of its life.

Conclusion & Next Steps

A Certificate Authority Security Assessment is no longer just about checking the physical locks on your server room door. In 2025, a secure CA environment is defined by its crypto-agility, its automation capabilities, and its operational transparency.

To secure your infrastructure today:
1. Audit your algorithms: Ensure no legacy systems are relying on RSA-2048 or SHA-1, and begin mapping out your migration to Post-Quantum Cryptography.
2. Kill the spreadsheet: If you are tracking any certificates in Excel, stop. Implement robust discovery and lifecycle management.
3. Monitor the whole chain: Don't just monitor your public-facing web servers. Use [Expiring.at](https