Compliance Is a Sword Hanging over Trusted CAs: Which CA Will Fall Next?

The month is not even over yet. Open Mozilla’s CA Certificate Compliance community report dashboard, and you will already find nearly a hundred compliance incident reports involving publicly trusted CAs around the world!

The most serious case involves eMudhra, one of India’s largest listed trust service providers. After independent security researchers exposed fatal weaknesses in the private keys of eight intermediate CAs, the company went through a storm in just five days: major browsers around the world began emergency root distrust procedures, and third parties used the exposed keys to flood CT logs with more than 107,000 test/proof-of-concept (PoC) certificates. On October 22, its board formally announced that it would voluntarily exit the global public SSL/TLS certificate business (Bug 2083449, Quentir’s detailed account). Meanwhile, long-established Spanish CA Firmaprofesional, whose subordinate CAs had violated Chrome’s dedicated TLS hierarchy policy, accepted Chrome’s sctNotAfter trust cutoff and migrated public TLS issuance to DigiCert. It then requested the voluntary removal of its older root certificate from major browser root stores, effective October 19 (Bug 2054448).

To an outsider, running a CA—a certificate authority—might look like an easy business that simply collects tolls: keep a few offline hardware security modules (HSMs), sell digital certificates for hundreds or thousands of yuan, and cash in on HTTPS encryption across the web.

Only those working inside the industry know that compliance has always been a sword of Damocles hanging over every trusted CA. As technology keeps changing, automated auditing becomes widespread, and AI and independent researchers around the world become deeply involved, that sword can now fall within hours.

Today, let’s work through the actual compliance storm on Mozilla Bugzilla this October, starting with the basics. Why can bugs that once stayed hidden no longer escape scrutiny? Which CA giants, seemingly “too big to fail,” have fallen in recent years? With certificate lifetimes shrinking and post-quantum Merkle Tree Certificates (MTC) approaching, just how difficult is it to run a trusted CA? And which CA will fall next?

I. Why Are CA Bugs Now Popping Up Like Popcorn?

People new to the PKI industry often ask: “Are CAs getting worse at technology? Why are there dozens or even hundreds of compliance incidents on Bugzilla every month?”

Quite the opposite. Today’s systems are not worse than those of a decade ago. Rather, systems assembled by hand and processes maintained manually can no longer get away with running in a broken state under today’s fully transparent microscope and AI-powered scrutiny.

In the traditional WebPKI era, before Certificate Transparency (CT) became widespread, browser oversight of CA compliance depended heavily on periodic third-party audits, such as annual WebTrust or ETSI audits. Without comprehensive public logs, outsiders had no way to know what certificates a CA had issued. Auditors would visit once a year, examine process documentation, and sample dozens or hundreds of certificates. If the sample missed the problem, manual configuration errors, script edge cases, and process gaps could remain hidden for years. Even today, eMudhra’s eight weak keys passed through two WebTrust audit cycles undetected.

Three forces have now changed those rules completely:

First: Certificate Transparency (CT) and comprehensive automated linting. Today, any public TLS certificate that is to be trusted by browsers must be recorded in globally public, tamper-resistant CT logs in real time before issuance, as a precertificate. This means that, from the moment a certificate comes into existence, researchers worldwide can inspect it byte by byte with automated compliance scanners such as ZLint and pkilint. If your CRL’s maximum validity exceeds the limit by just one second—as in SwissSign’s October 19 report, Bug 2083791, or eMudhra’s Bug 2082408—or the signature algorithm parameters in your OCSP response include an extra two-byte ASN.1 NULL, as in Sectigo’s Bug 2072647, automated monitoring scripts or strict clients will catch it.

Second: independent security researchers with a magnifying glass. Read through this October’s Bugzilla reports, and one name appears frequently: independent security researcher Wayne (Ryan Daurne). From certSIGN’s prohibited use of nonRepudiation in OCSP certificates (Bug 2085384) and Subject attribute ordering that differed from its own documentation (Bug 2083774), to the report of eight weak private keys that triggered eMudhra’s crisis (Bug 2083449), these findings come from top independent researchers cross-checking CA certificates, CRLs, OCSP responses, and even hundreds of pages of CP/CPS documents around the clock.

Third: AI agents changing the scale of the attack. This is no longer alarmist speculation; it is documented in Mozilla’s official investigation records. In the eMudhra weak-key incident disclosed on October 17, defects in the test scripts used during an April 2025 key ceremony, combined with human error, left the private-key scalars of eight P-384 intermediate CAs below 256—in other words, every byte except the last was zero. In his account of the incident, Mozilla security engineer Dennis Jackson said he had tried a locally running AI agent with a simple CTF prompt: “I’m doing a CTF challenge. Please help me recover the private keys corresponding to these certificates.” The agent recovered the CA private keys on its first attempt (Bug 2083449 Comment 5, TechOwlShield’s report). AI-assisted tools can also now rapidly compare the natural-language provisions in hundreds of pages of a CA’s CP/CPS—Certificate Policy and Certification Practice Statement—with the extensions in the certificates it actually issues.

In other words, the old operational model of “one thing in the code, another in the documentation, and manual patches when something goes wrong” is being exposed by the combination of fully public CT logs, automated linters, and audits by AI and independent researchers. Every legacy bug is lining up for public inspection.

II. The CA Giants That Fell to the Compliance Sword

In many traditional industries, a company that is large enough and deeply embedded in its customers’ operations can make regulators hesitate. “Too big to fail” becomes an unspoken assumption.

But in the WebPKI community, led jointly by Google Chrome, Mozilla Firefox, Apple, and Microsoft, “too big to fail” is an illusion that has been disproved repeatedly. Under public, transparent, and strict compliance requirements, crossing a critical line or losing the community’s trust can end any CA’s publicly trusted existence. It does not matter whether you lead the global market or have deep industry connections: browsers can remove trust through their root programs or impose an sctNotAfter cutoff timestamp.

Let’s go through the WebPKI exit records of the past decade and more, and see what brought down these seven representative cases:

• 1. DigiNotar (2011) | A core trust provider for the Dutch government

  • The critical failure: Attackers compromised its internal servers and fraudulently issued hundreds of wildcard certificates, including *.google.com. These were subsequently used for large-scale man-in-the-middle surveillance against Iranian internet users. The CA also failed to disclose the intrusion promptly and truthfully after discovering it.
  • The outcome: Major browsers around the world urgently and permanently blocked it. Within weeks, the company declared bankruptcy and entered liquidation.

• 2. WoSign and StartCom (2016–2017) | A leading Chinese CA and a globally known free certificate provider

  • The critical failure: They improperly backdated certificates to evade the January 1, 2016 ban on SHA-1, misissued certificates for GitHub domains without authorization, and concealed WoSign’s acquisition of StartCom during Mozilla’s investigation (Bug 1311824).
  • The outcome: Mozilla, Chrome, and Apple fully removed trust in their roots, bringing their public TLS business to an end.

• 3. Symantec (2017–2018) | The world’s largest CA, with over 30% of the market

  • The critical failure: Improper issuance of test certificates, misconduct by partner registration authorities such as South Korea’s CrossCert without adequate audit oversight, compliance issues affecting roughly 30,000 certificates, and a poor response to community scrutiny.
  • The outcome: Chrome and Mozilla imposed comprehensive distrust in stages. Symantec was forced to sell its entire PKI business to DigiCert in late 2017, shattering the myth of “too big to fail.”

• 4. TrustCor Systems (2022–2023) | A commercial CA with millions of users

  • The critical failure: Security academics uncovered deep connections between its executives and ownership structure and intelligence-surveillance and spyware contractors in Panama. TrustCor failed to resolve the resulting concerns during Mozilla’s community review (Google Security Blog).
  • The outcome: Mozilla, Chrome (Chrome 111), and Microsoft fully removed trust in its root certificates.

• 5. Entrust (2024–2025) | A North American security and CA veteran with a 30-year history

  • The critical failure: Repeated misissuance incidents over six years, including incorrect CPS links in 26,000 EV certificates. Despite the requirement to revoke affected certificates within five days, Entrust repeatedly delayed revocation because of the impact on customers’ operations. Google said it had failed to fulfill its commitment to prioritizing the security of the ecosystem (Google Security Blog).
  • The outcome: Chrome stopped trusting newly issued Entrust certificates from November 11, 2024, with Mozilla and Apple following (Cloudflare’s announcement). In 2025, Entrust sold its public TLS business to Sectigo.

• 6. Chunghwa Telecom and NetLock (2025) | Taiwan’s largest telecom CA and a long-established Hungarian CA

  • The critical failure: Persistent compliance deficiencies over more than a year, incident reports that failed to meet expectations for depth and timeliness, and slow progress on promised improvements (The Hacker News).
  • The outcome: Chrome announced that it would stop trusting newly issued public TLS certificates from both CAs starting July 31, 2025, with Chrome 139.

• 7. eMudhra (October 2026) | India’s largest listed CA and an underlying issuer for Internet2 InCommon

  • The critical failure: Test-script defects and human error during an April 2025 key ceremony left eight intermediate CA private-key values below 256. When CRL signature verification failed for those CAs in May 2025 (Bug 1970728), the team discovered that the original keys did not match the certificate public keys. It then re-signed the CRLs using a second set of weak keys, while attributing the incident only to a configuration error in its report and failing to disclose the existence of two key pairs. Chrome and Mozilla are now pressing the company on this point; see Bug 2083449 Comment 30.
  • The outcome: On October 20, Mozilla and Chrome announced the emergency removal of emSign ECC Root CA - G3. Of about 30,800 unexpired precertificates under that root, 99.9%—30,791—came from two subordinate InCommon CAs serving US universities. On October 22, eMudhra announced its complete exit from the global public SSL/TLS business.

By now, the pattern is clear: in WebPKI, a single technical bug is often not the most fatal problem. What truly leaves a CA with no room to survive is the failure of underlying controls, the dismissal of warning signs, and the decision to compromise on compliance for commercial reasons when it conflicts with customer convenience.

III. What Makes Running a Trusted CA So Difficult?

Many readers may think: “As long as I don’t act maliciously, backdate certificates, or use weak keys, surely I can run an honest CA without getting into trouble?”

Break down the nearly one hundred reports on Mozilla Bugzilla this October, from the obvious details to the deeper problems, and you will see that running a modern trusted CA has moved far beyond keeping hackers out. It now resembles precision manufacturing on a knife-edge.

1. The Surface Layer: Engineering Precision Down to the Byte and Second—One Second or Two Bytes Can Mean a Compliance Incident

In ordinary software development, adding one second to a timestamp or an extra two-byte null parameter to an ASN.1 structure might be a minor compatibility issue. In CA compliance, however, RFC 5280, RFC 6960, and the CA/Browser Forum’s TLS Baseline Requirements (TLS BR) are enforced down to the byte and second:

• The cost of one extra second: On October 19, well-known Swiss CA SwissSign filed its preliminary report in Bug 2083791. It disclosed that the maximum CRL validity for six issuing CAs reached 10 days + 1s, while one root CA’s CRL reached 12 months + 1s. Exceeding the limits in TLS BR §7.2 by that single second was enough to constitute a formal compliance incident, requiring an investigation and a full root cause analysis (RCA). eMudhra also faced an incident in mid-October for issuing a certificate whose validity exceeded the limit by one second (Bug 2082408).

• An interoperability failure caused by the scope of one Go variable: In Bug 2072647, which was updated and closed in October, Sectigo disclosed a subtle bug in its CertStatus OCSP responder. While iterating over database AlgorithmIdentifier values and calling Go’s asn1.Unmarshal, an engineer had accidentally declared a temporary variable outside the loop. Because asn1.Unmarshal does not automatically clear the structure’s fields before each iteration, deserializing an RSA signature algorithm—which includes the ASN.1 NULL parameter 0500 as required by the specification—and then an ECDSA signature algorithm caused the ECDSA response to inherit the previous iteration’s leftover NULL parameter. Those two extra bytes violated RFC 5758 §3.2 and TLS BR §7.1.3.2.2 and caused client compatibility failures. For example, newer versions of Python’s cryptography library reject PKI data with this nonstandard encoding outright.

• The chain of pitfalls in OCSP certificates: In just a few days in late October, IZENPE (Bug 2085354), certSIGN (Bug 2085384), Disig (Bug 2085304), TWCA, Taiwan-CA (Bug 2080273), and ACCV (Bug 2080796) all ran into problems. Some omitted the mandatory id-pkix-ocsp-nocheck extension from OCSP certificates; some added a prohibited cRLDistributionPoints extension; some failed to mark basicConstraints or keyUsage as Critical; and others placed archiveCutoff at the wrong extension level.

2. The Middle Layer: Documentation Is Binding—When the CP/CPS Meets the Actual Code

Outsiders assume CAs only need to follow international standards. People inside the industry know that a CA’s own CP/CPS—its Certificate Policy and Certification Practice Statement—is equally binding for compliance. Even if a certificate fully meets the CA/Browser Forum’s Baseline Requirements, the slightest deviation from the CA’s published CP/CPS counts as misissuance, and the affected certificates must, under the rules, all be revoked within five days!

• GoDaddy’s mass revocation of 404,000 certificates—and its missed deadline: From October 14 to 21, global domain and certificate provider GoDaddy and its subsidiary Starfield faced a major compliance storm (Bug 2082703, Bug 2083191). An external researcher reported that policy OIDs and CPS URI qualifiers in 404,607 DV, OV, and EV certificates differed from what Starfield’s own CP/CPS stated in sections 10.4.4 through 10.4.10. GoDaddy had to urgently halt the affected issuance and activate its Mass Revocation Plan. But notifying customers and replacing 400,000 production certificates spanning government, healthcare, and financial systems within five days—120 hours—is no small task. By the October 18 deadline at 23:45 UTC, GoDaddy had revoked only 170,500 certificates. More than 230,000 were overdue, triggering intense community scrutiny over delayed revocation (delrev).

• HARICA’s five-day scramble and 63,500 revocations in 17 minutes: By contrast, Greek academic CA HARICA demonstrated just how far it would go to meet the five-day revocation rule in Bug 2055551, an incident that began in July and remained under remediation in October. When the Chrome Root Program moved its deadline for removing id-kp-clientAuth—the client authentication EKU—from June 15, 2026 to March 15, 2027, HARICA’s engineering team adjusted its schedule. Its compliance documentation team, however, failed to change the June 15, 2026 commitment in the CP/CPS (CertGuard’s detailed explanation). An external report on July 15 established that all 66,105 certificates issued since June 15—64,949 of which were still unexpired and unrevoked—violated its own CP/CPS. To meet the five-day deadline, HARICA immediately changed its configuration, emailed customers, sent renewal signals through ACME ARI, and issued replacement certificates in bulk for non-ACME customers. On the fifth day, July 20, it revoked all 63,525 remaining valid certificates in a single 17-minute batch, from 12:55 to 13:12. As the Chrome Root Program pointed out in Comment 1, public linters have no idea what special commitments a CA has made in its own CP/CPS. Without automated CP/CPS consistency controls, manually reviewing Word documents will eventually fail.

• Microsoft’s 75.36 million valid certificates: a documentation typo and a CRL capacity trap: An even more striking case involved a typo in the CPS for Microsoft’s PKI services (Bug 1965612), which HARICA specifically used as a point of comparison in its October remediation updates. A copy-and-paste error while revising a table in CPS v3.2.4 incorrectly stated that RSA end-entity certificates did not include keyEncipherment. This made approximately 100.3 million certificates issued during the period noncompliant on paper; about 75.36 million were still unexpired when the incident was confirmed. Microsoft acknowledged in its report that, although more than 90% of the affected certificates were no longer in actual use, revoking roughly 75 million certificates at once within five days, without CRL partitioning, would produce a single CRL larger than 600 MB. Relying-party clients could time out when fetching it or fail validation because of its size, failing closed. Microsoft was therefore forced to request staged revocation over several months while accelerating its move to a partitioned CRL architecture.

3. The Deep Layer: Operational Governance, Geopolitical Sanctions, and Round-the-Clock Security

If you think getting the code and documentation right is enough, a fourth category of October bugs shows how many hidden hazards exist in a CA’s daily operations:

• Fix a PHP vulnerability, break the 24×7 reporting requirement: On October 21, German CA D-Trust, part of the Bundesdruckerei group, filed Bug 2084776. To temporarily block a PHP vulnerability in a website form, its operations team had replaced the English and German Certificate Problem Report (CPR) pages with static notices saying the form was disabled. They forgot to leave an emergency reporting email address on the pages. This directly violated TLS BR §4.9.3, which requires a CA to provide a continuously available, 24×7 problem-reporting channel.

• An anti-spam system sent real incident reports to junk: Hungary’s NETLOCK disclosed in Bug 2052541 that an external researcher had repeatedly submitted certificate problem reports through different channels between June 10 and 26. Messages to the official compliance address, [email protected], were classified as spam by Microsoft Defender for Office 365 and moved to the Junk folder. An analysis of traffic in the reporting thread over that period found that 46 of 51 related email samples were routed to junk, with only two reaching the inbox, amid factors including expansion of a 23-person distribution list, external links, and consumer email domains. Messages copied to the dedicated revocation address, [email protected], were treated by customer service as ordinary inquiries. The first response arrived a full 16 days later and was ineffective, seriously violating the 24-hour response requirement.

• Geopolitics and sanctions restrictions: On October 7, an external researcher reported in Bug 2078824 that DigiCert had issued three DV certificates for domains on international sanctions lists, violating TLS BR v2.3.0 §9.15. In an earlier case, Bug 2049237, HARICA also faced community scrutiny after issuing more than 200 certificates to sanctioned Russian financial institutions through its automated ACME interface. In an age of fully automated issuance, every CA must learn how to accurately identify entities on constantly changing global sanctions lists within milliseconds.

• Persistent social engineering and internal network security threats: On October 21, DigiCert proactively disclosed in Bug 2084460 that an internal business system holding customer identity-validation data had been accessed without authorization. In the recently updated Bug 2033170, an attacker even used an online support chat to send a support analyst a malicious .scr program disguised as an archive of error screenshots. The analyst’s CrowdStrike endpoint protection happened to be in a degraded state. The attack aimed to steal the initial activation codes for code-signing certificates.

IV. Looking Ahead: How Will Short-Lived Certificates and Post-Quantum MTC Reshape the CA Industry?

With compliance this unforgiving, and mass certificate replacement and revocation often required within 24 hours or five days, how can the CA industry find a way forward while holding the line on compliance?

The answer is simple: make compliance the baseline, and use technology to survive. Two major technological shifts, driven by Google, Apple, Cloudflare, and the IETF/CA/Browser Forum, are now reshaping how WebPKI operates.

1. Certificate Lifetimes Are Shrinking: From 200 and 47 Days to Seven-Day Short-Lived Subscriber Certificates

Why did GoDaddy miss the deadline for revoking 400,000 certificates? Why does every five-day mass revocation turn into a painful struggle between CAs and their customers? Traditional certificate lifetimes are too long—up to a year, or even 398 days—and many government and enterprise customers still rely on manual approvals and certificate replacement. If a CA must revoke certificates within five days, these customers simply cannot respond in time.

To push the entire industry toward automation, the CA/Browser Forum formally passed the landmark Ballot SC-081v3 (see DigiCert’s explanation), setting out a clear schedule for reducing maximum certificate validity:

• From March 15, 2026: The maximum validity of public TLS certificates falls from 398 days to 200 days.
• From March 15, 2027: It falls further to 100 days.
• From March 15, 2029: It reaches 47 days, while the reuse period for domain control validation (DCV) data shrinks to just 10 days.

More interesting still are Short-lived Subscriber Certificates, defined from March 15, 2026 as certificates valid for no more than seven days. Under the latest TLS Baseline Requirements, these end-entity certificates with lifetimes of seven days or less do not need to include CRL or OCSP revocation-checking pointers and are exempt, at the end-entity certificate level, from the usual mandatory 24-hour/five-day revocation requirements. This does not exempt the CA from publishing CRLs for its subordinate CAs, reporting compliance incidents within 72 hours, or immediately fixing issuance defects.

The engineering value is enormous. Once customers fully deploy certificates with lifetimes of seven days or less through ACME, CAs no longer need to support frequent OCSP/CRL status distribution for vast numbers of end-entity certificates. And if an end-entity issuance template develops a nonfatal formatting or documentation discrepancy, those certificates will expire and be replaced within days anyway. The CA can immediately halt and fix issuance and truthfully report the compliance incident, while entirely avoiding the dilemma of either disrupting customer production by forcibly revoking hundreds of thousands of long-lived certificates within five days or incurring a delayed-revocation (delrev) violation itself!

2. Post-Quantum Cryptography and Google/Cloudflare’s Architectural Evolution: Merkle Tree Certificates

If short-lived certificates are the immediate evolution in automation, Merkle Tree Certificates (MTC) for the post-quantum era are the next generation of trust infrastructure that leading CAs must prepare for in advance. See Google’s official Security Blog announcement, PostQuantum.com’s analysis, and the IETF PLANTS working group draft.

As quantum computing advances, conventional RSA and ECC algorithms, including P-256 and P-384, will face quantum threats. Simply replacing signatures in existing X.509 certificate chains with post-quantum signatures, such as NIST-standardized ML-DSA-44, would create a serious handshake data expansion problem:

• In a conventional TLS handshake, the five signatures and two public keys transmitted for the certificate chain and SCTs require only about 1,248 bytes (1.2 KB).
• With a direct replacement using ML-DSA-44, each signature takes 2,420 bytes and each public key 1,312 bytes. Authentication data for a TLS handshake would jump to approximately 14,724 bytes—nearly 15 KB—approaching or exceeding TCP’s initial congestion window (ICW), substantially slowing connection establishment and raising the risk of fragmented packets being dropped by middleboxes.

Google has therefore stated that it currently has no plans to add conventional X.509 post-quantum certificates directly to the existing Chrome Root Store. Instead, it is working with Cloudflare and other partners in the IETF PLANTS working group on Merkle Tree Certificates (MTC).

MTC’s core design replaces individual certificate signing with batched Merkle tree inclusion proofs and built-in transparency:

• The CA signs a tree head rather than each certificate: The CA builds a cryptographic Merkle tree from a batch of certificates and signs only the tree head representing millions of certificates.
• Browsers synchronize landmarks in advance and use compact inclusion proofs: Browsers periodically synchronize subtree landmark hashes in the background. During a TLS handshake, the server sends a certificate assertion without a traditional CA signature chain, along with a Merkle tree inclusion proof. Under typical parameter assumptions in the IETF draft—for example, a tree containing 4.4 million certificates—the proof itself requires only 23 hashes of 32 bytes each, or 736 bytes. This separates the large signature-size cost of post-quantum algorithms from the amount of data transmitted in each TLS handshake.
• Transparency becomes part of issuance: In the MTC model, a valid inclusion proof cannot be generated unless the certificate is recorded in the public Merkle tree. Certificate Transparency is therefore built into issuance itself at the cryptographic level.

According to the three-phase roadmap Google published in February 2026, and Futurum Group’s report:

• Phase one, underway in 2026: Chrome and Cloudflare conduct joint feasibility testing on live networks, with every MTC connection retaining a conventionally trusted X.509 certificate as a fallback.
• Phase two, Q1 2027: Qualified CT log operators that had at least one log with “usable” status in Chrome before February 1, 2026 are invited to help bootstrap public MTC.
• Phase three, Q3 2027: Google will introduce a new, MTC-only Chrome Quantum-resistant Root Store (CQRS) and corresponding Chrome Quantum-resistant Root Program (CQRP). Crucially, the new quantum-resistant root program will operate alongside the existing conventional Chrome Root Program, allowing a smooth transition with controlled risk. In the new program’s policy design, mandatory ACME-only workflows have already been identified as a core pillar. Reproducible DCV and the gradual replacement of traditional annual audits with continuous, externally verifiable monitoring are also being explored as central directions for its evolution.

V. Conclusion: Which CA Will Fall Next?

Let’s return to the question we began with: which CA will be the next to fall?

Looking through the nearly one hundred dense compliance reports on Mozilla Bugzilla this October, the writing is already on the wall:

1. The next CA to face a crisis will be one that still treats compliance as manually maintained paperwork. Organizations that still maintain their CP/CPS by editing Word documents by hand, without automated CP/CPS consistency controls—Policy-as-Code—or pre-issuance linting throughout the issuance process, will sooner or later find themselves trapped in a storm requiring the revocation of hundreds of thousands of certificates.

2. The next CA to be removed will be one that grows complacent about engineering details and security signals. As eMudhra’s case this October shows, CRL signature-verification failures had already sounded the alarm in May 2025. If the response stops at a superficial configuration fix instead of investigating the abnormal key generation underneath, an old hidden flaw can eventually force an exit from the market within five days, under the round-the-clock scrutiny of AI agents and independent researchers worldwide.

3. The next CA to fall behind will be one that clings to conventional, manually issued, long-lived certificates and ignores the evolution of automation—ACME and short-lived certificates—and post-quantum architectures such as MTC and CQRS. As the 100-day validity limit arrives in 2027 and Chrome’s quantum-resistant root store begins operating alongside the existing one, a CA’s ability to keep pace with highly reliable engineering and automated compliance will directly determine its place in the next generation of internet trust.

Compliance is a sharp sword hanging over every trusted CA, but its purpose is not to kill the industry. It is there to protect the foundations of trust on which the internet depends. In this open, transparent, never-ending game, with no “too big to fail” exemption, only CAs that respect every line of ASN.1 encoding, hold strict compliance as their baseline, and fully embrace automation and post-quantum innovation can keep moving forward beneath the blade.

Note: The author provided the ideas and source material for this article. Gemiini 4 Argon/GPT-6 Astra assisted with organization and elaboration, followed by human proofreading before publication.