Abstract
Three weeks ago, eMudhra’s ECC root was distrusted. InCommon told its universities to handle it by “reissue[ing] affected certificates as RSA until ECC issuance is restored to avoid disruption.” Most schools followed that advice. Of the replacements we watched that week, 97% went to eMudhra’s RSA root, emSign Root CA - G1.
On Monday, November 16, Microsoft distrusts the RSA root, and every certificate under it stops working on Windows and in Edge. eMudhra says Apple will also remove it on November 30.
InCommon’s November 10 update says its G1 issuing CA “is no longer viable for public trust.” So the schools that did what they were told get to replace every certificate again. That’s their third CA switch this year, and many are not happy.
Who is dropping emSign Root CA - G1, and when
| Where | When | Certificates you already have |
|---|---|---|
| Microsoft Windows, Edge, and Azure | November 16 | Stop working |
| Chrome | Certificates logged after November 16, 23:59 UTC | Keep working until they expire |
| Firefox | Certificates issued after November 16, 23:59 UTC | Keep working until they expire |
| Safari and Apple apps | November 30, according to eMudhra | Stop working |
Microsoft goes first. A November 11 update to Microsoft’s response to the eMudhra key compromise says it is “removing the remaining eMudhra root certificates across its products and services,” starting November 16. That day it takes the remaining 10 eMudhra roots out of the Windows trusted root list. The post doesn’t list them, but Edge’s release notes name G1.
They say a November 16 update “will fully remove default trust for the remaining roots.” It ships as a component update that Edge checks for every 10 hours and after each launch, so nobody has to install a new browser version to get it. Azure Linux drops the roots the same day.
Apple hasn’t announced anything about G1 directly, but eMudhra’s incident page says “all certificates issued under the G1 hierarchy at any point in time will cease to be trusted on their platforms.” Apple has already moved on the command line. Apple’s support note says macOS 27.2.1, 26.7.3, and 15.8.3 remove G1 from /etc/ssl/cert.pem.
Chrome and Firefox are less strict. Chrome will stop trusting G1 certificates “whose earliest Signed Certificate Timestamp (SCT) is dated after November 16, 2026 11:59:59 PM UTC,” and Mozilla set the same cutoff for Firefox. Certificates from before the cutoff keep working until they expire.
It doesn’t really matter, though. No one wants a certificate that only works in some browsers. All these certificates need to be replaced before Monday. That sounds familiar.
eMudhra said G1 was fine
Back on October 22, eMudhra’s incident page said “Our G1 root certificates remain active and continue to be fully supported.” InCommon’s FAQ told schools their reissued certificates will “remain trusted until they expire” and that “no further action is currently required.” It still says that.
That held for nineteen days.
I told schools not to stay on the RSA root back then, because I expected it to be distrusted too. Why would the browsers keep trusting the company that let “4” be an intermediate’s private key?
eMudhra’s record was there to read. It had 33 incidents on file as of November 7 but only found 4 of them itself.
Most G1 certificates haven’t been replaced
On November 12, we looked up 59 large universities in our CT log search. Counting each set of names once, they have 36,824 certificates on G1. 21,462 of them, 58%, haven’t been replaced by a certificate from another CA yet. They have until Monday to get it done.
| Domain | G1 certificates with no replacement, November 12 |
|---|---|
| umich.edu | 1,971 |
| umn.edu | 1,968 |
| ucsd.edu | 1,344 |
| uw.edu and washington.edu | 1,341 |
| pitt.edu | 1,035 |
InCommon’s suggested fix is SSL.com, and schools are using it. SSL.com issued 1,221 certificates for these schools on November 10, 5,230 on November 11, and 7,410 by 2 p.m. Central on November 12. That covers 35% of what was on G1. Another 7% went to Let’s Encrypt, Google, or another CA.
What to do before Monday
Search your domain in our CT log search and look at the certificates issued by Internet2. If the issuer is InCommon Intermediate CA - OVG2C, DVG2C, or EVG2C, or InCommon RSA IGTF Server CA 4, it’s on G1.
You can’t wait for renewal. ACME clients renew when a certificate is close to expiring, and these don’t expire until spring. You have to force a new one from a different CA. We wrote up how to move an InCommon certificate to another CA last month, and the steps haven’t changed.
Any CA still in the root stores works. Let’s Encrypt and Google Trust Services are free, and have some of the best incident records of any CA. If you have CAA records, add the new CA first.
Do the hosts Windows users reach first. Then check each one in the certificate chain checker, including the load balancers and appliances that hold their own copy.
Three CAs in one year
InCommon schools started 2026 on Sectigo, moved to eMudhra by July, and are moving to SSL.com now. Most of the school IT people I met at TechEX in October renew by hand. For them, every move is a ticket and a login for every certificate.
In CertKit, the CA is a setting. When we ran a CA distrust wargame, moving every certificate in one of our products to a new CA and deploying it to 18 targets took 10 minutes. For 99.4% of domains, the new CA issues every replacement in under a minute.
If you’re replacing G1 certificates this week, contact us. We’ll help you get through Monday, and make the next CA change a setting.
CertKit automates certificate lifecycle management so your next CA change is a setting.