On 22 October 2026, eMudhra Limited announced that its board had voted to withdraw from the global SSL/TLS certificate business. The statement is unusually candid: global TLS was “about 1% of the global revenue”, the compliance burden was rising, and “some of the large entities issue the SSL/TLS free of cost”. Five days earlier, eight of the company’s intermediate CAs had been revoked for key compromise after a researcher demonstrated he could derive their private keys from the public certificates.
The question every operations team should be asking today is narrow and practical: do I have to do anything? We went looking for the answer in the public record, and found that there is no single answer, because there is no single root store. There are four, they are all documented in one free CSV, and they agree with each other about a third of the time.
TL;DR
- The Common CA Database lists 211 root certificate records marked for TLS server authentication. Microsoft includes 191 of them, Mozilla 135, Apple 121 and Google Chrome 100.
- Only 72 of 211 roots (34%) are included by all four programmes. Sixty-six are included by exactly one, and 56 of those are Microsoft-only.
- 100 roots are included by Microsoft and not by Chrome, 36 of them because Chrome explicitly removed them. In the other direction the number is 9.
- eMudhra holds 16 root records. Microsoft includes all 16; Apple and Chrome include 2; Mozilla includes 1.
- We dated every unexpired certificate from eMudhra’s eight public TLS intermediates: 1,435 live certificates across 112 organisations, and the last one expires on 25 January 2027, 95 days from now.
- That tail is short for one reason. 1,417 of the 1,435 (98.7%) are 390-day certificates issued before 15 March 2026, the date the CA/Browser Forum cut maximum validity to 200 days. From March 2027 the cap is 100 days, and from March 2029 it is 47.
Four root programmes, one CSV
The Common CA Database (CCADB) is run jointly by the major root programmes, and it publishes a free, unauthenticated CSV of every root certificate alongside its status in each store. We pulled RootCACertificatesIncludedByRSReportCSV on 22 October 2026, filtered to the records whose intended use includes Server Authentication (OID 1.3.6.1.5.5.7.3.1), and counted.
That filter leaves 211 root records. Here is how the four programmes treat them.
| Root programme | Included | Removed | Not included |
|---|---|---|---|
| Microsoft | 191 | 1 | 13 |
| Mozilla | 135 | 29 | 47 |
| Apple | 121 | 1 | 83 |
| Google Chrome | 100 | 42 | 69 |
Microsoft trusts 91 more TLS roots than Chrome does. That is not a rounding difference, it is nearly double. And the overlap is thinner than the totals suggest:
| Included by | Roots | Share |
|---|---|---|
| All four programmes | 72 | 34.1% |
| Three | 47 | 22.3% |
| Two | 26 | 12.3% |
| Exactly one | 66 | 31.3% |
| None | 0 | 0% |
Fifty-six of the 66 single-store roots are included only by Microsoft. One hundred roots are included by Microsoft and not by Chrome, and in 36 of those cases Chrome has not merely declined to add the root, it has removed it. The reverse set, roots Chrome includes and Microsoft does not, has nine members.
This is the part that matters for anyone running a mixed estate. “Is this certificate trusted?” is not one question with one answer. It is four questions, and in roughly two thirds of cases at least one programme disagrees with the others.
eMudhra is the worked example
eMudhra appears in CCADB as 16 root records, which makes it the fourth-largest root holder in the database by record count, behind DigiCert (38), Sectigo (26) and SSL.com (18). Six of the 16 are marked for TLS server authentication. Their status on the morning of 22 October 2026:
| Root | Apple | Chrome | Microsoft | Mozilla |
|---|---|---|---|---|
emSign Root CA - G1 |
Included | Included | Included | Included |
emSign ECC Root CA - G3 |
Included | Included | Included | Removed |
emSign ECC Root CA - C3 |
Not included | Removed | Included | Removed |
emSign Root CA - C1 |
Not included | Removed | Included | Removed |
emSign Root TLS CA - G1 |
Not included | Not included | Included | Not included |
emSign Root TLS CA - G3 |
Not included | Not included | Included | Not included |
Across all 16 records the count is: Microsoft includes 16, Apple includes 2, Chrome includes 2 and has removed 2, Mozilla includes 1 and has removed 3.
Note which root survives everywhere. emSign Root CA - G1 is the only eMudhra root still included by all four programmes, and it is exactly the one the press release leans on: “Our G1 RSA roots will continue to serve customers until this transition is complete.” The company is winding down against the one anchor every client still honours.
One caveat we want to state plainly, because it would be easy to read this table as a scorecard of incident response. Root programme inclusion is not the same thing as active distrust of a sub-CA. The eight intermediates revoked on 18 October were blocked by Firefox and Chrome on 17 October, Apple on 19 October and Microsoft on 20 October, through disallowed-certificate mechanisms that sit alongside root inclusion rather than inside it. Microsoft responded to the incident. The table above measures something different and slower moving: which roots each programme has decided to carry at all. The divergence in it predates this month and will outlast it.
Counting what gets left behind
A CA exit is not a revocation event. Certificates already issued keep working until they expire, which is why the press release commits to keeping “revocation and certificate status services” running “until every issued certificate has expired or been replaced”. We wanted the date that sentence resolves to.
Certificate Transparency makes this answerable. We enumerated every unexpired certificate logged against eMudhra’s eight public TLS-issuing intermediates via crt.sh, which returned 3,227 entries.
That number is wrong, and the way it is wrong is a trap worth naming. CT logs both a precertificate and the final certificate for most issuances, so a naive count roughly doubles. Collapsing entries that share an issuer, a not-before date, a not-after date and a subject gives 1,435 distinct certificates, of which 1,422 had a precertificate twin. If you ever quote a CT count without deduplicating, you are reporting the logging behaviour of the CA, not the size of its installed base.
| Intermediate | Live certificates |
|---|---|
emSign SSL CA - G1 |
1,376 |
emSign EV SSL CA - G1 |
35 |
emSign EV SSL CA - C1 |
7 |
emSign SSL CA - C1 |
6 |
emSign TLS CA - G3 |
4 |
emSign ECC SSL CA - G3 |
3 |
emSign ECC EV SSL CA - G3 |
2 |
emSign TLS CA - G1 |
2 |
Those 1,435 certificates carry 1,284 distinct common names across 112 subject organisations. The concentration is striking: Infosys Limited holds 198 of them, Etihad Airways 41, Edgeverve Systems 28, eMudhra itself 23, and Kerala State IT Mission 17. This is an enterprise and public-sector portfolio in India and the Gulf, not a long tail of small websites. The newest still-valid certificate was issued on 16 October 2026, the day before the key-compromise report went public.
The answer is 95 days
Here is the expiry curve.
| Expires in | Certificates | Cumulative |
|---|---|---|
| October 2026 (from the 23rd) | 131 | 131 (9.1%) |
| November 2026 | 467 | 598 (41.7%) |
| December 2026 | 501 | 1,099 (76.6%) |
| January 2027 | 336 | 1,435 (100%) |
The median certificate expires on 6 December 2026. The last one expires on 25 January 2027. From the date of the announcement that is a 95-day obligation, after which eMudhra’s commitment to keep OCSP and CRL infrastructure alive has nothing left to answer for.
Ninety-five days is a remarkably soft landing for the exit of a CA with 16 roots in the database. It is worth being precise about why, because the reason is not good luck.
Short-lived certificates are CA-exit insurance
The CA/Browser Forum Baseline Requirements carry a dated schedule of future obligations. Section 6.3.2 reads, effective 15 March 2026: “Maximum validity period of Subscriber Certificates is 200 days.” The same schedule sets 100 days from 15 March 2027 and 47 days from 15 March 2029, with domain validation data reuse tightening from 200 days to 100 and then to 10 on the same dates.
Measure eMudhra’s survivors against that line and the picture is unambiguous:
- Median certificate lifetime: 390 days. Maximum: 390 days.
- 1,417 of 1,435 (98.7%) have a validity period longer than 200 days, meaning they were issued under the old regime.
- Only 18 were issued on or after 15 March 2026. The shortest live certificate runs 89 days.
- The oldest still-valid certificate was issued on 28 September 2025.
Almost the entire surviving population consists of 390-day certificates that are simply far enough through their lives that none of them reaches February 2027. Had this exit happened in 2019, when 825-day certificates were still being issued, the same portfolio would have had a tail measured in years rather than weeks, and the browsers would have faced a choice between a hard distrust date that broke working sites and waiting out the certificates.
The industry debate about shrinking certificate lifetimes is almost always framed as an automation cost imposed on operators. This is the other side of that ledger, and it rarely gets stated. Short-lived certificates convert a CA failure from an ecosystem crisis into a scheduling problem. At 47-day certificates, a CA could collapse entirely on a Monday and the entire installed base would be gone inside seven weeks without a single emergency revocation. The 2026 cut to 200 days is why eMudhra’s exit is a 95-day story instead of a two-year one.
If your renewal process still assumes a human remembers to do something once a year, that assumption has a hard deadline of 15 March 2027, when the cap halves again. Helping teams get to fully automated issuance is a routine part of our DevOps work, and the sites that will find the next three years painless are the ones that stopped treating renewal as an event.
The lights are still on, mostly
We checked whether eMudhra is honouring the part of its statement that matters most to anyone still running one of those 1,435 certificates. The CRL for the revoked G3 TLS root is served at http://crl.emsign.com/?roottlscag3.crl, and on 22 October it returned HTTP 200 and the same 796 bytes recorded on 21 October, with CRL number 17, a last update of 18 October and a next update of 16 April 2027.
It did not return that on every attempt. We fetched the same URL 19 times over half an hour: 12 attempts returned the valid 796-byte CRL, and 7 failed, with connection resets and, once, a 35KB HTTP 403 page from a web application firewall. We are deliberately not calling that an outage. A 403 served to a command-line client from a single vantage point is far more likely to be a bot-filtering rule than a failure of the service, and we cannot distinguish the two from outside. But a roughly one-in-three failure rate is a genuine operational observation about a CRL distribution point, a resource whose entire purpose is to be fetched by automated clients. If you are building revocation checking into your own tooling, budget for retries rather than treating a single non-200 as a verdict.
Which brings this back to the finding we published yesterday in our test of five TLS clients against a revoked CA: the revocation data was published, reachable and free the whole time, and not one of the five clients on a stock Ubuntu box asked for it. eMudhra keeping the CRL alive for 95 more days is a promise kept to an audience that largely is not listening.
What to actually do about this
Nothing here requires panic, but three things are worth an hour of someone’s time this week.
Find out who issued your certificates, in every environment. Not the production website, which someone is watching. The staging environment, the internal API gateway, the vendor-managed appliance, the thing a contractor stood up in 2023. The 112 organisations in that CT data did not choose a CA that was going to exit; they chose a CA, and the exit happened to them.
Work out which root store each of your clients actually uses. The 91-root gap between Microsoft and Chrome is not an abstraction. A Windows service, a Node process carrying its own bundled roots, a container with a distribution trust store and a browser can each reach a different verdict on the same chain. We have seen all four disagree on one connection.
Monitor Certificate Transparency for your own domains. Every number in this post came from public CT logs and a free CSV, for nothing, in an afternoon. The same queries tell you what has been issued for your domains, by whom, and when it expires. It is the cheapest early warning in the whole PKI stack, and in our experience almost nobody has it switched on.
If you want help building that inventory, automating renewal before the 2027 cap lands, or working out what your estate actually trusts, talk to us. Measuring this sort of thing is most of what we do before we recommend anything.
All figures measured on 22 October 2026 from the CCADB root report CSV, crt.sh Certificate Transparency data and the CA/Browser Forum Baseline Requirements effective-date schedule. Certificate counts are deduplicated to remove precertificate twins.
📷 Photo by Keagan Henman on Unsplash
