Your site passed the Chrome check. It was revoked a week ago.
This morning I pointed openssl ocsp at four Indian government websites. Among them are the national scholarship portal and the site pensioners use to submit their annual life certificate. All four answered with the same thing: revoked, reason superseded, revocation time 19 October, around 13:45 UTC. All four still serve that certificate today. And as far as Chrome is concerned, all four are fine.
Chrome is doing exactly what Google built it to do. Last week that design ran into two mass revocations at once. GoDaddy revoked 378,067 certificates. eMudhra revoked another 9,356. If you run anything on either CA, or on any CA that will have a bad week someday, the browser you test in is lying to you. It just does it by keeping quiet.
What GoDaddy and eMudhra actually revoked
GoDaddy first. A third party noticed that certificates under the GoDaddy and Starfield hierarchies carried policy OIDs and CPS URI qualifiers that didn't match GoDaddy's own published CP/CPS. It's the same kind of paperwork bug that hit HARICA and SSL.com earlier this year. GoDaddy's preliminary report, filed on 15 October, counts 404,607 affected certificates, almost all of them Starfield DV.
The Baseline Requirements give a CA five days for this kind of misissuance, with reason code superseded. GoDaddy missed it. In a second bug it reports 170,566 revocations by the 18 October 23:45 UTC deadline, and on 22 October it declared the job done: a corrected total of 403,643, of which 378,067 revoked and 25,576 expired along the way. GoDaddy's customer help page says the certificates were revoked "on October 21, 2026", which doesn't square with the Bugzilla numbers. I'd trust the bug. Revocations ran from before the 18th through the 22nd, so "when did mine die" depends on your serial.
eMudhra's batch is smaller and stranger. While the internet was busy with its guessable CA keys, a separate incident, Bug 2082782, reported TLS certificates missing the certificate-type policy OID that emSign's CP/CPS requires. On 19 October eMudhra revoked 9,356 certificates on its RSA hierarchy, the one that's still trusted, again as superseded. The blogger behind Nemo's Home mapped the fallout. His 24 October count found 1,377 Indian government domain names on those certificates, 811 of them still serving the revoked one. (HN discussion.)
Then on 22 October eMudhra announced it is leaving the global TLS business. Nemo's take on whether subscribers got proper notice: he's "not sure", now that eMudhra doesn't care about its TLS business. Neither am I.
I checked Chrome's CRLSet this morning
Chrome doesn't do online revocation checks. Its own documentation says it plainly: "Online (i.e. OCSP and CRL) checks are not generally performed by Chrome." Instead it ships a CRLSet, which Google describes as primarily a way to block certificates "in emergency situations", plus "some number of non-emergency revocations" crawled from CA CRLs.
Some number. Let's see what that means. Adam Langley's crlset-tools can download and dump the live set:
git clone https://github.com/agl/crlset-tools.git
cd crlset-tools && go build -o crlset .
./crlset fetch > crl-set
# Grab the issuer certificate of a site you care about
openssl s_client -connect nsp.gov.in:443 -servername nsp.gov.in -showcerts </dev/null 2>/dev/null \
| awk '/BEGIN CERT/{n++; f="c" n ".pem"} f{print > f} /END CERT/{f=""}'
# Every revoked serial Chrome knows about under that issuer
./crlset dump crl-set c2.pem
I pulled CRLSet version 10861 on 26 October. It holds 71,909 serials across 385 issuers. Then I ran the dump against every issuing CA named in GoDaddy's incident: Starfield TLS Intermediate CA DV, OV and EV R1v1, Starfield Secure Certificate Authority G2, GoDaddy TLS Intermediate CA OV and EV R1v1. Zero entries under every one of them. Same for eMudhra's EM DV and EM OV TLS CA G2A-1, which issued most of the revoked Indian government certificates.
It gets worse. One shard of GoDaddy's OV R1v1 CRL currently lists six certificates revoked for keyCompromise. Not in the CRLSet either. So no, Chrome isn't skipping only the paperwork revocations. For these issuers it has nothing at all.
Who actually sees the error page
Firefox does, on desktop. Since Firefox 137 it has shipped CRLite, a compressed set of every revocation for CT-logged certificates, refreshed every 12 hours. Revoked means blocked, whatever the reason code says.
SSL Labs fetches the CRL itself and hands these sites an F. Safari on iOS catches some of them: according to Nemo it only checks OCSP for EV certificates. Apple doesn't document that, so treat it as observed behaviour. Chrome, Edge and Android do nothing. The page loads.
That's the trap. Your team mostly runs Chrome, and so does your QA. The person who notices is a Firefox user filing a ticket that says "your site is broken". Whoever triages it opens the site in Chrome and closes the ticket as works-for-me.
Real visitors did hit this. Gibraltar's government put out a press release on 22 October told citizens that some government sites were showing security warnings because of the GoDaddy revocation, and asked them not to click through. It doesn't say which browsers. Given what's in the CRLSet, my bet is that most of those warnings showed up in Firefox.
Your monitoring has the same blind spot as Chrome
Here's the part that should bother you more than the browser story. Run this against one of those government sites:
curl -s -o /dev/null -w '%{http_code} verify=%{ssl_verify_result}\n' https://nsp.gov.in/
I got 301 verify=0. Zero means verification succeeded. A certificate revoked a week ago, and curl is perfectly happy, because OpenSSL with default settings never looks at OCSP or CRLs. Python's requests, Go's net/http, Node's fetch, Java with default settings: same story.
Now think about what your uptime checker and your homegrown certificate script are built on. Most of them open a TLS connection, read notAfter, and compare it with today. A revoked certificate with 70 days left passes that check every five minutes until it expires. Expiry monitoring answers "when will this break". It has no opinion on "is this already broken for some of my users".
Ask the CA, from every IP behind the name
Asking the CA directly is the fix. GoDaddy, Starfield and eMudhra leaf certificates still carry OCSP URLs, so for them OCSP is the quickest route. Here's a script that resolves the hostname, connects to every IPv4 address behind it, and asks the CA about whatever certificate each one serves:
#!/usr/bin/env bash
# Usage: ./revcheck.sh example.com
set -uo pipefail
HOST="$1"
WORK=$(mktemp -d)
trap 'rm -rf "$WORK"' EXIT
for IP in $(getent ahostsv4 "$HOST" | awk '{print $1}' | sort -u); do
openssl s_client -connect "$IP:443" -servername "$HOST" -showcerts </dev/null 2>/dev/null \
| awk -v d="$WORK" '/BEGIN CERT/{n++; f=d "/c" n ".pem"} f{print > f} /END CERT/{f=""}'
SERIAL=$(openssl x509 -in "$WORK/c1.pem" -noout -serial 2>/dev/null | cut -d= -f2)
OCSP=$(openssl x509 -in "$WORK/c1.pem" -noout -ocsp_uri 2>/dev/null)
if [ -z "$OCSP" ]; then
echo "$IP serial=$SERIAL no OCSP URL, check the CRL instead"
else
STATUS=$(openssl ocsp -issuer "$WORK/c2.pem" -cert "$WORK/c1.pem" -url "$OCSP" \
-CAfile /etc/ssl/certs/ca-certificates.crt 2>/dev/null \
| awk -F': ' '/c1.pem:/{print $2} /Reason:/{print "(" $2 ")"}' | tr '\n' ' ')
echo "$IP serial=$SERIAL ${STATUS:-unknown}"
fi
rm -f "$WORK"/c*.pem
done
Against nsp.gov.in this morning it printed 103.195.217.209 serial=85603881362DE427F5FB871517DAC9 revoked (superseded). The CA bundle path is Debian's. Change it for your distro.
Why every IP? Because the most common way to "fix" a mass revocation is to install the new certificate on the box you remember. The load balancer gets it, the second region doesn't, and nobody remembers the old origin behind a CDN bypass rule. Checking the hostname once gives you whichever backend DNS handed you, and that's how a revoked serial survives a fix everyone believes is finished. Checking from more than one place matters for the same reason.
Let's Encrypt certificates no longer carry an OCSP URL, so the script says so and stops. For those, use the CRL-based check from our HARICA post. It pulls the CRL from the leaf's distribution point, verifies the signature against the served issuer and looks for the serial.
eMudhra customers now have two problems
If you're on eMudhra, a working certificate today doesn't mean much. The ECC G3 root is on its way out of Chrome and Mozilla after the key incident. The RSA G1 hierarchy is where eMudhra was moving people, and that's the hierarchy that just revoked 9,356 certificates for a policy OID. And the company has announced it's leaving the business. Its press release promises replacements "free of cost from partners" without naming them. On 22 October someone in the incident bug asked eMudhra to say who those partners are and which roots they'll issue from.
Don't wait for the email. Move to a CA that plans to still be issuing TLS certificates next year. About 97% of eMudhra's G3 certificates were issued over ACME according to eMudhra itself, so for most people that's a directory URL change and a forced renewal. Worth doing while you're at it: make sure your client can switch CAs without a code change.
What to change this week
Add revocation status to whatever watches your certificates, right next to expiry. Run it against every address behind a name. Alert on revoked as loudly as you alert on "expires tomorrow". For Firefox users it's the same outage.
Stop using Chrome as your test oracle for certificate problems. Keep a Firefox profile around and open the site there when someone reports a TLS error you can't reproduce.
And if your CA supports ARI, make sure your ACME client reads it. A renewal window that suddenly lands in the past is how a CA tells your software to hurry. GoDaddy had to do it with emails, text messages and phone calls, and it still missed its own deadline by four days.
Frequently asked questions
Why didn't Chrome block the revoked GoDaddy and eMudhra certificates? Chrome doesn't check OCSP or CRLs online and relies on its CRLSet instead, which Google describes as mainly an emergency blocking mechanism. In CRLSet version 10861, the one Chrome was serving on 26 October 2026, there were no entries at all under the GoDaddy and Starfield issuing CAs named in the incident or under eMudhra's G2A-1 issuing CAs, so Chrome has no way of knowing these certificates are revoked.
Is a certificate revoked as superseded actually dangerous? Usually not in the security sense, since no private key was exposed and the domain validation was fine. It is an availability problem: Firefox desktop, SSL Labs and anything else that checks revocation will reject it, so part of your audience gets a full-page error while the rest see nothing wrong.
How can I tell if my GoDaddy certificate was one of the 404,607? Run an OCSP query against the certificate your servers are serving and look for a revoked status with reason superseded, or check the alerts on the SSL certificates page in your GoDaddy account. GoDaddy says it reissued affected certificates, but reissuing doesn't install anything, so a revoked serial can stay on a server until somebody replaces it by hand.
Does Let's Encrypt still support OCSP for this kind of check? No. Let's Encrypt certificates no longer include an OCSP URL, so you check them against the CRL listed in the certificate's CRL distribution point extension. The CRL route works for most other CAs as well, and it's the one Firefox's CRLite is built from.
Can I make Chrome check revocation online? Only through enterprise policy, according to the Chromium documentation, and online checks are soft-fail: if the OCSP responder or CRL can't be reached, the connection goes ahead. That's fine for an internal test machine, but don't treat it as a fix for your users, who will keep running the default settings.
