eMudhra Certificate Revoked, Still Live on Smart City Sites
eMudhra revoked its certificates after a weak-key flaw: browsers fixed it within hours, but smart city websites still use the cancelled certificates
This post argues that the eMudhra certificate incident is a test of the software a city runs, not of the browsers its staff use. Chrome and Firefox blocked the eight compromised eMudhra keys within hours of the report on 17 October.[1][2] Yet when we checked on the morning of 28 October, the websites of Pune Smart City, Smart City Patna and Moradabad Smart City were still serving certificates that eMudhra had revoked nine days earlier, and a standard Python connection accepted all three without a warning. Command centres, building systems and field devices exchange data through that kind of software, so a browser check tells a city little about its own systems.
Two separate events are involved. The first is the compromise of eight intermediate keys under the emSign ECC Root CA – G3, which led Google to schedule that root’s removal from the Chrome Root Store for 27 October.[1] The second is a batch of 9,356 certificates that eMudhra revoked on 19 October on its unaffected RSA hierarchy; that batch is what left Indian government sites on revoked certificates.[3] Both reach smart city systems in different ways.
Eight signing keys could be worked out in seconds, and browsers fixed it within a day
A certificate authority’s signing keys are meant to be random numbers that nobody can guess. CERT-In’s advisory says the eight eMudhra private keys had values smaller than 256 and “could be recovered almost instantly” from their public keys, because of a fault during key generation rather than any weakness in the P-384 algorithm.[4] The Hindu reported that one key was the number 4, preceded by 383 zeroes.[5] Anyone holding such a key could issue fake certificates for websites they do not control and, with access to the network path, intercept or alter encrypted traffic.[4]
The browser response was quick. Google says it received the report at 18:05 UTC on 17 October and pushed a block at 19:45 UTC, without users needing to update or restart Chrome.[1] Mozilla says its OneCRL block reached all Firefox users with standard settings in under three hours.[2] eMudhra says the affected intermediates issued no end-entity certificates.[6] CERT-In says the public disclosures did not establish confirmed malicious use as of 21 October.[4]
The Ministry of Electronics and Information Technology (MeitY) formed a special team to investigate, said the impact on Indian websites had been “very limited and for a very short interval”, and said Digital Signature Certificates and eSign services regulated by the Controller of Certifying Authorities were unaffected.[5] On 22 October eMudhra’s board decided to withdraw from the global SSL/TLS certificate business, which the company says contributes about 1% of its revenue; its RSA G1 roots continue to serve customers during the transition.[7]
Revoked certificates still loaded on smart city websites nine days later
The 19 October revocations were not about the weak keys. Nemo, the researcher who has tracked them, matched the batch to certificates missing a policy identifier that eMudhra’s own rules require. His 24 October update counted 1,366 Indian government domain names on revoked certificates, 773 of them still serving the revoked certificate.[3] Whether such a site opens depends on the browser: Firefox carries a near-complete local list of revocations and refuses them, while Chrome, Edge and Android load them because Chrome’s revocation list did not include these certificates.[3][8] Safeguard, which re-checked hosts independently, adds that curl, Python requests, Java, Go and most API clients do not check revocation by default.[8]
We took the city-related names from Nemo’s published list of revoked certificates and connected to each from our own server between 10:01 and 10:02 IST on 28 October. We compared the serial number each site served with the serials eMudhra revoked on 19 October, and also tried a connection using Python’s default certificate checks, which validate the chain but do not check revocation.
| Site | What it served on 28 Oct 2026 | Default Python check |
|---|---|---|
| Pune Smart City (punesmartcity.in) | Same eMudhra certificate revoked on 19 Oct | Accepted |
| Smart City Patna (smartpatna.co.in) | Same eMudhra certificate revoked on 19 Oct | Accepted |
| Moradabad Smart City (smartcitymoradabad.org) | Same eMudhra certificate revoked on 19 Oct; it also expires on 3 Nov 2026 | Accepted |
| Kanpur Jalkal OTS portal (ots-jalkalkanpur.in) | Same eMudhra certificate revoked on 19 Oct | Accepted |
| Kanpur Jalkal main site (jalkalkanpur.in) | Older eMudhra certificate that expired on 20 Sep 2026 | Rejected: expired |
| Dharamshala smart city domain (dharamshalasmartcity.com) | New eMudhra certificate issued 12 Oct | Rejected: name does not match the domain |
| Diu smart city domain (diusmartcity.com) | New eMudhra certificate issued 16 Oct | Rejected: server does not send the full chain |
| Ghaziabad Nagar Nigam (ghaziabadnagarnigam.in) | New eMudhra certificate issued 15 Oct | Accepted |
| Pune Metro Line 3 (punerimetro.in) | Moved to Let’s Encrypt | Accepted |
| Smart City Jhansi (smartcityjhansi.com) | Could not read the certificate | Refused: server lacks secure renegotiation support |
Four sites were serving a revoked certificate, and the ordinary check most scripts and integrations use accepted every one. Three had moved to new eMudhra certificates, from a company leaving the business, and two of those fail strict validation for other reasons. Only one had changed certificate authority. Our reading is that certificate upkeep is often nobody’s assigned job once the website vendor has finished.
Field devices and data feeds do not get the browser fix
Browsers receive revocation and distrust updates automatically. Many other systems do not. CERT-In’s advisory lists “operators of embedded devices” among its audience, and asks organisations to examine “applications, programming-language runtimes, container images, TLS libraries, network appliances and embedded systems that maintain separate CA certificate bundles or do not reliably check certificate revocation”. Where vendor support is unavailable, it asks them to assess exposure and apply compensating controls.[4] The Hindu BusinessLine, reporting the advisory, noted that the risks are greater for older devices and systems that do not frequently update their trust stores.[9] Yash Kakadia of Security Brigade told The Hindu that the impact could extend to Internet of Things (IoT) devices that are not patched often: “The cleanup could be enormous, particularly for devices and software that cannot be easily updated.”[5]
In a smart city, those are the systems that matter. An integrated command and control centre (ICCC) pulls feeds from traffic signals, cameras, water SCADA and citizen apps, and a building management system talks to cloud dashboards and remote-support portals, often over encrypted connections. CERT-In’s own Cyber Security Guidelines for Smart City Infrastructure ask cities to issue digital certificates for all devices and users, use mutual TLS between systems, and automate certificate lifecycle management.[10] A trust store that is never updated keeps trusting what browsers have already dropped. We covered a related gap, AI agents reaching exposed building interfaces, in our note on CERT-In’s AI agent alert.
Five checks every smart city SPV can finish this week
These follow CERT-In’s advisory and NIST’s guidance on running a formal certificate management programme that can prevent, detect and recover from certificate incidents.[4][11]
- List every certificate, not just the website’s. Include the citizen portal, ICCC dashboards, mobile app back ends, VMS and BMS web consoles, IoT gateways and vendor APIs, with the issuer, expiry date and the person responsible for each.
- Check revocation as well as expiry. Test with a tool that reads the issuer’s revocation list, not only a browser; “it opens in Chrome” proved nothing in this incident.[8] Replace any certificate on eMudhra’s 19 October list now.
- Decide where new certificates come from. Moving to another eMudhra certificate buys time, but the company is leaving the business. Choose a long-term issuer once, and write it into the website and ICCC operations contracts.
- Ask each OEM how its devices learn about distrust. Get a written answer on whether cameras, controllers, gateways and appliances use their own CA bundle, how that bundle is updated, and whether the emSign ECC Root CA – G3 has been removed.[4]
- Never switch verification off to restore a feed. CERT-In warns against bypassing certificate warnings or disabling verification.[4] If an integration breaks, fix the certificate, and record who approved any temporary exception and when it ends.
For SPVs reviewing who supplies which security layer, our guide to cyber security OEMs matched to the layer maps vendors to devices, networks and identity. The control rooms guide explains how ICCC feeds are integrated, which is where a certificate inventory should start.
Planning a command and control centre? Talk to Trisim Global Solutions.
Trisim’s view: certificates need an owner in the O&M contract
The eMudhra keys were a certificate authority’s failure, and browsers contained it. The revoked certificates still live on city websites are a different failure, one of ownership. Certificate renewal, revocation checks and trust-store updates for every ICCC feed and field device should be named tasks with a named owner, checked every month like uptime.
Sources
- Google Security Blog (Chrome and Android Security Teams), Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates, 20 October 2026
- Mozilla Security Blog, Protecting Firefox users following the compromise of eMudhra intermediate certificates, 20 October 2026
- Nemo’s Home (captnemo.in), Indian government sites are serving revoked eMudhra certificates, 23 October 2026, updated 25 October 2026
- CERT-In, CIAD-2026-0050: Compromise of eMudhra Intermediate CA Certificates, 21 October 2026
- The Hindu, Eight web security keys of eMudhra firm used by Govt. and PSUs leaked, 21 October 2026
- eMudhra, eMudhra Statement on Recent Certificate Security Incident, updated 26 October 2026
- eMudhra (press release), eMudhra to Exit global SSL/TLS Certificate Business, 22 October 2026
- Safeguard Blog, eMudhra Revocations: Indian Govt Sites Still Serve Revoked Certificates, 24 October 2026
- The Hindu BusinessLine, eMudhra’s flawed certificate triggers CERT-In probe and raises questions on digital trust, 22 October 2026
- CERT-In, Cyber Security Guidelines for Smart City Infrastructure, February 2025
- NIST, SP 1800-16: Securing Web Transactions: TLS Server Certificate Management, June 2020
Disclaimer
Smartcitiesmission.com is an independent advisory and editorial body. It has no relation with any government agency and is associated with private commercial business houses. This article is published for information and public interest only. It is not legal, security or procurement advice, and it is not a security audit of any organisation.
The observations about named websites come from a connection to each public website from our own server between 10:01 and 10:02 IST on 28 October 2026, compared with a published third-party list of certificates that eMudhra revoked on 19 October 2026. We did not access, test or attempt to enter any system beyond the public website, and we are not aware of any misuse of the certificates named. Certificates may have been replaced since, and a site that was serving a revoked certificate at that moment is not evidence of a breach, negligence or non-compliance by any organisation. Naming a body in this article is not an allegation against it.
Revocation status was confirmed by matching serial numbers against a third-party list, because eMudhra’s own revocation list and status server could not be reached from our server. Figures and statements attributed to CERT-In, MeitY, Google, Mozilla, eMudhra and others are as reported in the sources listed above. If you represent an organisation named here and wish to comment or correct a detail, write to info@smartcitiesmission.com and we will review it promptly and update this article where appropriate.