How to Conduct a Certificate Authority Security Assessment

Certificate Authorities (CAs) are the foundational trust anchors of your infrastructure. Whether you are operating a public-facing PKI or managing internal machine identities via Microsoft Active Directory Certificate Services (ADCS) and HashiCorp Vault, the security of your CA dictates the security of your entire network.

Recent industry events have proven that failing to rigorously assess and secure CA infrastructure carries catastrophic consequences. In 2024, Google and Mozilla announced the distrust of Entrust's root certificates following a pattern of compliance failures. Around the same time, a domain validation bug forced DigiCert to revoke over 83,000 certificates within a strict 24-hour window, while a breach at AnyDesk compromised their production code-signing certificates.

Furthermore, with the upcoming industry shift toward 90-day maximum certificate lifespans and the finalization of NIST's Post-Quantum Cryptography (PQC) standards, CA management is undergoing a massive transformation. A modern CA security assessment must evaluate not just physical and logical security, but also automation capabilities and crypto-agility.

This guide outlines the critical technical domains you must evaluate when conducting a comprehensive Certificate Authority security assessment.

Phase 1: Physical Security and Hardware Infrastructure

The compromise of a Root CA private key is an unrecoverable event. To prevent this, your assessment must verify that the physical infrastructure hosting the root key is isolated and heavily fortified.

Validating the Offline Root CA

Your Root CA should never be connected to a network. It exists solely to sign the certificates of Subordinate (Issuing) CAs and should remain powered down in a physically secure location when not in use.

During an assessment, verify that:
1. The Root CA server lacks network interfaces (no Ethernet cables, disabled Wi-Fi/Bluetooth modules).
2. The server is stored in a secure vault, such as a Faraday cage or a GSA-approved safe.
3. Physical access requires tiered controls, including mantrap doors, biometric scanners, and CCTV coverage with at least 90 days of immutable retention.

Hardware Security Module (HSM) Compliance

Private keys must never reside in plain text on a server's hard drive. They must be generated and stored within a Hardware Security Module (HSM). Evaluate your infrastructure to ensure all CA keys are protected by HSMs certified to at least FIPS 140-2 (or 140-3) Level 3.

Whether you are using on-premise appliances like Thales Luna or cloud-native solutions like AWS CloudHSM, the assessment must confirm that the HSMs are configured in strict FIPS mode and that keys cannot be exported in plaintext under any circumstances.

Phase 2: Logical Security and Access Management

Physical security is only half the battle. Logical access controls ensure that even if an attacker breaches the network perimeter, they cannot issue fraudulent certificates or access the Issuing CA's signing keys.

Implementing Multi-Party Computation (Quorum)

No single individual should have the ability to bring the Root CA online, access the HSM, or unseal the CA software. Your assessment should verify the implementation of an M-of-N quorum system (e.g., requiring 3 out of 5 key custodians to present physical smart cards to authorize an action).

If you are using HashiCorp Vault as an internal CA, this concept is implemented via Shamir's Secret Sharing during initialization. You can verify the quorum configuration by examining the initialization parameters:

# Example of initializing Vault with a 3-of-5 quorum
vault operator init -key-shares=5 -key-threshold=3

During the assessment, confirm that the unseal keys (or physical smart cards for hardware CAs) are distributed among different individuals across different departments, preventing collusion.

Role-Based Access Control (RBAC) and MFA

Verify that strict separation of duties is enforced. The individual who configures the CA (Administrator) must not be the same person who approves certificate requests (Certificate Manager) or reviews the logs (Auditor).

Furthermore, all logical access to the Issuing CA environment must be protected by phishing-resistant Multi-Factor Authentication (MFA), such as FIDO2/WebAuthn hardware keys.

Phase 3: Cryptographic Controls and Crypto-Agility

An effective assessment looks at both current cryptographic strength and future readiness. Cryptographic algorithms weaken over time as computing power increases.

Deprecating Legacy Algorithms

Ensure that legacy algorithms like SHA-1 and RSA-2048 have been entirely deprecated across your PKI. The current baseline requires at least RSA-3072 or Elliptic Curve Cryptography (ECC) using curves like NIST P-256 or P-384.

You can audit the signature algorithms of your currently issued certificates using OpenSSL. Run this check against your internal endpoints to identify weak cryptography:

# Check the signature algorithm and key size of a certificate
openssl x509 -in internal-service-cert.pem -text -noout | grep -E "Signature Algorithm|Public-Key"

# Expected output:
# Signature Algorithm: ecdsa-with-SHA384
# Public-Key: (384 bit)

Assessing Post-Quantum Readiness

In August 2024, NIST finalized the first set of Post-Quantum Cryptography standards, including FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA). A modern CA assessment must evaluate "crypto-agility"—the ability of the CA infrastructure to seamlessly transition to these quantum-resistant algorithms.

Review your PKI vendor's roadmap. If your internal CA software cannot support hybrid certificates (combining classical ECC/RSA signatures with ML-DSA signatures), you must flag this as a critical long-term risk and begin planning a migration to a more agile PKI platform.

Phase 4: Certificate Lifecycle and Automation

With public TLS certificate lifespans shrinking to 90 days, manual certificate management is a massive operational liability. The DigiCert incident of 2024—which required customers to replace thousands of certificates within 24 hours—demonstrated that automation is no longer optional.

Evaluating ACME and Automated Issuance

Your assessment must verify that the CA supports automated issuance protocols like ACME (Automated Certificate Management Environment), SCEP, or EST.

For Kubernetes environments, verify that tools like cert-manager are configured to automatically request and renew certificates from your internal CA well before expiration. A healthy configuration should look similar to this ACME Issuer:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: internal-ca-issuer
spec:
  acme:
    server: https://ca.internal.example.com/acme/directory
    email: pki-alerts@example.com
    privateKeySecretRef:
      name: internal-ca-account-key
    solvers:
    - http01:
        ingress:
          class: nginx

Revocation Infrastructure Availability

If a private key is compromised, the CA must be able to publish revocation data instantly. Assess the high availability and response times of your Online Certificate Status Protocol (OCSP) responders and Certificate Revocation Lists (CRLs). The CA/Browser Forum Baseline Requirements mandate that critical compromises be reflected in revocation data within 24 hours. Your internal SLAs should be just as strict.

Independent Expiration Monitoring

Automation is powerful, but cron jobs fail, webhooks time out, and API tokens expire. A critical component of your CA assessment is ensuring you have independent, external monitoring that verifies certificates are actually being renewed on the endpoints.

This is where Expiring.at becomes an essential part of your infrastructure. By configuring Expiring.at to monitor your endpoints, you create a fail-safe layer. If your ACME client fails to renew a certificate, Expiring.at will detect the approaching expiration date and alert your DevOps team via Slack, email, or PagerDuty before the certificate expires and causes a production outage.

Phase 5: Audit, Logging, and Linting

The final phase of the assessment ensures that all CA activities are transparent, verifiable, and compliant with industry standards (such as WebTrust for CAs or ETSI EN 319 411).

Immutable Logging and Anomaly Detection

Every action taken by the CA—key generation, certificate issuance, revocation, and failed authentication attempts—must be logged. Assess your logging architecture to ensure these logs are forwarded to an immutable, append-only SIEM (Security Information and Event Management) system.

Configure anomaly detection rules within your SIEM. For example, your internal CA should never issue a