A Practical Security Assessment Checklist for Internal Certificate Authorities

Public Key Infrastructure (PKI) and Certificate Authorities (CAs) form the foundational trust layer of modern IT. They secure web traffic, authenticate machine identities, sign code, and enable Zero Trust architectures. Yet, internal enterprise CAs are often deployed once, loosely configured, and largely forgotten until a catastrophic failure or security breach occurs.

The landscape of certificate management is currently undergoing a massive shift. Machine identities now outnumber human identities by a factor of 45 to 1, according to recent industry research. Simultaneously, the impending industry push toward 90-day maximum lifespans for public TLS certificates is forcing organizations to re-evaluate their internal PKI capabilities.

If your organization relies on legacy on-premises PKI—particularly Microsoft Active Directory Certificate Services (ADCS)—your infrastructure requires a rigorous security assessment. This checklist provides a comprehensive framework for auditing your CA architecture, access controls, lifecycle management, and monitoring systems.

The Danger of Default Configurations: The ADCS Threat

Before diving into the checklist, it is critical to understand why CA assessments are suddenly a top priority for security teams.

Microsoft ADCS is the most common enterprise CA, but its default configurations and complex template permission structures make it a prime target for attackers. Security researchers at SpecterOps published a landmark paper detailing multiple escalation paths (dubbed ESC1 through ESC14) where misconfigured certificate templates allow standard users to escalate privileges to Domain Admin in minutes.

Ransomware groups like LockBit and ALPHV actively weaponize these misconfigurations. The most common attack vector, ESC1, occurs when a certificate template allows the requester to specify a Subject Alternative Name (SAN) and is configured for client authentication.

An attacker can use tools like Certify to find these vulnerable templates:

# Finding vulnerable ADCS templates using Certify
Certify.exe find /vulnerable

If an overly permissive template is found, the attacker simply requests a certificate while supplying the SAN of a highly privileged account (like a Domain Administrator):

# Requesting a certificate as the Domain Admin
Certify.exe request /ca:SERVER\CA-NAME /template:VulnerableTemplate /altname:DomainAdmin

Once the certificate is issued, the attacker uses PKINIT to request a Ticket Granting Ticket (TGT) and compromise the entire Active Directory domain. Preventing this requires treating your internal CA with the same rigor as a public Root CA.

Phase 1: Architecture and Cryptographic Design

The foundation of a secure CA lies in its physical and logical architecture. A compromised Root CA private key means the complete loss of trust across your entire environment.

• [ ] Verify the Root CA is strictly offline. The Root CA should never be connected to a network. It should be a standalone machine, physically secured, and only powered on to sign Subordinate Issuing CAs or generate Certificate Revocation Lists (CRLs).
• [ ] Enforce a tiered hierarchy. Never issue end-entity certificates (like web server or user certificates) directly from the Root CA. Implement at least a two-tier (Root -> Issuing) or three-tier (Root -> Policy -> Issuing) architecture.
• [ ] Mandate Hardware Security Modules (HSMs). All CA private keys must be generated and stored within an HSM certified to FIPS 140-2 or 140-3 Level 3. This ensures the key cannot be exported or copied. Cloud-native environments can utilize services like AWS CloudHSM or Azure Key Vault Managed HSM.
• [ ] Assess cryptographic agility and standards. Ensure your CA uses modern cryptographic standards (minimum RSA 3072-bit or ECDSA P-256/P-384 with SHA-256 hashing). Furthermore, assess your readiness for Post-Quantum Cryptography (PQC). With NIST finalizing FIPS 203, 204, and 205, your CA infrastructure must be capable of issuing hybrid certificates without breaking existing clients.

Phase 2: Access Control and Physical Security

Because the CA dictates trust, access to its management interfaces must be heavily restricted and audited.

• [ ] Implement M-of-N Control (Key Ceremonies). Accessing the offline Root CA should require multiple authorized individuals. For example, a 3-of-5 configuration means three out of five designated key holders must physically present their smart cards to unlock the HSM and boot the CA.
• [ ] Secure physical vaulting. The offline Root CA hardware and associated physical tokens must be stored in a secure safe within a facility controlled by biometric access and continuous video surveillance.
• [ ] Enforce strict Role-Based Access Control (RBAC). CA management roles must be explicitly separated. The person who configures the CA (CA Administrator) should not be the same person who approves certificate requests (Certificate Manager) or reviews the logs (Auditor).
• [ ] Classify the CA as a Tier 0 asset. In an Active Directory environment, the CA server must be treated as a Tier 0 identity asset. Only Tier 0 administrators should have logon rights. Disable NTLM authentication on CA web enrollment interfaces to prevent relay attacks.

Phase 3: Certificate Lifecycle and Issuance

The days of manually tracking five-year certificates in a spreadsheet are over. Automation and strict issuance policies are mandatory for survival in modern infrastructure.

• [ ] Audit certificate template permissions. Review all templates to ensure requesters cannot supply their own Subject Alternative Names (SANs) unless explicitly authorized and tightly scoped. Disable the ENROLLEE_SUPPLIES_SUBJECT flag on any template used for authentication.
• [ ] Validate automated revocation mechanisms. Ensure Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP) responders are highly available. If an issuing CA is compromised, you must be able to revoke its certificates immediately. You can test your OCSP responder using OpenSSL:

# Testing an OCSP responder for a specific certificate
openssl ocsp -issuer issuing_ca.pem -cert server_cert.pem \
  -url http://ocsp.yourdomain.internal -header "HOST" "ocsp.yourdomain.internal"

• [ ] Enforce short validity periods. Restrict end-entity certificates to the shortest viable lifespan. Web servers should use 30 to 90-day certificates, while microservices and containers should use certificates valid for only hours or minutes.
• [ ] Implement Certificate Lifecycle Management (CLM). Migrate away from manual provisioning. Use standard protocols like ACME (Automated Certificate Management Environment), SCEP, or EST to automate issuance and renewal.

For modern, cloud-native environments, consider augmenting or replacing legacy ADCS with dynamic PKI solutions like HashiCorp Vault or Smallstep. Vault, for instance, makes it trivial to issue short-lived certificates via its PKI secrets engine:

# Generating a 24-hour certificate via HashiCorp Vault
vault write pki_int/issue/web-servers \
    common_name="app.internal.domain" \
    ttl="24h"

Phase 4: Auditing, Logging, and Monitoring

A secure CA is a highly monitored CA. Without proper visibility, misconfigurations will go unnoticed until they cause an outage or a breach.

• [ ] Configure immutable logging. Forward all CA logs—including issuance requests, template modifications, and failed authentication attempts—to a centralized, tamper-proof SIEM (Security Information and Event Management) system.
• [ ] Build anomaly detection alerts. Configure your SIEM to alert on unusual issuance volumes, requests for highly privileged templates, or certificates requested during off-hours.
• [ ] Implement out-of-band expiration monitoring. Automated issuance via ACME is critical, but automation can and will fail. Cron jobs die, firewall rules change, and DNS validation records get accidentally deleted. You must maintain independent, out-of-band monitoring to catch expiring certificates before they cause downtime.

This is where integrating a dedicated monitoring platform like Expiring.at becomes essential. While your internal CLM handles the issuance, Expiring.at acts as the failsafe, actively probing your endpoints and alerting your team via Slack, PagerDuty, or email when a certificate is approaching expiration and the automated renewal process has failed.

Lessons from Real-World Incidents

When assessing your CA, it helps to look at recent high-profile incidents to understand what goes wrong when PKI is mismanaged:

1. The Starlink Global Outage (2023): A massive outage took down Starlink satellite internet for hours. The root cause was a single expired certificate in their ground station infrastructure. The Takeaway: Lack of automated lifecycle management and independent expiration monitoring bypasses even the most advanced technology stacks.
2. Let's Encrypt Mass Revocations: Due to minor compliance bugs in their issuance code, Let's Encrypt has occasionally had to revoke millions of certificates with only a few days' notice. *The Takeaway: