Two SSL/TLS Trust Failures This Week — What Healthcare Organizations Need to Check Before October 27

Web Security

Two separate SSL/TLS certificate incidents landed this week within days of each other. One involves a CA private key compromise that left eight intermediate certificates mathematically broken — and browsers are removing trust in the root entirely on October 27. The other involves GoDaddy revoking over 400,000 incorrectly issued certificates, with replacement installation required before affected sites become inaccessible.

They have different causes and different action items. This post covers both, with a focus on what healthcare organizations need to check.

Incident One: eMudhra CA Private Key Compromise

On October 17, a security researcher known as Wayne discovered that eight intermediate CA certificates issued by eMudhra had their private keys generated with insufficient cryptographic randomness. The entropy was so weak that the private keys can be computed directly from the public certificates — no attack required beyond basic mathematics. A second researcher, Flüpke, demonstrated this publicly by publishing one of the recovered private keys on GitHub. The private key for eMudhra's "EM OV TLS CA - G3C" intermediate certificate had a numeric value of 4.

eMudhra is an Indian certificate authority whose international TLS certificate infrastructure is trusted by major browsers. The affected certificates are not part of eMudhra's India-regulated Digital Signature Certificate or eSign services — those systems are separate and unaffected. The compromise affects the international TLS hierarchy used for website HTTPS certificates.

The browser response was rapid. Mozilla blocked the compromised certificates through Firefox's OneCRL revocation system on October 17, without requiring a browser update or restart. Google Chrome blocked the six compromised intermediates authorized to issue TLS certificates on the same day. Apple added protections on October 19. Mozilla additionally released Firefox 158.0.1 on October 20 for users whose browser configurations prevented them from receiving the earlier revocation updates.

The October 27 Deadline

The hard deadline is October 27. Chrome's Root Store removal — which will remove trust in the emSign ECC Root CA - G3 root for all Chrome and Android devices — is scheduled for that morning. Any website whose TLS certificate chains to emSign ECC Root CA - G3 will show certificate errors in Chrome after that date.

The Chrome Root Program's advisory is explicit: website operators with certificates chaining to emSign ECC Root CA - G3 must immediately acquire and install a new TLS certificate from another CA hierarchy included in the Chrome Root Store. Waiting until October 27 to begin that process is not a viable timeline.

No TLS certificates chaining to the six intermediates used for public websites had been logged to Certificate Transparency before Chrome's block, meaning none could have been trusted by default in Chrome or any other browser requiring CT logging. eMudhra has stated that its infrastructure was not otherwise compromised and that no data breach occurred.

The Embedded Software Problem

The browser vendors have moved quickly. The more durable concern is software that does not use browser certificate stores and does not automatically receive revocation updates. Mozilla's advisory explicitly flags this: software that uses its own bundled certificate store, or that does not check certificate revocation, may continue trusting the compromised intermediates until it is explicitly updated.

This category includes medical devices, healthcare software running in isolated environments, embedded systems in clinical equipment, and legacy applications with bundled CA stores. If any of those systems trust eMudhra's CA hierarchy and present eMudhra-chained certificates, or perform TLS validation against endpoints that present such certificates, the revocation updates that protect browser users do not automatically protect them.

System Updates Available

Several system-level CA trust store updates have been released. Debian's ca-certificates package (DSA-6572-1) removes emSign ECC Root CA - G3 and AAA Certificate Services. Ubuntu released equivalent updates (USN-8944-1 for 22.04 to 26.10 and USN-8944-2 for 14.04 to 20.04). NSS 3.131.1 removes emSign ECC Root CA - G3 from the trusted list. Homebrew ca-certificates and Composer ca-bundle have also been updated. For Linux-based systems — including servers running web applications, containers, and any platform using the system CA bundle — these updates should be applied now.

Incident Two: GoDaddy Mass Certificate Revocation

On October 21, GoDaddy revoked 404,607 SSL/TLS certificates following a compliance incident affecting GoDaddy and Starfield certificate hierarchies. Unlike the eMudhra incident, this is not a key compromise — the issue is a documentation and issuance compliance failure.

The specific problem involves discrepancies between the certificates GoDaddy issued and the certificate profiles documented in its public Certificate Policy and Certification Practice Statement (CP/CPS). Specifically, investigators identified mismatches in CA-specific policy object identifiers (OIDs) and CPS URI policy qualifiers. A third party initially reported the discrepancies. GoDaddy confirmed the issue, suspended certificate issuance, corrected the affected R1 profiles in its published CP/CPS, and resumed issuance. A further review found similar discrepancies in the older Starfield G2 hierarchy, which had already stopped issuing certificates.

The affected population spans domain-validated (DV), organization-validated (OV), and extended-validation (EV) certificates. Starfield R1 DV certificates account for 208,896 of the affected certificates, Starfield G2 DV certificates for another 187,159. The remainder are distributed across GoDaddy and Starfield OV and EV profiles. GoDaddy is reissuing replacement certificates and is tracking the incident under Mozilla's CA Certificate Compliance program as Bug 2082703.

The Operational Problem

Revocation alone does not protect a website's availability. When a certificate is revoked, browsers that check revocation — via CRL or OCSP — will begin showing warnings or blocking access to sites presenting the revoked certificate. GoDaddy is reissuing replacements, but the replacement sitting in a customer account does not protect the site while it continues presenting the revoked certificate to visitors.

GoDaddy warns that visitors may encounter security warnings or lose site access until administrators install the replacement. The operational sequence is: log into the GoDaddy account, navigate to SSL Certificates, review each certificate for alerts including "Action required: Install your new certificate," download the replacement zip or certificate file, and install it on the web server.

Certificates displaying "No action needed" do not require updates. GoDaddy also provides an SSL Status Check tool to verify which certificates are affected.

What This Means for Healthcare

Patient Portals and Health System Websites

Healthcare organizations using GoDaddy or Starfield certificates for patient portals, provider-facing applications, appointment scheduling systems, or public health system websites should treat this as an urgent operational check. A patient portal presenting a revoked GoDaddy certificate is not just a security issue — it is an availability issue that affects patient access to care. If the portal is inaccessible or showing certificate warnings, patients cannot reach it.

The check takes minutes: log into GoDaddy account management and review SSL certificate status. Any certificate showing an action-required alert needs its replacement installed immediately.

eMudhra Exposure in Healthcare Applications

eMudhra's CA hierarchy is not commonly used for US health system websites, but the broader concern is software that bundles its own CA trust stores. Healthcare is full of it — medical devices, point-of-care systems, healthcare middleware, legacy EHR integrations, and embedded clinical systems often ship with their own certificate stores rather than relying on OS-level trust anchors. These systems may not receive the revocation updates that protect browsers.

Any healthcare IT team responsible for medical devices or clinical systems should flag the eMudhra incident for their biomedical and clinical engineering counterparts. The question is not whether any of these systems have eMudhra-issued certificates — it is whether they include eMudhra's CA in their bundled trust stores, and whether they perform TLS validation against any endpoint that might present an eMudhra-chained certificate.

Vendor Risk and Third-Party Exposure

Healthcare organizations may also be exposed through their vendors. A health IT vendor whose web application is inaccessible because of an uninstalled GoDaddy replacement certificate, or whose healthcare-specific software contains an unpatched CA bundle that still trusts the compromised eMudhra intermediates, represents a third-party risk event. Vendor risk assessments and vendor monitoring programs should include certificate health as a standard check, not just a point-in-time evaluation.

The October 27 Window

The eMudhra root removal from Chrome's Root Store happens October 27. Healthcare organizations have five days from this post's publication to identify and replace any eMudhra-chained certificates in their environment and to apply CA bundle updates to Linux-based servers and containers. That window is short but sufficient if the check happens today rather than next week.

Two Separate Root Causes, One Shared Pattern

These incidents have different technical origins — one is a cryptographic failure in key generation, the other is a documentation and compliance failure in certificate issuance. But they share a structural pattern: the public key infrastructure that makes HTTPS trustworthy depends on certificate authorities following rigorous processes for key generation and certificate issuance, and when those processes fail, the remediation falls on every organization that trusted the CA's work.

The PKI trust model concentrates enormous authority in a small number of certificate authorities. When one of those authorities fails — whether through weak key generation, compliance gaps, or active compromise — the blast radius extends to every website, application, and device that trusted it. Healthcare organizations are not responsible for eMudhra's entropy choices or GoDaddy's CP/CPS documentation gaps. They are responsible for knowing which CAs they trust, monitoring for incidents like these, and acting quickly when the trust anchor turns out to be weaker than assumed.