The 2025 Certificate Authority Security Assessment: Surviving the 90-Day Cliff and Post-Quantum Shift
The era of "set it and forget it" for SSL/TLS certificates is officially over. For nearly a decade, the security industry has treated Certificate Authorities (CAs) as static infrastructure—secure vaults that issue digital identities once a year. However, the landscape has shifted violently in the last 12 months. Between Google’s proposal to reduce certificate validity to 90 days, the distrust of major legacy providers like Entrust, and the NIST standardization of Post-Quantum Cryptography (PQC), the requirements for a secure CA have fundamentally changed.
A security assessment checklist from 2022 is already obsolete. Today, assessing a Certificate Authority—whether it is a public vendor or your own internal Private PKI—is no longer just about key storage; it is an assessment of automation, agility, and supply chain integrity.
This guide provides a comprehensive technical framework for assessing CA security in the modern DevOps landscape, moving beyond basic compliance to address the operational realities of 2025.
The New Threat Landscape: Why Legacy Checklists Fail
Before diving into the technical assessment, it is critical to understand why traditional audit methods are failing. In mid-2024, the industry witnessed the collapse of trust in Entrust, a titan of the CA world. Google Chrome and Mozilla announced they would distrust Entrust certificates issued after October 31, 2024.
The reason wasn't a catastrophic key compromise. It was a pattern of compliance failures and, crucially, an inability to revoke non-compliant certificates within the mandated timelines (often 24 hours to 5 days).
Simultaneously, the "90-Day Validity" paradigm shift is looming. When (not if) this becomes the standard, organizations relying on manual spreadsheets or calendar reminders will face a 400% increase in workload and a corresponding spike in outage risks.
Therefore, this assessment checklist is divided into three critical pillars: Governance, Infrastructure, and Lifecycle Automation.
Phase 1: Governance and Policy Integrity
The foundation of any PKI (Public Key Infrastructure) is not hardware, but policy. If the rules governing the CA are weak, the strongest cryptography in the world cannot save you.
1. CP/CPS Alignment and The "Two-Person" Rule
Every CA must have a Certificate Policy (CP) and Certification Practice Statement (CPS). In a modern assessment, you must verify that these documents align with the CA/Browser Forum Baseline Requirements (v2.0+).
The Assessment Step:
Verify the enforcement of "Multi-Person Control" (often called m-of-n control) for the Root CA. No single individual should have the ability to access the Root CA private key.
- Requirement: Accessing the Root CA requires $m$ out of $n$ authorized administrators (e.g., 3 out of 5) to be physically present.
- Verification: Review the Key Ceremony logs. Were the smart cards or tokens distributed to different individuals? Are those tokens stored in separate physical safes?
2. Role Separation
In many DevOps environments, the engineer who manages the deployment pipeline often has access to the signing keys. This is a critical failure point.
The Assessment Step:
Check for strict separation of duties.
* Requester: Can request a certificate (e.g., a web server admin).
* Approver: Validates the request (e.g., a security officer).
* Auditor: Reviews the logs but cannot issue certs.
If your internal CA allows an automated pipeline to request and approve a certificate without policy constraints, you have created a vulnerability where a compromised CI/CD pipeline can mint valid credentials for any internal service.
Phase 2: Infrastructure and Key Management
This phase focuses on the tangible security of the cryptographic material.
1. Root CA Isolation (Air-Gapping)
The Root CA is the anchor of trust. If it is compromised, every certificate it has ever issued is untrustworthy.
The Assessment Step:
Verify that the Root CA is strictly offline. It should never have a network cable attached. It should reside on a dedicated machine that is powered off and locked in a safe when not in use. Data transfer (e.g., passing a signed Sub-CA certificate back to the network) must be done via a formatted, one-way media transfer method to prevent network bridging.
2. HSM Compliance
Storing private keys on a disk (even an encrypted one) is unacceptable for a CA. Keys must be generated and stored inside a Hardware Security Module (HSM).
The Assessment Step:
Confirm the HSM rating.
* Standard: FIPS 140-2 Level 3 or Common Criteria EAL 4+.
* Why Level 3? Level 3 requires physical tamper resistance. If an attacker tries to drill into the appliance or dissolve the casing with acid, the HSM detects the intrusion and zeroizes (erases) the keys immediately.
3. Network Segmentation for Issuing CAs
While the Root CA is offline, the Issuing CA (Sub-CA) must be online to service requests. However, it should not be exposed to the general corporate network.
The Assessment Step:
Perform a port scan on your internal Issuing CA.
# Example Nmap scan to verify firewall rules
nmap -p- -sV 192.168.10.5 --reason
Expected Result: You should ONLY see the specific ports required for enrollment protocols (e.g., TCP 443 for HTTPS/ACME, or TCP 80 for CRL distribution). If you see RDP (3389) or SSH (22) exposed to the general subnet, the assessment fails.
Phase 3: Operational Agility and Automation
This is the most significant addition to the 2025 checklist. A CA that is secure but manual is a liability.
1. The Automation Mandate (ACME Protocol)
With the shift to 90-day validity, a CA must support the ACME (Automated Certificate Management Environment) protocol. Proprietary APIs are often difficult to maintain and integrate with open-source tools.
The Assessment Step:
Does the CA natively support ACME? Can you use standard clients like Certbot or lego to request certificates without human intervention?
Implementation Example:
Test the CA's ability to handle an automated renewal. A healthy CA infrastructure should allow a client to renew a certificate simply by running:
certbot renew --server https://ca.internal.example.com/acme/directory --dry-run
If your assessment reveals that administrators are manually generating CSRs (Certificate Signing Requests) and pasting them into a web portal, the CA receives a failing grade for operational agility.
2. Revocation Speed and CRL Availability
In July 2024, DigiCert had to revoke thousands of certificates due to a minor validation bug. Customers who couldn't process these revocations and re-issues immediately faced outages.
The Assessment Step:
* OCSP Availability: Is the Online Certificate Status Protocol (OCSP) responder highly available? Is it behind a Load Balancer or CDN?
* Stapling: Does the infrastructure support OCSP Stapling to reduce the burden on the responder and improve privacy?
3. Shadow IT Discovery
You cannot assess what you cannot see. A major risk in modern architectures is "Shadow PKI"—developers spinning up self-signed CAs using tools like OpenSSL or HashiCorp Vault without central governance.
The Assessment Step:
Regularly scan the network for unknown CAs. Tools like zgrab2 or standard openssl scripts can help identify the issuer of certificates on your network.
# Script to check the Issuer of a remote certificate
echo | openssl s_client -connect internal-app.example.com:443 2>/dev/null | openssl x509 -noout -issuer
If the output reveals an issuer name that isn't in your approved list (e.g., "DevOps Temporary CA" or "Minikube CA"), you have a governance breach.
Phase 4: Post-Quantum Readiness
In August 2024, NIST finalized the standards for Post-Quantum Cryptography (ML-KEM, ML-DSA, and SLH-DSA). While full migration will take years, the threat of "Harvest Now, Decrypt Later" is real today. Attackers are recording encrypted traffic now to decrypt it once quantum computers become viable.
The Assessment Step:
Ask your CA provider (or internal PKI team) for their PQC roadmap.
1. Hybrid Certificates: Does the CA support hybrid certificates that contain both traditional (RSA/ECC) and PQC keys?
2. Crypto-Agility: If RSA-2048 is suddenly broken, how long would it take to re-issue every certificate in the organization?
If the answer is "weeks" or "months," the organization lacks the crypto-agility required for the modern threat landscape.
Technical Solution: Monitoring and Lifecycle Management
Conducting this assessment is only the first step. The ongoing challenge is maintaining this state of security. This is where dedicated monitoring becomes essential.
The Role of Certificate Monitoring
Relying on the CA's own email alerts is insufficient. You need an external "watchdog" that monitors your public and private endpoints. This is where tools like Expiring.at provide critical visibility.
Unlike basic calendar reminders, modern monitoring tools must:
1. Check the Chain: Verify that not just the leaf certificate, but the intermediate and root are valid.
2. Validate configuration: Ensure the server is sending the correct intermediate certificates (fixing the "incomplete chain" error).
3. Monitor multiple ports: SSL isn't just on port 443. It's on 8443 (Tomcat), 5432 (Postgres), and 636 (LDAP).
Implementing a "Watchdog" Strategy
A robust security posture involves "trust but verify." Even if your automated ACME bot says it renewed the certificate, did the web server actually reload the configuration?
Scenario:
1. Certbot renews the certificate on disk at 02:00 AM.
2. Nginx fails to reload due to a syntax error in a config file.
3. The web server continues serving the old, expiring certificate.
4. The CA dashboard says "Renewed," but the world sees "Expired."
This is why external monitoring is mandatory. By pointing a monitoring service at your endpoints, you validate the running state, not just the file system state.
Best Practices and Remediation
If your assessment uncovers gaps, prioritize remediation based on impact:
- Immediate Action: Move any software-based Root CA keys to an offline, air-gapped environment immediately. If you are using a self-signed root generated on a laptop, consider that PKI compromised and rebuild it.
- Short Term (1-3 Months): Implement ACME for all internal endpoints. Eliminate manual CSR generation.
- Medium Term (3-6 Months): Integrate a Certificate Lifecycle Management (CLM) tool or a robust monitoring solution like Expiring.at to catch shadow IT