Every time a customer sees the padlock next to your website address, they are trusting a chain of digital certificates they never think about. This week, one link in that chain broke. The eMudhra certificate compromise, disclosed on 20 October 2026, showed that eight certificates belonging to eMudhra, a Bengaluru-based certification authority, had private keys so weak that anyone could work them out in under a second.
Google, Mozilla, Apple and Microsoft moved within days to block those certificates, and Mozilla has removed trust in the eMudhra root certificate that signed them. For most people browsing on an up-to-date phone or laptop, that protection is already in place. For businesses, the picture is less simple. Websites using certificates from the affected root need new ones, and servers, mobile apps, payment callbacks, CRM connectors and WhatsApp webhooks that carry their own list of trusted certificates may still trust the bad ones until someone updates them.
This guide explains what happened in plain language, who is affected and who is not, how to check your own SSL certificate in five minutes, and a practical 7-day checklist for Indian businesses. You do not need to be a security engineer to follow it, but you will want to share it with whoever runs your website and servers.
At a Glance
- What happened: eight eMudhra intermediate certificates, six for websites (TLS) and two for code signing, were created in April 2025 with private keys that were tiny numbers. One of them was the number 4.
- The risk: anyone holding those keys could issue fake certificates for any website and impersonate it, intercepting or altering traffic.
- The response: Chrome and Firefox blocked the certificates on 17 October, eMudhra revoked them on 18 October, Apple followed on 19 October and Microsoft on 20 October. Mozilla removed the "emSign ECC Root CA – G3" root, and Google is removing it from Chrome.
- Who must act: businesses whose website certificates chain to that root (eMudhra estimates about 30,000 customer certificates), and anyone running servers, apps or devices with their own certificate lists.
- Not affected, per eMudhra: its Indian Digital Signature Certificate (DSC) and eSign services, which run on separate systems.
- What to do now: check your certificate issuer, replace any eMudhra-chained certificate, update operating systems, runtimes and container images, and never "fix" errors by turning off certificate checks.
What Happened: The eMudhra Certificate Compromise Explained
A researcher signs a message with eMudhra's keys
On 17 October 2026, a researcher who signs as "Wayne" was checking certificates in the Common CA Database, the shared register that browser makers use to track certificate authorities. According to Help Net Security, he found that the private keys behind eight eMudhra intermediate certificates could be recovered directly from the public certificates. To prove it, he signed the message "We have a problem here – Wayne" with each key and reported it to Apple, Google, Microsoft, Mozilla and eMudhra.
The keys were not just weak; they were almost absurdly small. Security researcher Scott Helme recovered them and published the values: 4, 56, 115, 156, 230, 155, 66 and 237. These certificates use the P-384 elliptic curve, where a private key should be a random 384-bit number with roughly 10115 possible values. A key below 256 can be found by simple trial in a fraction of a second.
A faulty script in a key ceremony
Certificate authorities create their most important keys in a formal, witnessed process called a key ceremony. eMudhra has traced the problem to a faulty script used in its ceremony of April 2025. As reported by Help Net Security, the script produced a second, weak set of keys with labels similar to the correct ones, and staff selected the weak set. Of 24 intermediates generated on 30 April 2025, eight were affected: six that issue TLS certificates for websites and two for code signing. All eight were cross-signed by Sectigo in May 2025, which is why they were trusted so widely.
eMudhra says only one of the eight intermediates was put into production and none was used to issue customer certificates. It has admitted human error at several steps and says it will re-check every key ceremony it has conducted. What nobody can say for certain is whether someone found and misused the keys in the roughly 17 months before the report. Cloudflare, which patched its own services before public disclosure, said its review "has not identified active exploitation of this issue on Cloudflare services."
How the browsers and operating systems responded
- 17 October: Chrome pushed a block through its CRLSet update that evening, and Mozilla blocked the intermediates through OneCRL a few hours later.
- 18 October: eMudhra revoked the certificates.
- 19 October: Apple blocked them.
- 20 October: Microsoft blocked them. Mozilla made the incident public and shipped an update removing eMudhra's "emSign ECC Root CA – G3" root from its trusted list.
- Next: Google says the root is being removed from the Chrome Root Store, reportedly on 27 October according to ThePrint, citing CERT-In. Chrome is also "conducting a thorough evaluation" of eMudhra's remaining CA certificate. Mozilla is not removing that other root for now.
The response was fast because the root programmes are designed for exactly this. Mozilla's Dennis Jackson still described the stakes bluntly: "the impact of this incident could not be higher." Markets agreed: ThePrint reported that eMudhra's shares fell 20% on the NSE on 21 October.
Why It Matters: How SSL Certificates Protect Your Customers
An SSL certificate (strictly, a TLS certificate) does two jobs. It encrypts the connection between a visitor and your website, and it proves that the website really is yours. That second job depends on a chain of trust. Your certificate is signed by an intermediate certificate, which is signed by a root certificate. Browsers, phones and servers ship with a list of roots they trust, called a trust store, and accept any certificate that chains back to one of them.
If an attacker has an intermediate's private key, they can sign a certificate for any domain, including your bank's, your payment gateway's or your own. Combined with a position on the network, such as a compromised Wi-Fi router, they can then sit in the middle of a connection that shows a perfectly normal padlock. That is why Cloudflare called it "a serious security incident with implications across the Internet," and why CERT-In, according to ThePrint, warned that attackers could intercept traffic and steal passwords or data, leading to financial fraud.
The two code-signing intermediates add a second risk. Code-signing certificates tell an operating system that software comes from a known publisher. With those keys, malware could be made to look legitimately signed.
Who Is Affected, and Who Is Not
You need to act if:
- Your website or API uses an eMudhra or emSign certificate that chains to the removed root. eMudhra estimates about 30,000 customer certificates need to move to its other root, and some genuine customer certificates will stop working when browsers remove the root.
- You run servers, containers or scripts that make HTTPS calls. Many non-browser clients use a certificate bundle on disk and do not check revocation, so they will keep trusting the bad intermediates until updated.
- You ship a mobile or desktop app with its own trusted list, or use certificate pinning.
- You use devices that rarely get updates, such as point-of-sale terminals, kiosks, IoT sensors and routers. Scott Helme notes that devices with frozen firmware will trust these certificates until they expire, which is not until 2039.
You are probably fine if:
- Your visitors use up-to-date Chrome, Firefox, Safari or Edge. These already block the compromised certificates.
- Your certificate comes from another authority, such as Let's Encrypt, DigiCert, Sectigo or GoDaddy, and your servers and apps are patched.
- You use eMudhra only for Digital Signature Certificates or eSign for tax returns, provident fund filings or e-tenders. eMudhra told the stock exchanges these run on separate systems. If in doubt, ask your DSC provider.
No credible source has published a list of affected Indian websites, so the only reliable answer for your business is to check.
How to Check Your SSL Certificate in Five Minutes
1. Look at the issuer in your browser
Open your website, click the padlock or the site-settings icon next to the address, choose the option to view the certificate and look at "Issued by". If the issuer or any certificate in the chain mentions eMudhra or emSign, you need to act. Repeat for every domain and subdomain you run, including shop, app, API and payment subdomains.
2. Check from the command line
Your developer or hosting provider can check any domain in seconds with OpenSSL:
openssl s_client -connect yourdomain.com:443 \
-servername yourdomain.com </dev/null \
| openssl x509 -noout -issuer -enddate
This prints the issuing certificate authority and the expiry date. An issuer such as "EM DV TLS CA - G3B" means the certificate came from one of the affected eMudhra intermediates.
3. Test whether your servers still trust the bad certificates
The public disclosure site run by Mozilla's Dennis Jackson offers test hosts that use the compromised chain. From any server, run:
curl https://dv-g3b-emudhra.we-have-a-problem.com/
A certificate error is the good result: it means that machine no longer trusts the compromised intermediates. If the page loads, that server's certificate bundle is out of date. Run the same test from each server, container image and build agent you use.
4. List every certificate you own
Most businesses discover certificates they had forgotten: an old landing page, a staging server, a payment callback URL or a mail server. Write each one down with its issuer, expiry date and who renews it. That list is the foundation of everything else in this guide.
If Your Certificate Is From eMudhra: Replace It Safely
- Contact eMudhra or your reseller. eMudhra says affected customer certificates must move to its other root, so ask for a reissue and the timeline.
- Or switch authority. You can buy from another commercial CA or use a free, automated authority such as Let's Encrypt for standard websites. Weigh this against any contractual or compliance requirement for a particular type of certificate.
- Generate a new private key. Do not reuse the old key with the new certificate. Create a fresh key and certificate signing request (CSR).
- Install the full chain. Install the new certificate with its correct intermediate chain on every server, load balancer and CDN that serves the domain.
- Test before and after. Re-run the OpenSSL check, test in several browsers and devices, and check APIs and mobile apps that call the domain.
- Revoke the old certificate once the new one is live everywhere.
If you use Cloudflare in Full (strict) mode, Cloudflare advises reviewing custom origin certificates as well, since a distrusted certificate on your origin server can break the connection between Cloudflare and your site.
The Hidden Risk: APIs, Apps, Payments and WhatsApp
Browsers fixed themselves within days. The software running your business may not have. Every program that makes an HTTPS call, from a PHP payment callback to a Node.js CRM sync, decides whom to trust using a certificate list, and many ship their own.
Update every trust store
The disclosure site lists patched versions for the main operating systems and runtimes, including the ca-certificates package on Ubuntu, Debian, Fedora and Alpine, Node.js, Java, Go, Python's certifi and pip, and the curl CA bundle. In practice:
- Run operating system updates on every server and virtual machine.
- Upgrade language runtimes and the
certifipackage in Python projects. - Rebuild and redeploy Docker images once their base images include the fix. A running container keeps its old certificate list.
- Check apps with bundled certificate lists or pinning, and ship app updates if needed.
- Ask vendors of payment terminals, kiosks and other devices when they will push an update.
Payment gateways, CRMs and webhooks
Integrations work in both directions. Your server calls the gateway, CRM or ERP, so your trust store must be current. The gateway, in turn, calls your server with payment confirmations and webhooks, so your certificate must be one they trust. If your API certificate chains to the removed root, those callbacks can start failing quietly, leaving orders marked unpaid or leads that never reach your CRM.
WhatsApp Business API webhooks
WhatsApp is a clear example. Meta's developer documentation states that "your webhook endpoint server must have a valid TLS or SSL digital security certificate" and that "self-signed certificates are not supported." If you host your own WhatsApp Business API webhook and its certificate is from the affected eMudhra chain, Meta may stop delivering incoming customer messages and delivery updates once that certificate is no longer trusted. Check the certificate on your webhook URL today.
This is one reason many businesses prefer a managed platform. With ConverseIQ, CodeBase Coders' own WhatsApp marketing software, Meta delivers messages to the platform's servers, so you do not run or renew a webhook certificate yourself. You get a shared team inbox, broadcasts, chatbots, an AI assistant and a built-in CRM, while the infrastructure is looked after for you. Read more in our ConverseIQ launch post and our WhatsApp Business API guide.
Never switch off verification
When a certificate error suddenly appears, the quickest "fix" is to turn off certificate checking in code, for example with verify=False in Python or a CURLOPT_SSL_VERIFYPEER setting in PHP. Cloudflare's advice is direct: "It's important to not resolve these errors by disabling verification." Doing so removes the exact protection that keeps forged certificates out. Fix the certificate or the trust store instead.
A 7-Day Certificate Security Checklist
- Day 1, inventory: list every domain, subdomain, API endpoint, webhook URL and mail server, with its certificate issuer and expiry.
- Day 2, check the issuer: flag anything that chains to eMudhra or emSign, and contact your CA or reseller about replacements.
- Day 3, replace: issue new certificates with new keys, install the full chain and test each domain.
- Day 4, patch servers: update operating systems,
ca-certificates, runtimes and libraries, then run the curl test on each machine. - Day 5, rebuild: rebuild container images, redeploy services and check CI/CD build agents.
- Day 6, test integrations: confirm payment callbacks, CRM syncs, WhatsApp webhooks and mobile app API calls still work end to end.
- Day 7, automate: set up automatic renewal where possible, plus expiry and certificate-change monitoring with alerts to more than one person.
Lessons for Indian Businesses
Treat certificates as assets, not one-off purchases
Many small businesses buy a certificate once and forget it until the site breaks. A simple inventory, with an owner and an expiry date for each certificate, turns a scramble like this week's into a routine task.
Automate renewal and monitoring
Automated issuance through the ACME protocol, used by Let's Encrypt and several commercial authorities, means certificates are renewed and replaced without anyone remembering a date. Pair it with monitoring that alerts you when a certificate is about to expire or changes unexpectedly.
Keep software patched by default
This incident was fixed for most people by ordinary updates. Businesses running outdated servers, end-of-life runtimes or old Docker images remain exposed the longest. If your applications are hard to update, that is a legacy modernisation problem worth solving before the next incident.
Security is part of compliance
Under India's Digital Personal Data Protection framework, businesses are expected to take reasonable security safeguards to protect personal data. Encrypted, correctly verified connections are a basic one. Our DPDP Act compliance checklist covers the wider picture, and our guide to protecting API keys and data covers another fast-growing risk.
Know who to call
When something like this happens, the businesses that recover fastest know who looks after their website, servers and integrations. If the honest answer is "nobody in particular," fix that now, whether with an in-house person, your hosting provider or a managed IT partner.
Conclusion
The eMudhra certificate compromise is a reminder that the padlock on your website depends on systems most businesses never see. Browsers responded within days, and most visitors are already protected. The remaining risk sits with businesses: certificates that chain to the removed root, and servers, apps, devices and integrations that still trust the compromised intermediates.
The fix is not complicated. Check your certificate issuer, replace anything from the affected chain, update every trust store, test your payment, CRM and WhatsApp integrations, and automate renewal and monitoring so the next incident is a non-event. If you would like a second pair of eyes, our free website audit is a good place to start.
Frequently Asked Questions
What is the eMudhra certificate compromise?
It is a security incident disclosed on 20 October 2026 in which eight intermediate certificates of eMudhra, an Indian certification authority, were found to have extremely weak private keys. Anyone could recover the keys and use them to issue fake website or code-signing certificates. Browsers and operating systems have blocked the certificates.
How do I know if my website uses an eMudhra SSL certificate?
Click the padlock in your browser, view the certificate and check "Issued by", or run the OpenSSL command in this guide. If eMudhra or emSign appears anywhere in the chain, contact your certificate provider about a replacement.
Will my website show an SSL certificate error?
If your certificate chains to the removed "emSign ECC Root CA – G3" root, visitors may see certificate errors as browsers remove that root. Certificates from other authorities are not affected, although your own servers still need updated trust stores.
Are eMudhra digital signature certificates (DSC) for GST or income tax affected?
eMudhra says its Indian Digital Signature Certificate and eSign services run on separate systems from the affected website certificates. If you rely on a DSC, check with your provider for confirmation.
Do I need to do anything if I only use Chrome or Firefox?
As a visitor, keep your browser and operating system updated and never click through certificate warnings. As a business, you also need to check your own certificates and the servers and apps you run.
How can CodeBase Coders help after the eMudhra certificate compromise?
CodeBase Coders can check which certificates your websites, APIs, mobile apps and servers use, replace any certificate that chains to eMudhra, update trust stores in servers, containers and apps, and set up automatic renewal and expiry monitoring so this does not catch you out again. We also review payment, CRM and WhatsApp integrations that call your servers. Start with a free website audit, see our DevOps services and managed IT services, or talk to our team.
Sources
- Help Net Security (21 October 2026): eMudhra security blunder left trusted CA signing keys exposed to anyone
- The Register (20 October 2026): Indian certification authority eMudhra's private keys compromised
- Scott Helme (20 October 2026): Eight bits of trust: eMudhra's CA keys cracked in milliseconds
- Cloudflare (20 October 2026): eMudhra certificate compromise
- ThePrint (21 October 2026): What's the eMudhra security scare that has rattled the internet?
- eMudhra Intermediate CA Compromise: disclosure, tests and patched versions
- Mozilla Bugzilla: eMudhra incident report
- Meta for Developers: Create a WhatsApp webhook endpoint
Work With CodeBase Coders
CodeBase Coders helps businesses turn ideas into scalable digital products and improve existing processes through software, automation, AI, integrations and modern web technologies. After the eMudhra certificate compromise, we can audit your certificates, replace and automate them, patch servers and containers, and test the payment, CRM and WhatsApp integrations your business depends on.
- Free Website Audit
- DevOps Services
- Managed IT Services
- IT Audit Services
- Software & API Integration Services
- Web Application Development
- Mobile App Development
- ConverseIQ WhatsApp Marketing Software
Not sure whether your website, apps or integrations are affected? Talk to CodeBase Coders and we will check your certificates and help you fix anything that needs attention.
Rohan Verma
Founder, CodeBase CodersRohan Verma is the founder of CodeBase Coders. He helps startups, SMEs and enterprises turn ideas into scalable digital products and improve business processes through custom software, AI, automation, integrations and modern web technologies.