Why was emSign removed?

This change has far-reaching consequences.

Remove emsign #437 does not offer a justification for removing the issuer.
2026.10.19 #438 attempted to add it back and was closed without explanation.

This is affecting some users at University of Michigan as well, would like to understand if there's an issue with emSign.

This will break quite a bit of Python software in the US Research & Education community.

Internet2's InCommon certificate service uses the emSign root CA, and that service is used by quite a few Research & Education institutions across the US.

(Apologies, replying from my $work github account rather than my OSS maintainer one.)

emSign was removed due to security concerns across all of its intermediates. I should be able to share more details soon, but for the time being this was the path to addressing risk.

You can see that both Chrome and Firefox have performed revocations of emSign certificates, and that emSign themselves published CRLs revoking intermediates.

@gaynor-anthropic

@gaynor-anthropic Can you provide a link/reference to the Chrome/FF actions? I'm not seeing anything jump out other than the 2024 incident?

@nneul

@nneul here's what's public so far:

emSign revoked the eight G3B/G3C intermediates on Oct 18, reason cACompromise - see their CRLs (http://crl.emsign.com/?roottlscag3.crl, http://crl.emsign.com/?rootcscag3.crl) or CCADB's revoked intermediates list: https://ccadb.my.salesforce-sites.com/mozilla/PublicIntermediateCertsRevokedWithPEMCSV
Sectigo revoked the AAA Certificate Services cross-certs for the same CAs on Oct 19, also CA compromise: http://crl.comodoca.com/AAACertificateServices.crl
Firefox: the six TLS ones are in OneCRL (https://firefox.settings.services.mozilla.com/v1/buckets/security-state/collections/onecrl/records, issuer emSign Root TLS CA - G3; also https://crt.sh/mozilla-onecrl)
Chrome: same six are blocked by SPKI in the CRLSet (10845 onward; https://github.com/agl/crlset-tools dumps it)

That sounds like the others are revoking solely the intermediates - not the roots. Is this being done in certifi due to no framework for revocation/block of the intermediates only? Lot of collateral damage if so....

I imagine the hope is that the removal from certifi is a temporary measure until downstream packages can make sure they're validating intermediaries correctly. And then the roots can be added back.

That's correct, there's no facility for revoking an intermediate only. Given the alternate of exposing every user of certifi to MITM attacks, there was no better choice.

Would you consider explicitly adding (the OTHER intermediates) to reduce the blast radius of the "fix"? According to the InCommon list/representive from certinext - only one of the 8 had actually even been deployed, and none of them are affecting the very-heavily-used InCommon/CertiNext intermediates?

It looks like the Rust folks are removing ONLY the affected G3 root, which has massively less impact.

We can likely limit ourselves to only removing emSign Root TLS AC -G3 and emSign ECC Root CA - G3. I'll look at that this evening, although if someone sends a PR that'll save me a bit of time.

#440

Thanks, I'll look this evening.

Restore unaffected emSign roots (certifi#439)

It looks like the background is here; the CA had dual-purpose root certificates (website and email) and as part of complying with the root CA programs they were required to drop trust for one or the other. Mozilla responded by removing the cert (and likely sticking it in OneCRL though I don't see that mentioned in the bug)

Edit to add: It's not exactly a trust issue so much as a compliance issue, the certs are kinda-sorta technically misissued but I would still trust them to prove identity for the moment.

Restore unaffected emSign roots (#439) (#440)

FWIW, 2026.10.19 seems to have fixed our issues.

Sample validation I ran:

uvx --with requests,certifi ipython

import requests, certifi
certifi.__version__  # => '2026.10.19'
r = requests.get("https://.../")
r.status_code   # => 200

Edit: I'd still be interested in seeing this issue remain open until there's public information on the security incident we can link to.

fix(docker): apply security upgrades and distrust emSign ECC G3 (#3)

See https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE/m/0XofdebrAAAJ for additional information. At this point I'm going to close this issue as there's now wide coverage of the incident.

Thanks for bearing with us during this unique incident, and thank you for all the feedback!

Here's the vendor disclosure page: https://emudhra.we-have-a-problem.com/

deps: upgrade certifi for emudhra compromise

[security] Update gRPC repo roots. (#43699)

deps: upgrade certifi for emudhra compromise

Now that #440 brought some of the certificates back, I wonder if there could be an adjustment to the "affected Version" of GHSA-6q48-6c7w-9gw2.
It currently sits at >=2019.03.09 which somehow contradicts the statement "the certificates were created in April 2025" made by https://emudhra.we-have-a-problem.com/

The root has been present in certifi since 2019, the fact that the intermediates weren't issued until 2025 doesn't change the fact that if you have a copy of certifi from 2020, it's got the root and therefore you must upgrade.

Navigation Menu

Repository navigation

Why was emSign removed? #439

3 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Why was emSign removed? #439

Description

Activity

dnowell commented on Oct 19, 2026

jamesharr commented on Oct 19, 2026

gaynor-anthropic commented on Oct 19, 2026

nneul commented on Oct 19, 2026

aaomidi commented on Oct 19, 2026

nneul commented on Oct 19, 2026

rascalking commented on Oct 19, 2026

gaynor-anthropic commented on Oct 19, 2026

nneul commented on Oct 19, 2026

nneul commented on Oct 19, 2026

gaynor-anthropic commented on Oct 19, 2026

nneul commented on Oct 19, 2026

gaynor-anthropic commented on Oct 19, 2026

omnigrok commented on Oct 19, 2026

3 remaining items

jamesharr commented on Oct 20, 2026

gaynor-anthropic commented on Oct 20, 2026

DrDaveD commented on Oct 20, 2026

TTMaZa commented on Oct 21, 2026

alex commented on Oct 21, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions