What Two Weeks of CA Compliance Incidents Say About Your Revocation Risk
In the two weeks ending August 27, 2026, Mozilla's public CA Certificate Compliance tracker logged 69 incidents across more than 30 public Certificate Authorities, 14 of them newly filed. They fall into three groups that all end the same place for a certificate holder: delayed revocations (ACCV, SwissSign, SDAIA), a wave of misissuance over invalid subject fields and the clientAuth extended key usage (SSL.com, GlobalSign, CFCA, Certum, DigiCert, Sectigo, iTrusChina, Actalis, HARICA), and process failures that are the early markers of distrust (NETLOCK, Beijing CA, Microsoft PKI Services, SECOM). Your renewal calendar catches none of it - the bigger revocation risk is your CA's compliance, and the defense is external monitoring for revocation and trust, not just expiry.
Every publicly trusted Certificate Authority reports its rule violations in one public place: Mozilla's CA Certificate Compliance tracker. It is the closest thing the Web PKI has to a live feed of trust problems. In the two weeks ending August 27, 2026, it logged 69 incidents across more than 30 public CAs, 14 of them brand new.
Here is the part most teams miss: when a CA breaks a rule, the fix is almost always to revoke your certificate. Your renewal calendar tells you when your certificate expires. It says nothing about the revocation your CA is about to hand you. Grouped by what matters to a certificate holder:
Delayed revocations: the clock you didn't start
The Baseline Requirements give a CA five days to revoke for most compliance problems, and 24 hours for the serious ones. When a CA misses that deadline it has to file a "delayed revocation" incident. Five appeared in this window: ACCV (Bug 2064673), SwissSign twice (Bug 2065157, plus an April case still open at Bug 2034359), and SDAIA (Bug 2058294). Delayed revocation means a batch of certificates that should have been pulled is living on borrowed time, and if you hold one, you are in a queue you never joined.
Misissuance: certificates that shouldn't exist as issued
The largest category, 22 incidents, was misissuance, and most clustered on a boring-sounding but consequential theme: the identity fields inside the certificate do not match the rules. Invalid or inconsistent country, state, and locality values showed up at SSL.com (Bug 2065634, Bug 2057915), GlobalSign (Bug 2065895, plus a Unicode replacement character in a subject field, Bug 2057318), CFCA (Bug 2058918), Asseco/Certum (Bug 2061178), DigiCert (Bug 2062100), Sectigo (Bug 2062202), and eMudhra (Bug 2057520). A wrong two-letter country code sounds trivial, but the entire value of a public certificate is that a neutral third party verified those details. If the field can be wrong, the verification is meaningless, so the rules require revocation.
A second misissuance cluster matters more going forward: TLS certificates carrying the clientAuth extended key usage against the CA's own policy, at iTrusChina (Bug 2060152), Actalis (Bug 2060581), and HARICA (Bug 2055551, the mismatch that forced HARICA to revoke more than 63,000 certificates in July). That connects to the one scheduled PKI change worth putting on your calendar.
Process failures: the slow road to distrust
No CA is distrusted overnight. It happens through a pattern of missed deadlines and slow responses that erode a root program's confidence, and this window was full of the early signals. NETLOCK missed the 72-hour deadline to file a preliminary incident report (Bug 2063842). SSL.com (Bug 2057919) and Beijing Certificate Authority (Bug 2060785) each missed the 24-hour deadline to respond to a certificate problem report. Microsoft PKI Services missed a required seven-day status update (Bug 2066649). SECOM extended trust to externally operated CAs through a cross-certificate without the required prior notification (Bug 2066068). And Beijing Certificate Authority issued TLS certificates with the weak RSA public exponent 3 (Bug 2056489). NETLOCK is worth pausing on: its certificates issued after July 31, 2025 are already untrusted in Chrome, and it is still filing fresh compliance bugs. When a CA is finally distrusted, every certificate it issued you stops working in the affected browsers, expiry date notwithstanding.
The one date on the calendar
Chrome Root Program Policy v1.8 requires leaf TLS certificates issued on or after March 15, 2027 to assert serverAuth only. The clientAuth extension many certificates still carry will make them non-conforming going forward, and the three clientAuth incidents above are its leading edge. You will see June 15, 2026 cited widely for this; that was the older v1.6 date, extended before it took effect, and it now applies only to a narrower subordinate-CA rule. Some CAs are dropping clientAuth ahead of the deadline anyway, so a routine renewal can quietly change what your certificate can do. Verify renewed certificates, do not assume they match the ones they replaced.
What this means for you
You cannot control your CA's compliance. You can control how fast you find out when it affects you. A renewal reminder catches expiry. It never catches a certificate revoked early over a misissuance, a chain broken by a distrusted intermediate, or a CA sliding toward a distrust decision that invalidates everything it issued you. Monitor your certificates for revocation and trust, from outside, not just for expiry. Run a free scan of your domain to see what a browser sees today, then put anything you care about under continuous monitoring so the next CA-side surprise reaches you before your customers.
Frequently asked questions
- What is the Mozilla CA Certificate Compliance tracker?
- It is a public component of Mozilla's Bugzilla where publicly trusted Certificate Authorities are required to report and remediate violations of the CA/Browser Forum Baseline Requirements and root program policies. It functions as the public record of trust problems in the Web PKI.
- Can my certificate be revoked because of my CA's mistake?
- Yes. When a CA discovers misissuance, the Baseline Requirements generally require it to revoke the affected certificates within five days, or 24 hours for serious cases. If you hold one of them, you have to reissue on that timeline whether or not the mistake was yours.
- What is delayed revocation?
- Delayed revocation is when a CA misses the required deadline to revoke a certificate, usually because subscribers are not ready to reissue. It signals that a batch of certificates is out of compliance and living on borrowed time. Five such incidents were open in the two weeks ending August 27, 2026, including ACCV (Bug 2064673).
- When do public certificates have to drop the clientAuth EKU?
- Chrome Root Program Policy v1.8 requires leaf TLS certificates issued on or after March 15, 2027 to assert serverAuth only. An earlier June 15, 2026 date from policy v1.6 was extended before it took effect and now applies only to a narrower subordinate-CA rule. Some CAs are removing clientAuth ahead of the deadline.
- How do I find out about a revocation before my customers do?
- Monitor your certificates with continuous external probes that check revocation and trust the way a browser does, not just expiry. A CA-side revocation does not change the certificate file on your server, so only external monitoring sees it while you still have time to reissue.
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.