What We Learned from Recent Certificate Authority Compromises

Certificate Authorities (CAs) operate as the foundational trust anchors of the internet. We rely on them to verify identity, secure transit, and maintain the integrity of software ecosystems. When a CA is compromised, or when it fails to adhere to the strict compliance standards governing the industry, the blast radius is massive. It exposes millions of users to Man-in-the-Middle (MitM) attacks, enables malware signing, and inflicts severe reputational damage on the organizations relying on that infrastructure.

Historically, the industry focused on catastrophic, malicious breaches—like the infamous DigiNotar hack of 2011. However, the events of 2024 and 2025 have shifted the narrative. Today, the most pressing threats to certificate infrastructure stem from compliance failures, operational negligence, and the exploitation of internal Public Key Infrastructure (PKI).

Coupled with the industry-wide push toward 90-day certificate lifespans and the impending transition to Post-Quantum Cryptography (PQC), organizations can no longer afford to treat certificate management as a manual, set-and-forget process. Here is a detailed look at recent CA compromises and distrust events, the technical lessons learned, and how engineering teams must adapt their infrastructure.

Compliance Failures Are Security Incidents

The most significant CA event of 2024 was not a malicious hack by a nation-state, but a high-profile distrust event driven by compliance failures. In mid-2024, major browser root programs, including Google and Mozilla, announced they would remove trust for TLS certificates issued by Entrust. For Google Chrome users, this distrust took effect in November 2024.

The root cause was a sustained pattern of operational failures. The CA/Browser (CA/B) Forum Baseline Requirements mandate strict rules for public CAs, including a requirement to revoke misissued certificates within 24 hours. Entrust repeatedly failed to meet these revocation deadlines, delayed incident reporting, and demonstrated a lack of internal controls.

Major browser vendors demonstrated zero tolerance for these violations. The lesson for DevOps and security teams is stark: relying on a single CA is a massive business continuity risk.

When a CA is distrusted, every certificate they issued for your organization becomes invalid in modern browsers, resulting in immediate security warnings and broken API connections. Organizations that relied heavily on manual certificate provisioning found themselves scrambling to replace thousands of certificates across load balancers, web servers, and edge networks before the distrust deadline.

This event cemented the necessity of crypto-agility—the architectural ability to swap out cryptographic primitives, algorithms, and Certificate Authorities instantly and without downtime. If your primary CA is distrusted tomorrow, your infrastructure must be capable of failing over to a secondary CA automatically.

The Illusion of Third-Party Audits

The Entrust incident was preceded by the 2023-2024 distrust of the Turkish CA eTugra by Mozilla and Apple. Security researchers uncovered severe vulnerabilities in eTugra’s systems. Subsequent investigations revealed that despite possessing standard third-party WebTrust audits, the CA suffered from poor internal security controls.

This highlights a critical reality: compliance audits are point-in-time checks and do not guarantee operational security. Enterprises cannot blindly trust that a CA is secure simply because it holds the necessary certifications. Instead, organizations must implement continuous monitoring of Certificate Transparency (CT) logs.

Certificate Transparency is an open framework that requires public CAs to log every certificate they issue to publicly verifiable, append-only ledgers. By actively monitoring these logs using tools like crt.sh or commercial CT monitoring services, security teams can detect rogue or misissued certificates in real-time. If a compromised or negligent CA issues a certificate for your domain, CT log monitoring ensures you are alerted immediately, allowing you to trigger a revocation before attackers can weaponize it.

Internal CAs Are High-Value Targets

While public CA distrust events make headlines, internal CA compromises are actively destroying enterprise networks. Throughout 2023 and 2024, ransomware operators and Advanced Persistent Threat (APT) groups heavily targeted Microsoft Active Directory Certificate Services (AD CS).

Security researchers have categorized a series of AD CS misconfigurations (known as ESC1 through ESC14). These vulnerabilities often stem from overly permissive certificate templates. For example, if a template allows a low-privileged user to request a certificate and specify a Subject Alternative Name (SAN), an attacker can request a client authentication certificate in the name of a Domain Administrator. Once the internal CA issues that certificate, the attacker can use it to authenticate as the Domain Admin, achieving total network compromise in minutes.

The primary lesson here is that internal PKI must be treated as Tier 0 infrastructure. Best practices for securing internal CAs include:

• Offline Root CAs: The Root CA should never be connected to the network. It should only be brought online to sign subordinate issuing CAs.
• Hardware Security Modules (HSMs): Private keys for issuing CAs must be generated and stored within HSMs to prevent exfiltration.
• Strict Template Auditing: Regularly audit AD CS templates using tools like Certify to identify and remediate ESC vulnerabilities.

Defense in Depth: Implementing CAA Records

To mitigate the risk of external CA compromises, organizations must implement Certificate Authority Authorization (CAA) records. A CAA record is a DNS resource record that explicitly dictates which public CAs are authorized to issue certificates for your domain.

If an attacker compromises a CA that is not listed in your CAA record, that CA's systems (if functioning according to Baseline Requirements) will refuse to issue the fraudulent certificate. Furthermore, you can configure CAA records to alert your security team if an unauthorized issuance attempt occurs.

Here is an example of a robust CAA implementation in a DNS zone file:

; Restrict issuance exclusively to Let's Encrypt
example.com.  IN  CAA  0 issue "letsencrypt.org"

; Explicitly deny the issuance of wildcard certificates by any CA
example.com.  IN  CAA  0 issuewild ";"

; Send violation reports to the security team
example.com.  IN  CAA  0 iodef "mailto:security@example.com"

By combining strict CAA records with active CT log monitoring, you create a powerful defense-in-depth architecture against BGP hijacking and CA compromise. Even if an attacker successfully hijacks BGP routes to intercept HTTP-01 or DNS-01 validation challenges, the CAA record will block the issuance at the CA level.

Total Automation is a Security Imperative

The fallout from recent CA compromises intersects directly with Google's "Moving Forward, Together" initiative, which aims to reduce the maximum validity of public TLS certificates from 398 days to just 90 days.

Shorter lifespans are a net positive for security. If a private key is compromised, or if a CA misissues a certificate, the window of opportunity for an attacker is drastically reduced. However, a 90-day lifecycle increases the volume of certificate renewals by roughly 400%. Manual certificate management is no longer mathematically or operationally feasible for enterprise teams.

To achieve true crypto-agility and survive the 90-day transition, organizations must adopt the Automated Certificate Management Environment (ACME) protocol for all issuance and renewal. Modern infrastructure relies on tools like cert-manager for Kubernetes, which natively supports ACME and allows for seamless CA failover.

Consider a scenario where your primary CA is distrusted. If you have configured cert-manager with multiple ClusterIssuers, your CI/CD pipeline can seamlessly failover to a secondary CA without manual intervention.

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: production-api-cert
  namespace: production
spec:
  secretName: production-api-tls
  duration: 2160h # 90 days
  renewBefore: 720h # 30 days
  issuerRef:
    name: letsencrypt-prod # Primary CA
    kind: ClusterIssuer
  dnsNames:
  - api.example.com

If letsencrypt-prod experiences an outage or is compromised, an administrator can simply update the issuerRef to a fallback CA (like ZeroSSL or Google Trust Services), and cert-manager will automatically rotate the certificates across the cluster.

Preparing for the Post-Quantum Era

Looking slightly further ahead, the lessons learned from recent CA compromises are informing how the industry prepares for Post-Quantum Cryptography (PQC). In August 2024, NIST finalized the first three PQC standards: FIPS 203, 204, and 205.

The threat model here is "Harvest Now, Decrypt Later." Attackers are currently intercepting and storing encrypted traffic. If a CA's infrastructure is compromised by a cryptanalytically relevant quantum computer in the future, attackers could retrospectively decrypt that stored traffic.

CAs and enterprises are already testing hybrid certificates that combine classical algorithms (like ECDSA) with quantum-resistant algorithms (like ML-KEM). The organizations that survive this transition smoothly will be those that have already established strict crypto-agility, automated their ACME workflows, and eliminated shadow IT.

Visibility and Expiration Tracking

While automation handles the heavy lifting of issuance and rotation, visibility remains the biggest blind spot for many organizations. Developers frequently spin up shadow IT infrastructure with certificates that security teams cannot see. When a CA is distrusted, you cannot replace certificates you do not know exist.

Maintaining a centralized, real-time inventory of every certificate in your environment is non-negotiable. You must track where certificates are deployed, which CA issued them, and when they expire. This is where dedicated tracking platforms become essential. Utilizing a service like Expiring.at provides the necessary visibility to monitor certificate lifecycles across your entire infrastructure. By aggregating expiration data and alerting teams well before deadlines, you prevent orphaned certificates from triggering catastrophic outages—especially during chaotic events like a forced CA migration.

Moving Forward

The era of trusting a single Certificate Authority and manually rotating credentials once a year is over. The compromises and compliance failures of the past two years have proven that operational resilience requires a zero-trust approach to PKI.

Engineering teams must assume that their primary CA will eventually suffer an outage, experience a compromise, or face distrust by major browsers. By implementing strict CAA