eMudhra Revocations: Indian Govt Sites Still Serve Revoked Certificates

On 19 October 2026 eMudhra revoked thousands of TLS certificates on its RSA hierarchy because they lacked a policy identifier its own rules require. Days later, 156 Indian government sites were still serving them. Firefox refuses those sites; Chrome, Edge and Android load them. If you hold an eMudhra certificate, check its serial against the CRL today and replace it.

This is not the G3 key compromise. That story, eight weak intermediate keys under the emSign ECC Root CA G3, is covered in eMudhra CA key compromise explained. This post is about a second, quieter event on the hierarchy that was not compromised, and about what it exposes: browsers disagree on revocation, a "works in Chrome" smoke test proves nothing, and the regulator's own India PKI site was among the sites we found still serving a revoked certificate when we checked on 24 October.

We re-ran the checks ourselves with openssl s_client, the eMudhra CRLs and the eMudhra OCSP responders at 07:22 UTC (12:52 IST) on 24 October 2026. Every revoked serial named below was still being served at that time. Sites are rotating, so re-run the commands in this post before you rely on any single row.

What happened

eMudhra runs two families of publicly trusted TLS roots under the emSign brand. The ECC Root CA G3 family is the one whose intermediate keys turned out to be recoverable. The RSA family under emSign Root CA - G1 was not part of that compromise, and eMudhra's 22 October press release says the G1 RSA roots "will continue to serve customers" during its exit from the TLS business.

The G1 problem is a compliance one. On 16 October 2026 at 08:14 UTC, an eMudhra employee filed Mozilla Bug 2082782, titled "eMudhra emSign PKI Services: TLS certificates missing certificate-type policy OID required by CP/CPS". The preliminary report says eMudhra issued TLS server certificates without the emSign certificate-type policy identifier, 1.3.6.1.4.1.50977.1.2.100, .110 or .120, that its own SSL/TLS CP/CPS specifies for DV, OV and EV certificates. It lists the source of disclosure as "Third party reported".

When a certificate was not issued according to the CA's CP/CPS, the CA/Browser Forum Baseline Requirements (section 4.9.1.1) say the CA should revoke within 24 hours and must revoke within 5 days, using reason code 4, superseded. On 19 October, between 13:34 and 13:49 UTC (15:34 to 15:49 CEST, 19:04 to 19:19 IST), eMudhra did exactly that. A security researcher who writes as Nemo at captnemo.in counted 9,356 certificates in that batch and found that it matches every unexpired certificate missing the type OID.

Revoking a certificate only changes a list. The website keeps serving the old certificate until its operator installs a new one. Nemo checked the 8,947 hosts in IGOD, the Government of India's directory of government websites, and found that as of 23 October 156 of them were still serving one of the revoked certificates. Four of the affected bodies sit under the Ministry of Electronics and IT (MeitY): STPI, Bhashini, UIDAI, and the Controller of Certifying Authorities (CCA), whose India PKI site is affected. The CCA is the authority that licenses and regulates certifying authorities in India, including eMudhra's Indian CA business.

Timeline

The dispute over impact

MeitY's 21 October thread responded to what it called fear mongering on social media. The post we fetched says the impact on Indian websites and applications was "very limited and for a very short interval". It was posted as a reply within a longer MeitY thread, and it is about the eMudhra incident as reported publicly, which at that point meant the G3 key problem.

Nemo disputes both halves of that statement. On duration, the flawed G3 keys were generated in April 2025, so they were recoverable for roughly 18 months before anyone reported them. On scope, the compromised intermediates issued very few certificates, but because Mozilla and Chrome are now distrusting the whole G3 root, eMudhra estimates about 30,000 certificates from its unaffected G3 intermediates must be migrated. Nemo adds that most of those appear to belong to US universities rather than Indian sites.

The G1 revocations are a separate measure of impact, and they are the one this post is about. They are measurable from outside: we can see which certificates are on the CRL and which sites are still serving them. On 24 October, five days after the revocation, a public certificate check of ayush.gov.in returned "Revoked" and "INSECURE", and our own checks below found the same for every host we tried from Nemo's list. Whether that counts as a "very short interval" is a judgment readers can make for themselves; the data is public.

We do not know whether eMudhra notified each subscriber before or after the revocation. Nemo says he is not sure eMudhra is doing so. eMudhra's press release says it "will reach out to affected customers to replace any certificate free of cost from partners through the transition". Neither source says when that outreach started, so treat any notice as possibly late and check your own certificates directly.

Who is affected

Four groups need to act, for different reasons.

Not affected by this event: Indian DSC and eSign signing services, which eMudhra says run separately from its global TLS infrastructure and continue as normal. That is eMudhra's statement, and it matches CERT-In's earlier reading covered in our eMudhra incident FAQ for Indian organisations.

Technical details

All values in this section come from three places: Mozilla Bug 2082782, Nemo's 23 October table, and our own checks at 07:22 UTC on 24 October against the live sites, crl.emsign.com and the emSign OCSP responders. Where a value is ours, we say so.

The policy OID problem

TLS certificates carry a Certificate Policies extension. Two kinds of identifiers usually appear there. The CA/Browser Forum reserves 2.23.140.1.2.1 for domain validated, 2.23.140.1.2.2 for organisation validated and 2.23.140.1.1 for extended validation certificates. A CA can also add its own identifiers that point to its CP/CPS.

Bug 2082782 says the emSign SSL/TLS CP/CPS requires a certificate-type identifier in every DV, OV and EV certificate:

The certificates we pulled from the affected sites carry the CA/Browser Forum OID and an emSign policy OID, but not the type OID. The G2A-1 certificates carry 1.3.6.1.4.1.50977.1.0.1.1; the certificates issued by emSign SSL CA - G1 carry 1.3.6.1.4.1.50977.1.0.1. The compliant replacement now served at punjabrajbhavan.gov.in carries 1.3.6.1.4.1.50977.1.2.100 as its first policy. That single line in openssl x509 -ext certificatePolicies output is the quickest way to tell an old certificate from a new one.

The missing OID does not make the cryptography weaker. Nobody has suggested these keys or certificates were misused. The revocation is required because the Baseline Requirements treat any certificate not issued according to the CA's own CP/CPS as one that must be revoked within five days. eMudhra's preliminary report also cites CP/CPS sections 1.1, 1.2, 7.1.2.2 and Appendix B sections 11.3 to 11.5, and Baseline Requirements section 4.9.1.1.

The chain

Every G2A-1 certificate we checked came with this chain:

0  CN=*.ayush.gov.in
   issuer: C=IN, O=eMudhra Technologies Limited, CN=EM DV TLS CA - G2A-1
1  CN=EM DV TLS CA - G2A-1
   issuer: CN=emSign Root TLS CA - G1
2  CN=emSign Root TLS CA - G1
   issuer: C=IN, OU=emSign PKI, O=eMudhra Technologies Limited, CN=emSign Root CA - G1
3  CN=emSign Root CA - G1 (self signed)

The certificates issued directly by emSign SSL CA - G1 (C=IN, OU=emSign PKI, O=eMudhra Technologies Limited) chain to the same root. The intermediates are not revoked. Only the leaf certificates are, so the chain still builds and validates in any client that does not check revocation.

The four CRLs

Nemo lists four CRLs that hold the 19 October revocations. We downloaded each at 07:22 UTC on 24 October.

Two notes on these numbers. The DV CRL's 6,235 entries match the figure Nemo gives for that CRL. The four CRLs together hold 6,208 entries timestamped inside the 13:34 to 13:49 UTC window, which is fewer than the 9,356 Nemo counts for the whole batch. The batch may include certificates under other G1 issuing CAs that we did not download, or certificates whose revocation times fall just outside the window we filtered on. We have not reconciled the difference, so treat 9,356 as Nemo's count and 6,208 as what is visible on these four CRLs.

One practical surprise: crl.emsign.com returned HTTP 403 to curl's default user agent and HTTP 200 once any explicit user agent was set. If your monitoring fetches CRLs with a bare HTTP client, check that it is not silently getting an error page.

Ten hosts we re-checked on 24 October

At 07:22 UTC (12:52 IST) on 24 October 2026 we connected to each host with openssl s_client, read the served leaf certificate, and looked up its serial on the issuer's CRL. For four of them we also asked the OCSP responder named in the certificate.

For comparison, punjabrajbhavan.gov.in, which Nemo's table marks as fixed, now serves serial 55B73870DC28B44D01E9975A8E294B from EM DV TLS CA - G2A-1, valid from 16 Oct 22:56:06 UTC to 23 Dec 2026. That serial is not on the DV CRL, and the certificate carries the DV type OID.

The ayush.gov.in and aaib.gov.in serials and revocation times match Nemo's table (15:39:12 and 15:46:53 CEST). The indiapki.cca.gov.in and lea.uidai.gov.in hosts are the CCA and UIDAI sites Nemo names in his text; they are not in his IGOD table, which suggests they are not listed in IGOD under those hostnames.

SHA-256 fingerprints of the served certificates, for anyone who wants to match exact files:

Shared wildcards multiply the problem

Nemo's 156 rows contain 123 distinct serials. Several government bodies use one wildcard certificate on many hostnames, so one missed rotation shows up many times. In his table, serial 2A370B1A40BDA535F3C0614204053 appears on 9 hosts under dgt.gov.in, serial A859351FFFD25301AB2FAC0CB93381 appears on 8 STPI hosts (www, Bengaluru, Bhubaneswar, Gandhinagar, Guwahati, Hyderabad, Kolkata, Thiruvananthapuram), 2322014B49FF5673E67753965E5F43 on 8 ICFRE institute hosts and 1D59844AC5EE2AAF3FDF708F63DEC5 on 5 Ladakh hosts. The same serial B1BBCA8C44E3FB7B046E25B07190A4 serves ayush.gov.in, yoga.ayush.gov.in and accr.ayush.gov.in.

By distinct serial, Nemo's list breaks down as 95 on the DV G2A-1 CRL, 14 on the G1 SSL CA CRL, 12 on the OV G2A-1 CRL and 2 on the EV G2A-1 CRL. The two EV certificates are the ones for www.isea.gov.in and nfscnagpur.nic.in.

Rotating a wildcard is only done when every server, load balancer, reverse proxy and CDN edge that holds a copy has the new one. Partial rotation is common, and it is why a site can look fixed from one network and broken from another.

Why browsers disagree

Revocation checking on the web has three main designs today, and the major browsers use different ones. That is the whole reason this event looks like an outage to some users and like nothing to others.

Firefox and CRLite

Mozilla's August 2025 engineering post explains that Firefox downloads a compact encoding of every revoked certificate that appears in Certificate Transparency logs, stores it locally, refreshes it every 12 hours and queries it on each new TLS connection. Mozilla says it enabled CRLite for all desktop users from Firefox 137 and planned to stop using OCSP for domain validated certificates in Firefox 142. Because CRLite covers every revocation, including administrative ones such as superseded, Firefox blocks these certificates. Mozilla's own argument for covering everything is that there is no reliable way to tell security revocations from administrative ones by reason code alone.

Chrome and CRLSet

The Chromium project describes CRLSets as "the primary means by which Chrome quickly blocks certificates in emergency situations". Google crawls CRLs disclosed to the CCADB and includes "a subset" of the revoked certificates it finds. Chrome does not generally perform online OCSP or CRL checks, though enterprise policy can turn online checks on. Google does not publish how the subset is chosen. Mozilla's 2025 post estimated that CRLSets carry about 1% of all revocations.

Nemo reports that CRLSet version 10856, dated 24 October, contains none of the 156 certificates and none of the 6,235 entries on the DV G2A-1 CRL. We checked the next version independently. At about 07:30 UTC on 24 October, Chrome's component updater served CRLSet 10857. It lists 201 parent issuers, 989 revoked serials and 178 blocked public keys. We computed the SHA-256 hash of the public key of EM DV TLS CA - G2A-1 (ceb5298daeb8f59279480b46002c89f7755cc3a169514b11b810befc195a00d8), EM EV TLS CA - G2A-1 (27616f251b91b3df6a241b45854a5db0a7b1bedd13a296f5cacb670aeac460e5) and emSign SSL CA - G1 (aafccd83af8f4bb25b08547e14bf9e01f1593a237aa575ec1f5b5cf5ab87945f). None of the three is a parent in CRLSet 10857, so none of their revoked serials can be in it, and none of the three keys is on the blocked list.

That is not a Chrome bug. It is how CRLSets are designed: an emergency mechanism, not a complete revocation feed. The practical lesson is that "the site loads in Chrome" tells you nothing about whether its certificate is revoked.

Safari on iOS

Nemo reports that Safari on iOS only checks OCSP for EV certificates. Two of the 156 certificates are EV. emSign's OCSP responder reports the www.isea.gov.in certificate as revoked, and Nemo says Safari on iOS refuses to load that site. Our own OCSP query for www.isea.gov.in at 07:22 UTC on 24 October returned revoked, reason superseded, revocation time 19 Oct 13:46:19 UTC. We did not test iOS devices ourselves.

API clients and back ends

Most programmatic TLS clients do not check revocation at all unless you configure them to. A bank's server calling a government API, a mobile app's backend pulling data from a portal, or a scheduled job downloading a gazette notice will all accept these certificates. For those clients the revocation changes nothing, which is fine for availability and means revocation is not a control you can rely on in your own integrations either.

How to check a site yourself

These commands are read only. They connect to a public HTTPS site, print the certificate it serves, and compare it to the issuer's own revocation data. Run them from a Linux or macOS shell with OpenSSL 3 or newer.

1. Read the served certificate

HOST=ayush.gov.in
echo | openssl s_client -connect "$HOST:443" -servername "$HOST" -showcerts 2>/dev/null > "$HOST.chain"
openssl x509 -in "$HOST.chain" -noout -serial -issuer -subject -dates -fingerprint -sha256
openssl x509 -in "$HOST.chain" -noout -ext certificatePolicies,crlDistributionPoints,authorityInfoAccess

Look at three things. The issuer tells you which CRL to fetch. The crlDistributionPoints URL is that CRL. In the policies, a certificate issued after the fix should show 1.3.6.1.4.1.50977.1.2.100 (DV), .110 (OV) or .120 (EV); if it shows only 1.3.6.1.4.1.50977.1.0.1.1 or 1.3.6.1.4.1.50977.1.0.1 and the CA/Browser Forum OID, it is from the affected population.

2. Check the serial against the CRL

CRL_URL=$(openssl x509 -in "$HOST.chain" -noout -ext crlDistributionPoints | grep -o 'http[^ ]*crl')
SERIAL=$(openssl x509 -in "$HOST.chain" -noout -serial | cut -d= -f2)
curl -s -A "crl-check/1.0" "$CRL_URL" -o issuer.crl
openssl crl -in issuer.crl -inform DER -noout -lastupdate -nextupdate
openssl crl -in issuer.crl -inform DER -noout -text | grep -A4 "Serial Number: $SERIAL"

If the last command prints a revocation date and Superseded, the certificate on that site is revoked. The -A flag matters for crl.emsign.com, which refused curl's default user agent when we tested. To confirm the CRL really comes from the issuer, save the issuer certificate as in step 3 and run openssl crl -in issuer.crl -inform DER -CAfile issuer.pem -noout, which prints verify OK for a valid signature.

3. Ask the OCSP responder

awk '/BEGIN CERT/{n++} n==1' "$HOST.chain" > leaf.pem
awk '/BEGIN CERT/{n++} n==2' "$HOST.chain" > issuer.pem
OCSP_URL=$(openssl x509 -in leaf.pem -noout -ocsp_uri)
openssl ocsp -issuer issuer.pem -cert leaf.pem -url "$OCSP_URL" -resp_text | grep -E "Cert Status|Revocation Time|Revocation Reason|This Update"

The G2A-1 certificates point at http://ocsp-a.emsign.com; the emSign SSL CA - G1 certificates point at http://ocsp.emSign.com. A healthy replacement certificate returns Cert Status: good.

4. Check a list of hosts

# hosts.txt: one hostname per line
while read -r h; do
  echo | openssl s_client -connect "$h:443" -servername "$h" 2>/dev/null > /tmp/c.pem || continue
  s=$(openssl x509 -in /tmp/c.pem -noout -serial 2>/dev/null | cut -d= -f2)
  i=$(openssl x509 -in /tmp/c.pem -noout -issuer 2>/dev/null | sed 's/.*CN *= *//')
  oid=$(openssl x509 -in /tmp/c.pem -noout -ext certificatePolicies 2>/dev/null | grep -c '50977.1.2.1[012]0')
  printf '%s\t%s\t%s\ttype_oid=%s\n' "$h" "$s" "$i" "$oid"
done < hosts.txt

Any row whose issuer is an emSign CA and whose type_oid is 0 needs a closer look with steps 2 and 3. Download each CRL once and reuse it rather than fetching it per host. On a host without a shell, certutil -verify -urlfetch site.cer on Windows also fetches the CRL and OCSP status for a saved certificate.

5. Look up certificates by issuer in CT

To find every emSign certificate logged for your domains, query crt.sh for your domain and filter by issuer name, or look up a serial directly, for example https://crt.sh/?serial=B1BBCA8C44E3FB7B046E25B07190A4. Our CT monitoring guide has the full queries and a monitor setup; we do not repeat them here.

6. See which CRLSet your Chrome is using

Open chrome://components and find the CRLSet entry. The version number tells you which CRLSet is loaded. It will not change what Chrome does with these certificates, but it is useful when you need to explain to a user why two browsers behave differently.

A runbook for Indian public sector and BFSI teams

This is the part of the response that falls on the organisations serving and consuming these sites. It is ordered by what tends to go wrong.

If you run a government site or host one for a department

1. Find every hostname on the old certificate. Take the serial from step 1 and search your own inventory, load balancer configs and CDN settings for it. Wildcards are the usual trap. If Nemo's list shows your serial on several hosts, they all share one certificate file somewhere.
2. Get a replacement. eMudhra says it will replace affected certificates free of cost through partners. eMudhra is also leaving the TLS business, so plan for the replacement to come from another CA. Our post on eMudhra's exit and what customers do now covers picking a CA, switching ACME and CAA, and handling pins.
3. Deploy to every terminating point. That includes origin servers, every node behind a load balancer, any web application firewall that terminates TLS, and CDN edges. Reload or restart the service; many servers only read certificate files at start.
4. Verify from outside. Run steps 1 to 3 again from a network outside your data centre. Confirm the serial changed, the new serial is not on any CRL, OCSP says good, and the policies now include the type OID if the new certificate is from eMudhra.
5. Test in Firefox. It is the only mainstream browser that reflects this revocation, so it is the right smoke test. Chrome loading the site proves nothing.
6. Record the change. Note the old and new serials, the time of rotation and who approved it. If the site is in scope for a CERT-In or departmental audit, that record is your evidence.

If you run a bank, NBFC, insurer or fintech that calls government endpoints

1. List the government hosts you call. Pull them from integration configs, API gateway routes and outbound proxy logs. Run the host loop from step 4 against that list.
2. Know how your clients treat revocation. Most server side clients do not check it. Some hardened Java deployments and some enterprise proxies do. A client that checks revocation and hard fails will start failing against any of these hosts; one that soft fails will log warnings. Find out which you have before an incident does it for you.
3. Do not paper over failures. If a client starts failing on a revoked government certificate, the right fix is on the server side. Do not disable certificate validation, add the revoked certificate to a trust store, or turn off revocation checks to restore service. Raise it with the department and track it.
4. Check your own estate too. Run the same commands against your public sites, internal portals and partner endpoints. Any emSign G1 certificate missing the type OID is either already revoked or should be treated as if it were.
5. Tell your service desk. Staff using Firefox will see errors on some government portals that colleagues on Chrome do not. A one line note saves hours of tickets.

If you set browser policy for an organisation

Chrome and Edge can be told to perform online revocation checks through enterprise policy. Those checks are soft fail by design: if the responder is unreachable, the page loads anyway. They add a network round trip and a privacy cost. For most organisations the better use of effort is to make sure the sites you depend on rotate, and to use Firefox or a CRL based checker as a test tool, not to change fleet wide browser behaviour in reaction to one event.

What changed since the first reports

• The scope moved from G3 to G1. Early coverage, including MeitY's statement, was about the eight compromised G3 ECC intermediates. The G1 revocations on 19 October are a separate, larger and more visible event for Indian site operators.
• The count of affected Indian government hosts became measurable. Nemo's 23 October scan put a number on it: 156 of 8,947 IGOD hosts. His table is being updated as rotations happen, and on our 24 October fetch it marked one row as fixed.
• Rotation is happening, slowly. Nemo's table has a "Cert Rotated" column and a separate "Fixed" column. On our fetch 144 rows said Yes under "Cert Rotated" and only one said Yes under "Fixed". We read that as replacement certificates existing for many hosts without having been deployed, but Nemo does not define the columns, so treat that reading as ours.
• CRLSet moved on, without these entries. Version 10856 per Nemo and version 10857 per our check both lack the emSign issuers.
• eMudhra announced its exit. That turns "replace this certificate" into "replace this certificate and plan a CA change", for every G1 customer.

Open questions

• Was each subscriber notified before 19 October? No public source we found says when or how eMudhra contacted the owners of the 9,356 certificates.
• Why the gap between 9,356 and the 6,208 we see on four CRLs? We did not download every G1 issuing CA's CRL. A full count needs the complete list of G1 issuers from the CCADB.
• How long will the G1 hierarchy remain trusted? eMudhra says G1 RSA roots continue during its transition. Browser root programs have not, in anything we fetched, set an end date for G1.
• Will the full incident report change the scope? Bug 2082782 is still a preliminary report with one comment and status ASSIGNED. The full report may add affected issuers or counts.
• Will other CAs' profile bugs follow the same path? GoDaddy's Bug 2082703, filed the day before, describes a similar mismatch between issued profiles and CP/CPS. Mass revocations of compliant looking but technically non conforming certificates are becoming a pattern, and operators should expect more.

What would have helped

Practices any team can use

• Monitor revocation, not only expiry. Most certificate monitoring alerts on expiry dates. Add a daily job that reads your served serials and checks them against the issuer's CRL or OCSP. The commands above are enough to start; a revoked serial should page someone the same way an expiring one does.
• Monitor CT for your domains. A CT monitor would have shown subscribers the new compliant certificate as soon as eMudhra issued it, which is a strong hint that the old one is about to be revoked.
• Automate issuance and deployment. Sites using ACME with automatic deployment can rotate within minutes of a CA issuing a replacement. Manual renewal through a reseller portal and a ticket to a hosting team is what turns a five day revocation window into weeks of serving a revoked certificate.
• Keep a map of where each certificate lives. For every serial, record every hostname, server, load balancer and CDN configuration that uses it. Wildcards make this essential.
• Keep a second CA ready. A tested fallback CA, with CAA records that already allow it, makes a forced CA change a configuration edit rather than a procurement exercise.
• Use Firefox as a test client. For any certificate change, a check in Firefox or with a CRL based tool catches revocation problems that Chrome will not show.
• Do not rely on revocation in your own clients. Treat revocation as a signal you monitor, not as a control your API clients enforce. Pin or validate what you need to by other means, and keep trust stores current.

Where Safeguard fits

Safeguard does not inventory deployed certificates, monitor CT, track revocation or manage CAs. For this event the main work is outside it: rotate certificates and verify with the commands above. Where it helps is the software around that work.

• Finding trust material in what you build. SBOM and dependency scanning covers repos, container images and SBOM files: safeguard scan --dir ., safeguard scan --image <name> or safeguard scan --sbom <file>, with JSON results under ./output. The platform shows which projects contain a given component and version, which is how you find images still shipping an outdated ca-certificates package or an old certifi pin while you are already touching TLS configuration. See SBOM incident response.
• Writing and running the checks with approval. The Safeguard CLI assistant can edit code and run commands with your approval. Here that means turning the host loop above into a scheduled job in your repository, adding a revocation check to a deployment pipeline, or updating an nginx or load balancer config to point at the new certificate files. Its /permissions modes run from Ask through Accept edits, Plan and Auto (the default) to Strict. safeguard exec runs a single non interactive turn for CI.
• Keeping old versions out. Policies and gates evaluated in the platform can hold back builds that still carry an outdated trust bundle.
• Approving from wherever you are. The desktop and phone apps can send work to a computer running the CLI and approve each command.

Where it does not help: Safeguard cannot rotate a certificate on a government server it has no access to, cannot change which revocations Chrome ships, and would not have prevented eMudhra's issuance error or the revocation.

Zero-Day Discovery and Gold

Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode, and issues findings as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems. A CA's certificate profiles, its CP/CPS compliance and browser revocation policy are outside that scope, and there is no CVE for this event.

Gold Open Source at gold.safeguard.sh is free and needs no login. It offers searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, a free read API and a CI gate GitHub Action. Gold Registry at registry.safeguard.sh is a paid service of hardened drop in components and container images held to zero exploitable critical or high CVEs, built to SLSA L3 or higher, Sigstore signed, with evidence pages; an artifact loses its badge if it regresses. For an event like this, the useful habit is the same one that applies to trust bundles: pull base images and components from a curated, signed source and rebuild quickly when trust material changes.

Common mistakes and troubleshooting

• "It works in Chrome, so it is fine." Chrome's CRLSet does not include these revocations. Test in Firefox, or check the CRL.
• Rotating one host of a wildcard. If the serial appears on several hostnames, every one of them needs the new file. Check each hostname from outside after the change.
• Forgetting the reload. Many web servers keep the old certificate in memory until reloaded. Copying the file is not enough.
• Checking from inside the network. An internal resolver or a different load balancer pool can show you a new certificate while the internet still sees the old one.
• A CRL fetch that returns HTML. crl.emsign.com answered curl's default user agent with HTTP 403 and an HTML page when we tested. If openssl crl says it cannot decode the file, check what you actually downloaded.
• Mixing up G1 and G3. The G3 ECC root is being distrusted because of the key compromise. The G1 RSA hierarchy is still trusted; only specific leaf certificates on it are revoked. The fix for a G1 site is a new certificate, not a trust store change.
• Disabling validation in a client. If a strict client fails against a revoked government certificate, escalate to the site owner. Turning off validation creates a real risk to fix a compliance one.
• Assuming an email was sent. Do not wait for a CA or reseller to tell you a certificate was revoked. Check.

FAQ

Is this the same as the eMudhra key compromise?

No. The key compromise affected eight intermediates under the emSign ECC Root CA G3. These revocations are on the RSA hierarchy under emSign Root CA - G1, which was not compromised. They happened because certificates were missing a policy identifier that eMudhra's own CP/CPS requires.

Are the revoked certificates dangerous?

Nobody has reported misuse of these certificates or their keys, and the missing identifier does not weaken the encryption. The risk is operational: Firefox users cannot reach the sites, strict clients may fail, and a site that keeps serving a revoked certificate trains users to click through warnings.

Why does Firefox block these sites when Chrome does not?

Firefox uses CRLite, which includes every revocation seen in CT logs. Chrome uses CRLSet, a curated subset that Google maintains mainly for emergencies. Nemo found none of these certificates in CRLSet 10856, and we found none of their issuers in CRLSet 10857.

How many Indian government sites were affected?

Nemo found 156 of 8,947 IGOD hosts serving a revoked certificate as of 23 October. Those 156 rows contain 123 distinct certificates. The CCA's India PKI site and a UIDAI host were also affected but are not in his IGOD table. We confirmed ten hosts, including both of those, still serving revoked serials at 07:22 UTC on 24 October.

Does MeitY's statement cover this?

MeitY's 21 October post said the impact on Indian websites and applications was very limited and brief. It responded to public discussion of the eMudhra incident, which at the time centred on the G3 keys. Nemo disputes it, and the G1 revocations left at least 156 government hosts serving revoked certificates four days after revocation, with the ten we checked still doing so after five.

My site uses an eMudhra G1 certificate. Is it revoked?

Possibly. Run the commands in "How to check a site yourself". If the policies lack 1.3.6.1.4.1.50977.1.2.100, .110 or .120 and the serial is on the CRL, replace the certificate now.

Will eMudhra replace it for free?

eMudhra's press release says it will reach out to affected customers to replace any certificate free of cost from partners through the transition. eMudhra is leaving the TLS business, so expect the replacement to come from another CA.

Does this affect DSC or eSign?

eMudhra says its digital signature certificate and eSign services, including those in India, run separately from its global TLS infrastructure and are not affected.

Should we turn on online revocation checking in Chrome?

Usually not as a reaction to this event. Chrome's online checks are soft fail and add latency. It is more effective to make sure the sites you depend on rotate, and to use Firefox or CRL checks for testing.

How long do sites have before these certificates expire anyway?

It varies. Of the ten we checked, www.trai.gov.in expires on 27 October 2026, while lea.uidai.gov.in runs to 5 January 2027. Waiting for expiry leaves some sites broken in Firefox for more than two months.

Fix it without waiting for upstream

Certificate revocation is a case where the fix has to come from each site operator, not from a library maintainer. For the software you build around that work, the same principle applies: you do not have to wait for someone else's release.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos shows eMudhra, a government site or a certificate rotation. Each is a real Safeguard session, and each intro says how the same flow applies to this event.

This real CLI session fixes a lodash CVE in a sample repository: the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and pushes nothing. For this event, you would open the repository that holds your infrastructure scripts, ask the assistant to turn the host loop from this post into a daily revocation check that fails when a served serial appears on its issuer's CRL, and approve each command as it runs the check against your hosts.

Click through it at your own pace, or open it full screen.

This real desktop app session shows the CLI session in the conversation list, a request for work on your computer, a folder pick, and Approve or Deny on each command and file edit, ending with an upgrade done and tests passing. For a hosting team rotating a shared wildcard, you would pick the folder with your web server or load balancer configs, ask for every reference to the old certificate files to be updated, and approve or deny each edit before anything reloads.

Click through it at your own pace, or open it full screen.

This real Android session sends work to a computer running the CLI and approves the command on the phone with Allow once, Allow for turn or Deny. When the revocation check fires in the evening, as it would have for anyone watching on 19 October at about 19:05 IST, the on call engineer could approve the verification commands from a phone and see the result straight away.

Click through it at your own pace, or open it full screen.

To try it on your own services, download Safeguard and follow the CLI docs. For the rest of the eMudhra story, read the G3 key compromise explained, the eMudhra FAQ for Indian organisations, CT monitoring after eMudhra and what eMudhra customers do now. For background, see what a certificate authority is and CERT-In's cyber security directions.

Quick check

Sources

• Nemo, "Indian government sites are serving revoked eMudhra certificates", captnemo.in, 23 Oct 2026
• Mozilla Bugzilla 2082782: eMudhra emSign PKI Services, TLS certificates missing certificate-type policy OID
• Mozilla Bugzilla 2082782 comments via REST API
• Mozilla Bugzilla 2082703: GoDaddy, Subscriber Certificate Profiles Did Not Conform to CP/CPS
• MeitY on X, 21 Oct 2026
• eMudhra press release: eMudhra to Exit global SSL/TLS Certificate Business, 22 Oct 2026
• CA/Browser Forum Baseline Requirements, version 2.3.1, section 4.9.1.1
• emSign CRL: EM DV TLS CA - G2A-1
• emSign CRL: EM OV TLS CA - G2A-1
• emSign CRL: EM EV TLS CA - G2A-1
• emSign CRL: emSign SSL CA - G1
• The Chromium Projects: CRLSets
• Mozilla Hacks: CRLite, fast, private and comprehensive certificate revocation checking in Firefox, Aug 2025
• Mozilla Security Blog: CRLite part 1, all web PKI revocations compressed, Jan 2020
• crt.sh lookup for serial B1BBCA8C44E3FB7B046E25B07190A4
• SSL Labs result for ayush.gov.in
• IGOD, Integrated Government Online Directory
• Chrome CRLSet component 10857, fetched via the Chrome component updater on 24 Oct 2026

Last reviewed: 24 October 2026. This is a developing story; check the linked advisories for the latest status.