SSL.com Revoked 2,700 Certificates in 24 Hours After an Audit Found a Missing Check
On 2026-09-11 SSL.com disclosed that an annual WebTrust audit found four sampled TLS certificates with no Multi-Perspective Issuance Corroboration (MPIC) evidence on their domain validation. The full investigation identified 2,700 unexpired, unrevoked TLS certificates in the same state, and SSL.com invoked its mass revocation plan and revoked all of them in under 24 hours (Mozilla Bug 2071491). Nothing about those certificates was inspectable from the outside - the defect was in the CA's validation records, not in the certificate file. A separate July 2026 SSL.com incident (Mozilla Bug 2057915) produced 20 certificates with invalid stateOrProvinceName values, including a state of US-DE instead of Delaware, caused by a background business-registry lookup with fuzzy name matching and a race condition against human validators. That second class of defect is visible in the certificate you already hold, and TLS Radar's scanner flags it on every scan including the free one. Revocation is not visible locally at all - a revoked certificate is unchanged on your server - so TLS Radar now reads revocation status directly, from the stapled OCSP response or the CA's CRL, on Business and Enterprise plans.
On September 11, 2026, SSL.com disclosed that it revoked 2,700 TLS certificates in less than 24 hours. Nobody attacked anything. No key was stolen. An auditor pulled a sample of certificates during SSL.com's annual WebTrust audit and found that four of them had no evidence that a required domain validation step was ever performed. The full investigation found 2,700 live certificates in the same condition (Mozilla Bug 2071491).
If one of those 2,700 was yours, your first warning was your site breaking.
What the missing step was
The step is called Multi-Perspective Issuance Corroboration, or MPIC. Before a CA issues you a certificate, it has to prove you control the domain. It does that by checking a DNS record, a file on your server, or an email address. The problem is that the check travels over the internet, and the internet can be redirected. An attacker who hijacks a network route can make the CA's check land on their server instead of yours.
MPIC is the fix. Instead of checking from one place, the CA checks from several network locations in different parts of the world and compares the answers. It is the difference between confirming someone's address by asking one neighbor and asking four neighbors on different streets. One neighbor can lie to you. Four, in four different places, is much harder to arrange.
The CA/Browser Forum made MPIC mandatory. SSL.com's own policy requires it. For one specific validation path, the corroboration evidence was not there. Under the rules, a certificate validated without a required step is misissued, and misissued certificates get revoked. SSL.com invoked its mass revocation plan and pulled all 2,700 within a day. The full incident report is due on or before September 25, 2026.
Why you could not have seen this coming
There was nothing wrong with those 2,700 certificates that you could inspect. The dates were fine. The chain was fine. The domain names were correct. They opened in every browser right up until the moment they were revoked. The defect was in a record at the CA, not in the file on your server.
Your renewal calendar does not help either. A calendar tracks expiry. Revocation is not expiry. It arrives early, without warning, on the CA's schedule.
You cannot predict it but you can detect when it happens.
Here is the important part. When your certificate is revoked, the file on your server does not change. It is the same bytes it was yesterday. Your server keeps serving it, and every local check you run keeps saying it is fine. The revocation lives somewhere else: in the OCSP response your server staples, or in the certificate revocation list your CA publishes.
We shipped revocation checking this week, so this is now something TLS Radar answers directly. On Business and Enterprise plans, every scan reads the revocation status of the certificate you are actually serving. It reads the stapled OCSP response first, because that costs nothing, and falls back to the CRL the certificate itself names. That fallback matters: OCSP became optional in 2025 and Let's Encrypt retired its responders, so a checker that only spoke OCSP would answer "I don't know" for a large share of the public web. A certificate found revoked is a critical finding. It drops the grade to F and raises an alert naming the domain.
"Unknown" never counts as "good." If no revocation list can be reached, or you are on a plan without revocation monitoring, or you ran the free scan, the result says unknown and stays out of your grade. Not looking is not the same as looking and finding nothing. We would rather tell you we do not know than tell you something is fine when we did not check.
The other SSL.com incident, and this one you can check for free
This was not SSL.com's only open compliance bug. In July 2026, a security researcher reported certificates carrying invalid values in the stateOrProvinceName field (Mozilla Bug 2057915). Twenty certificates were affected: 12 OV TLS, 5 client authentication, 2 code signing, and 1 VMC. All twenty were revoked.
The cause was a business registry lookup tool that pre-filled organization details for the human validator. It searched company names with fuzzy matching rather than exact matching, and it ran in the background while the validator worked, so it could overwrite a value after the validator had already approved what was on screen. It also pulled geographic data in the wrong format. One certificate went out with a state of US-DE instead of Delaware.
One line from SSL.com's own report is worth reading twice:
"standard linters do not pick up on errors in the content for the stateOrProvinceName or localityName fields"
That is accurate, and it is the whole problem. The automated tools CAs run before issuance check that a field is well-formed, not that its contents are true. A state that does not exist, or a real state belonging to a different country than the one printed beside it, sails straight through.
Unlike revocation, this one is visible in the certificate you already hold, and we check it on every scan including the free one. We tried it: TLS Radar flags US-DE on a US certificate as an unrecognized subdivision, and flags the more serious cases too, such as a country code that is not a real ISO 3166-1 code, or a state that belongs to some other country. We shipped that check earlier this month precisely because CAs keep being forced into revocations over it.
What to do this week
Three things, in order. Scan the certificates you actually serve and read the subject fields, because the province class of defect is one you can find yourself today, for free. Write down which CA issued each certificate, so the next mass revocation notice takes minutes to assess instead of days. Then put the certificates you care about under continuous external monitoring with revocation checking on, so that a revoked certificate reaches you as an alert rather than as a support ticket.
SSL.com handled both of these incidents the way the system is designed to work: disclosed publicly, revoked fast, reported in the open. That is the process functioning. It is still your outage. A CA can fix its validation pipeline over a few weeks; you have to replace every affected certificate in 24 hours, and you can only do that if you know which ones are yours and which ones have already been pulled. Sign up for TLS Radar and let a monitor tell you, instead of a customer.
Find out from a monitor, not from a customer
TLS Radar keeps a live inventory of every certificate across your domains and checks each one from outside the way a browser does. On Business and Enterprise plans it reads revocation status on every scan, from the stapled OCSP response or the CA's revocation list, and a revoked certificate drops the grade to F and raises an alert. Every plan, including the free scan, checks the subject-field defects that lead to misissuance revocations in the first place: invalid country codes, states belonging to a different country, and malformed province values like the ones in this incident.
We also publish a weekly digest of CA compliance incidents drawn from Mozilla's public tracker, so you can watch your CA's record without reading Bugzilla yourself.
Related reading
Frequently asked questions
- What is MPIC in certificate issuance?
- MPIC stands for Multi-Perspective Issuance Corroboration. Before issuing a certificate, a Certificate Authority must confirm the applicant controls the domain. MPIC requires that this domain control check be corroborated from several remote network perspectives, not just one, so that an attacker who hijacks a single network path with a BGP attack cannot fool the CA. It is mandated by TLS Baseline Requirements v2.3.0 section 3.2.2.9.
- Why did SSL.com revoke 2,700 certificates?
- During its annual WebTrust audit, SSL.com found that four sampled TLS certificates had no evidence that MPIC was performed on their domain validation. A full internal investigation identified 2,700 unexpired, unrevoked certificates validated through the same path. Under the Baseline Requirements a certificate validated without a required step is misissued and must be revoked, so SSL.com invoked its mass revocation plan and revoked all 2,700 within 24 hours.
- Could I have detected the MPIC problem in my own certificate?
- No. The defect was in SSL.com's validation records, not in the certificate itself. The affected certificates had valid dates, correct domain names, and complete chains, and they worked in every browser until the moment they were revoked. The practical defense is not inspection but preparation: maintain an accurate inventory of which certificates you hold and which CA issued each one, and monitor them externally so a revocation reaches you rather than your customers.
- What was wrong with SSL.com's stateOrProvinceName values?
- A business registry lookup tool pre-filled organization and geographic details for human validators. It matched company names with fuzzy rather than exact matching, ran in the background so it could overwrite values after a validator had approved the screen in front of them, and returned geography in the wrong format. One certificate was issued with a stateOrProvinceName of US-DE rather than Delaware. Twenty certificates were affected in total and all were revoked.
- Do pre-issuance linters catch invalid state or province values?
- Generally no. As SSL.com stated in its own incident report, standard linters do not pick up on errors in the content of the stateOrProvinceName or localityName fields. Linters check that a field is well formed, not that its contents are true, so a nonexistent state or a state belonging to a different country than the certificate's own country code passes through.
- Can TLS Radar detect invalid province values in my certificate?
- Yes. TLS Radar's scanner checks the certificate subject for geographic consistency on every scan, including the free one. It flags a countryName that is not a valid ISO 3166-1 code, a stateOrProvinceName that is a real subdivision of a different country than the certificate's own, and values that match no known subdivision at all - which is how the US-DE value from this incident is caught.
- How do I find out my certificate has been revoked?
- Revocation does not change the certificate file on your server, so nothing local will tell you. You need external monitoring that reads revocation status the way a browser would. TLS Radar checks it on every scan on Business and Enterprise plans, reading the stapled OCSP response first and falling back to the CRL named by the certificate; a revoked certificate is a critical finding that drops the grade to F and raises an alert. The free scan does not check revocation and reports it as unknown rather than good.
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.