When Intermediate CA Keys Are Compromised - Pushed Blocklists, Compiled-In Denylists, Root Removals, and AWS Trust Bundles

First Published: 2026-10-29
Last Updated: 2026-10-29

When an intermediate CA's private key is compromised, simply revoking that intermediate CA does not protect all clients. Some clients will continue to connect without verifying revocation online, or when online verification is unavailable, because they do not use revocation information. There are three additional mechanisms to protect such clients: distribution of blocklists by browser and operating system vendors, inclusion of denylists in the runtime environment, and removal of root certificates from the trust store. Which mechanism protects a given process is not determined by the process's language, but rather by where it reads its trust store and, for compiled-in denylists, by its runtime version.

This article will examine these four mechanisms, using the eMudhra intermediate CA key compromise, reported on October 17, 2026, as an example. It will detail how browsers, operating systems, Go, Node.js, Python, Java, Linux's ca-certificates, AWS SDK and AWS CLI, AWS Lambda, and AWS services' trust bundles are protected, listing the initial corrected versions and dates, actions users should take, and whether online revocation checking is enabled by default. AWS announcements with target dates will be distinguished from those that have been completed.

This article does not cover the technical details of the key compromise, methods for key recovery, or the handling of test certificates or hosts. It also refrains from evaluating the responses of CAs or vendors, or discussing associated costs. The information presented was verified as of October 29, 2026.

Related articles on this site:

1. Scope and Assumptions
2. How to Read the Tables
3. What Happened and What Was Counted
4. Four Mechanisms That Stopped the Same Keys
5. Client-by-Client Tables
6. The AWS Column
7. Where the Sources Disagree or Are Silent
8. What This Local Setup Showed
9. Failure Modes
10. Frequently Asked Questions About Compromised Intermediate CA Keys
11. Summary
12. References

1. Scope and Assumptions

This section will first define the intended audience, the scope of this article, the source materials consulted, and how to distinguish between different entities that may share the same name. To begin, the following seven points will be outlined.

The private keys of eight intermediate Certificate Authorities (CAs) belonging to eMudhra were compromised. Six of these issued TLS certificates, while two issued code signing certificates. Apple, AWS, Microsoft, and Mozilla (in Bug 2083449) have documented this breakdown in their respective documents. Google's announcement uses both "eight" and "six" on the same page without explaining the difference.
Mozilla has provided guidance for trust store operators in three steps. Clients that verify revocation and reject connections when they cannot check it require no action. Operators with mechanisms to block specific intermediate CAs should implement those blocks. Otherwise, operators should consider removing the root.
Chrome, Firefox, Apple, and Windows have blocked the intermediate CAs with lists that they push. Chrome and Windows block based on the key (SPKI), while Apple blocks 12 certificates. These blocks were implemented without waiting for new browser or operating system versions.
Go and Node.js have incorporated denylists in their new versions. Eight entries in Go versions 1.27.3 and 1.26.10 (released on October 19, 2026) match the SHA-256 hashes of the SPKIs of the eight publicly logged certificates – a calculation verified in this article. Regarding Node.js versions 22.23.4, 24.22.1, and 26.12.1 (released on October 21, 2026), the description in a Node.js pull request states that these denylists pertain to eMudhra's eight intermediate CAs, using the same values as Go. Neither denylist takes effect until programs are rebuilt with the new version or the runtime is replaced.
There are two paths associated with the same key: one descending from eMudhra's root, and another through Sectigo's cross-signatures, which lead to AAA Certificate Services. To effectively block the certificates through root removal, both paths must be severed. Stores derived from Mozilla (NSS, the Node.js bundled store, certifi, and curl's CA bundle) had not included AAA Certificate Services before this incident. However, Apple's /etc/ssl/cert.pem, Windows, JDK's cacerts, and the bundles included with botocore, AWS CLI v2, and the AWS SDK for Ruby previously did.
Python does not read a single trust store. The requests library reads certifi. botocore, if it can import certifi, will use it; otherwise, it will use its own bundled cacert.pem. The python3 included with macOS reads /etc/ssl/cert.pem.
AWS's Security Bulletin states that clients performing fail-closed revocation checks are not affected. AWS has marked STS and Amazon Cognito as complete, and lists target dates for CloudFront, Application Load Balancer, Lambda, and other services. As of the verification date, the target date for Lambda's ZIP managed runtimes (October 31, 2026) has not yet been reached.

1.1 Intended Audience

The intended audience for this article includes developers, platform engineers, and security professionals who operate applications, containers, Lambda functions, and CLIs on AWS. In particular, it assumes readers who hold one of the following five beliefs:

Because the browser has responded, the application must also be secure.
Updating the OS's ca-certificates will ensure security across all runtimes.
Python uses the certifi library.
AWS SDKs rely on the OS's trust store.
If a CA has revoked a certificate, no further action is required.

Each of these five beliefs holds in some cases and not in others, depending on where the process's trust store comes from and how revocation checking is configured. Sections 3 through 6 will, for each source, present relevant excerpts to illustrate this point.

1.2 Scope and Exclusions

This article addresses the dates of the incident, the numbers and their sources, the four mechanisms that stopped the same keys, where each client's trust store comes from, how AWS services and SDKs responded, and the discrepancies and omissions in the documentation.

This article does not cover the following topics, as they are addressed in other articles on this site or in other articles in the same series:

The lineage and methods by which a root program ceased trusting a Certificate Authority (CA), a topic covered in the "Web PKI CA Distrust History and Timeline" article in the same series.
The history of OCSP and CRL policies, and the progression to short-lived certificates, a topic covered in the "TLS Certificate Ecosystem History and Timeline" article.
Support periods for each programming language and Amazon Linux versions, which are detailed in the various timelines available on this site. This article only lists a single line indicating the corrected version.
The specific names that a CA actually validates, a topic covered in the "Which Name the CA Validates" article in the same series.

This article is written with a focus on defense. It does not include technical details regarding key compromise, methods for key recovery, the full fingerprints or SPKI hashes of compromised certificates, or test certificates and the hosts that serve them. Readers requiring more detailed information should refer to the primary sources listed in the "References" section. The impact of the compromise of two intermediate CAs used for code signing is mentioned in a single sentence, providing a numerical breakdown. The responsiveness and quality of responses from CAs and vendors are not discussed.

1.3 The Verification Date and the Sources Read

The information was verified on October 29, 2026. The materials reviewed are as follows:

Incident: Mozilla Bugzilla Bug 2083449, Mozilla Security Blog announcement (October 20, 2026), Mozilla's post on the dev-security-policy forum (visible October 20, 2026), Google announcement (October 20, 2026), eMudhra announcement page (updated October 28, 2026), Microsoft Security Response Center (MSRC) blog and Microsoft Trusted Root Program Announcements.md, Apple support page 149555.
Browsers and Operating Systems: Chromium CRLSets page, Mozilla wiki on Revocation Checking in Firefox.
Runtimes and Libraries: go.dev release history, Go issue #82345, source code for crypto/x509 in Go tags go1.27.3 and go1.26.10, nodejs.org security release announcement for October 2026, along with release notes for each version and CLI documentation, Node.js pull requests #66871 and #66877, PyPI certifi and botocore, requests certs.py, botocore httpsession.py and CHANGELOG, Oracle Security Alerts (2), JDK 27 release notes, Amazon Corretto 21 CHANGELOG, Ubuntu USN-8944-1, curl CA extraction page, Debian security tracking page.
AWS: AWS Security Bulletin 2026-150-AWS (published October 24, 2026 at 20:00 PDT, revised October 28, 2026 at 13:30 PDT), Amazon Linux Security Center (ALAS) pages for CVE-2026-113470, CVE-2026-114406, and CVE-2026-111943, AWS CLI v2 CHANGELOG and configuration page, AWS SDK for Ruby aws-sdk-core CHANGELOG, AWS SDK for JavaScript v3 developer guide, Lambda Node.js page and runtime updates page, GitHub aws/aws-lambda-base-images, AWS re:Post question (1).

This article counted the certificates in the cacert.pem files of the certifi and botocore wheels obtained from PyPI. The SHA-256 hashes of the wheels match the ones published by PyPI. For the comparison with Go's denylist, the eight certificates identified on the Bugzilla and Apple pages, which were found through a public Certificate Transparency search site, were also verified. Their fingerprints matched, and this article calculated the SHA-256 hash of their SPKI. This verification process used only the public keys.

The records from Section 8 were compiled by reading the trust store on a local Mac, specifically for the purpose of this article.

1.4 Words with the Same or Similar Spelling, Different Meanings

This article identifies words that share the same or similar spellings but refer to different concepts.

root store, trust store, CA bundle: This article uses "root store" to refer to a list of root certificates managed by a root program (e.g., Chrome Root Store, NSS lists). It uses "trust store" to describe a collection of certificates used by a process to verify certificate chains. When a trust store is distributed as a single file, it uses the term "CA bundle." Examples of CA bundles include cacert.pem in certifi, cacert.pem in botocore, and /etc/ssl/cert.pem in macOS.
trust bundle: AWS Security Bulletins refer to a collection of certificates used by AWS services to verify TLS connections to destinations specified by customers as "AWS-owned TLS trust bundles." When this article uses the term "trust bundle," it refers to this specific meaning.
distrust: "Web PKI CA Distrust History and Timeline," in the same series, defines "distrust" as removing trust for certificates below a root certificate, while keeping the root itself. Oracle Security Alerts use distrusts in reference to intermediate CA certificates. Go source code uses distrusted in the name of a denylist. This article keeps Oracle's and Go's words as they are, but in its own text it describes Oracle's action as removing trust for an intermediate CA, and Go's action as blocking.
revocation: The act of a CA invalidating certificates it has issued, and the distribution of lists by browsers or operating systems to block those certificates, are distinct actions. Mozilla refers to OneCRL as a list of revoked certificates, but this article uses "blocking" to describe the action performed by OneCRL.
key recovery: The title of an AWS Security Bulletin is as follows. This article uses the term only in direct quotes from the bulletin's title, and uses "compromise" in the main text. Google writes that a key was generated with insufficient randomness, and eMudhra writes cryptographically weak. No instance of the term "key leakage" was found in the referenced materials.

CVE-2026-111943: eMudhra intermediate CA key recovery in AWS trust bundles

2. How to Read the Tables

This section defines the columns in the tables from Sections 3 through 6, as well as how to describe the condition of the materials. The action words and the final two columns are borrowed from the other two articles in the same series. This article adds the distinction between the target date and completion.

2.1 Action Words

This article uses four of the five action words from "Web PKI CA Distrust History and Timeline" in the same series:

revoke: When a CA invalidates a certificate it issued, typically by adding it to a CRL or OCSP.
block: When an operating system or browser vendor prevents the use of specific certificates or keys by including them on a blocklist. This article also uses "block" to refer to the blocking of certificates with a denylist in a runtime's own source code.
distrust: To stop trusting the certificates below a root while keeping the root.
remove: To exclude a root certificate from a root store or CA bundle.

Microsoft, on its MSRC blog, distinguishes removing a root from revocation as follows:

Removing a root from a trust list is not the same as revoking the known impacted intermediate certificate
authorities. This is a separate trust decision, broader than blocking the identified compromised intermediate
keys.

eMudhra also states in its announcement that intermediate keys, not root keys, were revoked.

Intermediate keys were revoked, not root keys.

2.2 Last Two Columns and Four States

The client tables in Sections 5.1 and 5.2 and the table in Section 6.3, like the tables in "Which Name the CA Validates" in the same series, end with two columns: Where It Is Written and No Statement Found. The other tables end with the Where It Is Written column only. The tables of this article's own counts and of the local record (Sections 5.2 and 8.2) have neither column. The Where It Is Written column indicates the source and verification date for the statement in that row. The No Statement Found column describes instances where the statement could not be found after searching the resources mentioned in Section 1.3, along with the scope of the search. A non-empty No Statement Found entry does not necessarily mean the statement is non-existent or will not occur.

The status of the information is described using four terms:

no statement was found: This indicates that the statement was not found after searching, and includes the scope of the search.
the documentation does not list: This means the item is not included in the list or table.
the sources disagree: This indicates that the sources provide conflicting information. Both statements and their sources are listed. This article does not definitively identify either statement as incorrect.
Inference: This refers to what this article reads from the sources. The text states, in the same sentence, that it is this article's reading and not a statement in any source.

2.3 Target Dates and Completed Items

Security advisories may include dates related to ongoing work. AWS Security Bulletins often use terms like by, target date, targeted for, or expected to indicate dates. This article refers to these dates as Target Date, and advisories marked as complete will be designated as Completed. Terms indicating completion include have completed, are available now, and was updated and released. If no primary source stating completion is found by the verification date, even if the target date has passed, the status will remain Target Date.

3. What Happened and What Was Counted

This section lists the dates from the report to the root removal, and the numbers mentioned in the documentation, along with their sources. The rows for each root program's actions are in the 2026 section of "Web PKI CA Distrust History and Timeline" in the same series. This article focuses on listing the dates on which the information reached the clients.

3.1 From the Report to the Root Removal

Google's announcement describes the report as follows:

On Saturday, October 17, 2026, at 18:05 UTC, the Chrome Root Program received a report from a security
researcher regarding the compromise of private keys associated with eight eMudhra subordinate Certification
Authority (CA) certificates. The private keys for these certificates were generated with insufficient
randomness (i.e., weak cryptographic entropy),

The following table details the key events that occurred from October 17, 2026, to the verification date. All times are in UTC. Target dates for each AWS service are summarized in Section 6.5 and are not included in this table.

Date (UTC)	Who	Action	What the Source Says	Where It Is Written
2026-10-17 18:05	Chrome Root Program	—	Received the report	Google announcement (2026-10-20)
2026-10-17 19:45	Chrome	block	CRLSet update blocking the SPKI hashes of the affected intermediate CAs	Google announcement
2026-10-17 20:06	Mozilla	—	Received the report	Mozilla Security Blog (2026-10-20)
2026-10-17 22:59	Firefox	block	OneCRL distribution complete for standard configurations	Mozilla Security Blog
2026-10-18 09:38	eMudhra	revoke	The 8 certificates marked as revoked (`caCompromise`)	Bug 2083449, Comment 1 (Mozilla)
2026-10-18	certifi	remove	Version 2026.10.18 published on PyPI at 16:21; its `cacert.pem` has no emSign root	PyPI; wheel counted by this article
2026-10-19	Sectigo	revoke	Revoked its cross-signed copies	AWS Security Bulletin; Bug 2083449, Comment 13 (Sectigo)
2026-10-19	Apple	block	Began blocking 12 certificates through certificate configuration data	Apple Support 149555
2026-10-19	Go	block	go1.27.3 and go1.26.10 released with fixes to `crypto/x509`	go.dev release history
2026-10-19 (around 22:00)	Android	block	Equivalent update through Google Play Services	Google announcement
2026-10-20	Mozilla	block, remove	Firefox 158.0.1, ESR 115.43.1, and ESR 153.5.1 carry OneCRL; NSS 3.131.1 removes the root	Mozilla Security Blog
2026-10-20	Windows, Microsoft Edge	block	Disallowed Certificate Trust List update; separate CRLSet for Edge and WebView2	MSRC; Microsoft Trusted Root Program `Announcements.md`
2026-10-20	Ubuntu	remove	USN-8944-1 removes `emSign ECC Root CA - G3`	Ubuntu USN-8944-1
2026-10-20	curl CA bundle	remove	Bundle updated by Mozilla at 13:32:40 GMT	curl CA extract page
2026-10-21	Node.js	block, remove	22.23.4, 24.22.1, and 26.12.1	nodejs.org security release
2026-10-21	Oracle Java SE	— (Oracle: `distrusts`)	Security Alert CVE-2026-91403	Oracle Security Alert
2026-10-21	botocore, AWS CLI v2, AWS SDK for Ruby	remove	botocore 1.43.117, AWS CLI v2 2.38.4, and `aws-sdk-core` 3.260.0 drop `AAA Certificate Services` from their bundled files	PyPI; CHANGELOGs
2026-10-21	AWS	remove	Root removal for the shared AWS trust store released to service owners for general deployment beginning on this date	AWS Security Bulletin
2026-10-23	Apple	block	Began blocking `emSign ECC Root CA - G3`	Apple Support 149555
2026-10-24	Oracle Java SE, Amazon Linux	remove	Security Alert CVE-2026-114820; ALAS lists AL2 and AL2023 `ca-certificates` as fixed	Oracle Security Alert; ALAS CVE-2026-113470
2026-10-26	Windows	remove	Out-of-band update removes seven certificates from the Windows trust list	MSRC
2026-10-27	Microsoft Edge	remove	Same seven certificates removed from the Edge trust list	MSRC
2026-10-27 (PDT)	Chrome	remove	Root removal from the Chrome Root Store expected to be released	Google announcement (`expected`)

The date in the final row is the date on which Google's announcement says the removal is expected to be released. By the verification date (Section 7), no primary source was found confirming that the removal of the Chrome Root Store root had been distributed.

Who Stopped the Compromised Intermediates, and When

3.2 What 8, 6, 12, and 7 Count

The sources contain several numbers. Even when referring to the same event, the numbers may represent different things. This article will not use these numbers as isolated, unexplained figures.

Number	What It Counts	Who Says So	Where It Is Written
eight	Private keys of eMudhra subordinate CA certificates	Google, Mozilla, Apple, AWS, Microsoft, eMudhra	Each announcement
six	Intermediate CAs that issue TLS certificates	Apple, AWS, Microsoft, Mozilla (Bug 2083449)	Apple Support 149555; AWS Security Bulletin; Microsoft Trusted Root Program; Bug 2083449
six	`these six intermediate CAs` in the sentence about Certificate Transparency	Google	Google announcement (no explanation of the difference from eight)
two	Intermediate CAs that issue code signing certificates	Apple, AWS, Microsoft, Mozilla (Bug 2083449)	Same as above
12	Certificates that Apple blocks: each of the six TLS intermediate CAs has one certificate issued under `emSign Root TLS CA - G3` and one cross-signed by Sectigo	Apple	Apple Support 149555
seven	Certificates removed from the Windows and Edge trust lists: six eMudhra G3 roots and one `AAA Certificate Services` cross-sign	Microsoft	MSRC
three	Affected roots named by AWS: `AAA Certificate Services`, `emSign Root TLS CA – G3`, `emSign ECC Root CA – G3`	AWS	AWS Security Bulletin
8 entries	SPKI hashes in Go's `distrustedSPKIHashes`; they match the SPKIs of the eight certificates	Go source; the match is this article's calculation	`crypto/x509/verify.go` at tag `go1.27.3`

Apple lists the details as follows:

The private keys of eight intermediate CAs operated by eMudhra were compromised. Two of these CAs issue code
signing certificates, which Apple's frameworks don't trust. The other six issue TLS certificates.

Google's announcement states "eight" in the first paragraph and these six intermediate CAs in the Certificate Transparency section. The same page does not specify what "six" refers to. When compared with the details from Apple, AWS, Microsoft, and Mozilla, "six" can be read as referring to TLS intermediate CAs. This is this article's reading, not a statement from Google.

3.3 One Key, Two Paths: Sectigo's Cross-Signatures

The six intermediate CAs within TLS each have two certificates. One is issued by emSign Root TLS CA - G3 and leads to emSign ECC Root CA - G3. The other is cross-signed by Sectigo and leads to AAA Certificate Services. Both certificates share the same public key. The Microsoft Trusted Root Program describes this as follows:

The affected keys were also used by cross-signed certificates, creating additional certificate paths using the
same compromised key material.

Therefore, how the blocking mechanism is implemented affects how the cross-signed path is treated.

Blocking based on keys (SPKI) groups certificates with the same key together. Google states that CRLSet blocks based on SPKI and that, therefore, users were protected against all certificates sharing those keys. According to Microsoft's documentation, Windows' Disallowed CTL also blocks eight keys using SPKI.
Blocking based on certificates requires listing both certificates. Apple blocked twelve certificates, two from each of the six intermediate CAs.
If blocking is performed by removing root certificates, both root certificates must be removed. After its steps for removing emSign ECC Root CA - G3 from /etc/ssl/cert.pem, Apple writes the following:

Removing emSign ECC Root CA - G3 doesn't block the six certificates that Sectigo cross-signed, because these
tools can still verify them through AAA Certificate Services.

In Bug 2083449, Comment 6, Sectigo states that the root used for cross-signing has already been removed from Chrome and Mozilla's root stores, but remains trusted within Microsoft and Apple's root programs. Sectigo revoked the cross-signed certificates, and AWS's Security Bulletin states that date as October 19, 2026.

3.4 What Was Said About Certificate Transparency

Google's announcement describes Certificate Transparency (CT) as follows:

Because no TLS certificates chaining to these six intermediate CAs were logged to Certificate Transparency (CT)
before our blocking action, no fraudulent certificates issued by these CAs could have been used against
CT-enforcing clients.

This statement indicates that no such certificate was recorded in the CT logs before the block. It does not mention any events that occurred after the block. In Bug 2083449, Comment 44, one of the contributors noted that between October 20 and 21, 2026, 107,107 certificates, signed with 6 out of 8 keys, were recorded in the CT logs. This was a statement made by a contributor, and not a statement from the root program or a Certificate Authority (CA). This article has not verified this number.

No mentions of CT were found in Mozilla's Security Blog or in posts on dev-security-policy.

3.5 Mozilla's Three-Step Guidance

Mozilla, in a post to the dev-security-policy forum, provided the following three-step guidance for operators of trust stores. This article will use these three steps as the core of its classification.

If clients will reliably check revocation information and fail-closed (reject) if it is absent, no action is
needed. The CA has marked these certificates as revoked.

If the operator has a mechanism for blocking trust in particular intermediate CAs, the operator should block
the certificates identified in the attached JSON impacted-intermediates.json and distribute that update to
clients immediately.

Otherwise, the operator should consider whether removing trust in the roots which signed these intermediates
is suitable.

Prior to this guidance, Mozilla states that it cannot advise which course of action is appropriate for each operator. In Comment 5 of Bug 2083449, a Mozilla representative expressed concern about the potential impact on a wider range of users:

many endpoints do not have effective mechanisms for getting revocation information.

Which Mechanism Protects a Given Process

4. Four Mechanisms That Stopped the Same Keys

This section outlines four mechanisms designed to prevent the use of the same key, following the three steps described in Section 3.5. These mechanisms are: fail-closed revocation checking, pushed blocklists, compiled-in denylists, and root removal.

4.1 Fail-Closed Revocation Checking

The CA has revoked eight intermediate CAs. Sectigo also revoked certificates used for cross-signing. This revocation stops clients that refuse connections when they cannot verify the revocation status of a CA certificate within a chain. The AWS Security Bulletin also states:

Please note, customers whose TLS clients enforce certificate revocation checking (OCSP or CRL fail-closed) are
not affected, as the issuing CA revoked the affected intermediates on 2026-10-18, and the cross-signing CA
revoked its copies on 2026-10-19.

However, many clients do not verify revocation status online by default. The documentation states:

The Chromium CRLSets page states the following. Online OCSP checks can be enabled by enterprise policy.

Online (i.e. OCSP and CRL) checks are not generally performed by Chrome.

The source code for Go's crypto/x509 includes the following note in the comments for certificate validation functions:

WARNING: this function doesn't do any revocation checking.

The description for Node.js pull request #66871 states:

Node.js embeds the Mozilla root store but has no equivalent of the
browsers' CRLSet/OneCRL and no default online revocation checking.

Apple writes about the command-line tools that read /etc/ssl/cert.pem on macOS:

For certificates that chain to a root CA certificate in this file, these tools don't check Apple's block or
whether the certificate has been revoked.

The Revocation: From OCSP to CRLs and Short-Lived Certificates section of "TLS Certificate Ecosystem History and Timeline" discusses the history of revocation policies and the widespread use of "soft-fail" mechanisms. This article will not repeat that history.

4.2 Pushed Blocklists

Browser and operating system vendors have blocked specific intermediate CAs using pushed lists, without requiring new releases.

Chrome's CRLSet: The Chromium CRLSets page describes the CRLSet as a primary means for Chrome to quickly block certificates in emergency situations. This CRLSet blocks based on the SPKI hashes of intermediate CAs. Google states that this provides protection without requiring browser updates or restarts.
Firefox's OneCRL: Mozilla states that the OneCRL distribution has reached all Firefox installations with standard settings. For users whose settings do not receive Remote Settings, Firefox 158.0.1, ESR 115.43.1, and ESR 153.5.1 include the list.
Apple's Certificate Configuration Data: Apple states that it automatically delivers the block of the 12 certificates to devices without requiring software updates. Safari, Mail, and applications using Apple's network and security framework use this blocklist.
Windows' Disallowed Certificate Trust List (CTL) and Microsoft Edge's CRLSet: Microsoft is requesting that updated Disallowed CTLs be delivered to Windows devices that do not receive automatic updates.

Check disconnected Windows devices. If you manage Windows devices that don't get automatic updates, make sure
your update process delivers the updated Disallowed Certificate Trust List and the upcoming trust-list changes.

These lists only protect software that reads them. Apple notes that applications and tools with their own root certificate lists will not use Apple's blocklist or /etc/ssl/cert.pem, and advises users to contact developers for assistance.

4.3 Compiled-In Denylists

Go and Node.js have incorporated a SHA-256 denylist for SPKI into their latest versions of the source code.

In Go's issue #82345, the CA name is omitted, and the entry is written as follows:

We're blocking trust in a small set of intermediate certificates due to specific security concerns around their
operation. Verify will now filter out chains which contain these intermediates, preventing them from being
returned to the caller. We highly recommend immediately upgrading to this release. This is CVE-2026-111943

Go's release history indicates that versions go1.27.3 and go1.26.10 (both released on October 19, 2026) include security fixes for crypto/x509. The verify.go file associated with tag go1.27.3 contains a map called distrustedSPKIHashes, which holds 8 SHA-256 hashes. If the SPKI of any certificate in a chain returned by Verify is found within this map, that entire chain is excluded. Similar checks are performed through pathways that use the operating system's verifier on macOS and Windows. These pathways are implemented in the files root_darwin.go and root_windows.go.

Go's announcements and issue descriptions do not mention eMudhra by name. This article calculates the SHA-256 hashes of the SPKI for 8 certificates listed on Bugzilla and Apple's pages, and compares them against the 8 entries in the map. All 8 matched, and they include the two code signing certificates. AWS's Security Bulletin uses CVE-2026-111943 as the identifier for the eMudhra issue.

In Node.js's pull request #66871, the description lists the contents of the denylist as follows:

The initial entries are the eight eMudhra/emSign intermediates whose
private keys were reported compromised in October 2026. The hashes are
byte-identical to Go's fix (CVE-2026-111943) and Electron's patch.

This description reflects the wording used by the contributor who submitted the pull request. Node.js version 22.23.4's release notes describe this change in a single line:

tls: reject chains containing blocked public keys

The compiled-in denylist only takes effect for binaries rebuilt with that list included, or for runtimes that have been updated. Go programs will continue to use the older crypto/x509 library until they are rebuilt with a new toolchain. However, even versions without the denylist can be protected if the root certificate has been removed from the system's trust store (Sections 4.4 and 6.2).

4.4 Root Removal from Bundled and System Stores

The removal of a root certificate affects all software that reads that store. Consequently, certificates that chain to that root and were not compromised will also no longer be trusted. Google explains the reason for removing emSign ECC Root CA - G3 from the Chrome Root Store as follows:

To support other consumers of the Chrome Root Store that do not consume CRLSet updates, we have also removed
emSign ECC Root CA - G3 (the root certificate that signed the compromised CA certificates) from the Chrome Root
Store.

Mozilla also explains the reason for removing a root certificate in NSS version 3.131.1 as follows:

Firefox is already protected through OneCRL, but this additional update helps protect other applications that
use Mozilla's trust store or versions derived from it and do not receive OneCRL updates.

The process for a root certificate removal to take effect varies depending on the origin of the store.

Stores derived from Mozilla's store: The stores bundled with Node.js, certifi, and curl's CA bundle are updated with each new version or new file. The Node.js CLI documentation describes the bundled store as follows:

The bundled CA store, as supplied by Node.js, is a snapshot of Mozilla CA store
that is fixed at release time.

System stores: Ubuntu and Amazon Linux's ca-certificates, Windows' trust list, and Apple's /etc/ssl/cert.pem are updated through the operating system's update process. Processes that read the system store are protected even without changing the runtime environment.
Bundles managed independently by runtimes and libraries: The cacerts in Java Development Kits (JDK), and the bundled files in botocore, AWS CLI v2, and the AWS SDK for Ruby are updated with each new version. Updates to the operating system will not affect these bundled files. This article did not check whether a distribution's JDK package reads the system store instead.

As described in Section 3.3, to effectively block the affected certificates, both emSign ECC Root CA - G3 and AAA Certificate Services must be removed. Since stores originating from Mozilla had not included AAA Certificate Services, removing only emSign ECC Root CA - G3 is sufficient. Stores that previously included AAA Certificate Services will also require its removal.

4.5 The Four Mechanisms Side by Side

Mechanism	Unit	How It Reaches the Client	Covers the Cross-Signed Path	Examples in This Incident	Where It Is Written
Fail-closed revocation checking	Each certificate in the chain	Client fetches CRL or OCSP	Yes, after Sectigo revoked its copies (2026-10-19)	Clients configured to check every CA certificate and reject when status is missing	AWS Security Bulletin; Mozilla dev-security-policy post
Pushed blocklist	Key (SPKI) or certificate	List pushed without a new browser or OS version	Yes for SPKI; certificate lists must name both certificates	Chrome CRLSet, Firefox OneCRL, Apple configuration data, Windows Disallowed CTL, Edge CRLSet	Google; Mozilla; Apple Support 149555; MSRC
Compiled-in denylist	Key (SPKI)	New runtime version; programs rebuilt or runtime replaced	Yes	Go `distrustedSPKIHashes`; Node.js `reject chains containing blocked public keys`	Go source; Node.js release notes and pull request #66871
Root removal	Root certificate	New store file, package, or runtime version	Only if both `emSign ECC Root CA - G3` and `AAA Certificate Services` are absent	NSS 3.131.1, Node.js bundled store, certifi, curl bundle, `ca-certificates`, JDK `cacerts`, Windows and Edge trust lists, AWS trust bundles	Each vendor's notes

5. Client-by-Client Tables

This section lists, for each client, the origin of the trust store, what protects it, the first fixed version and date, what users should do, and whether online revocation checking is enabled by default. The first fixed version is the earliest version confirmed through primary sources in this article. Please refer to the individual timelines on this website for details on the support period.

5.1 Browsers and Operating Systems

Client	Trust Store Source	Protected By	First Fixed Version and Date	What the User Must Do	Online Revocation Check by Default	Where It Is Written	No Statement Found
Chrome	Chrome Root Store	CRLSet (SPKI) from 2026-10-17; root removal expected 2026-10-27 (PDT)	No browser update needed for the CRLSet	Nothing for the block	`Online (i.e. OCSP and CRL) checks are not generally performed by Chrome.`	Google announcement; Chromium CRLSets page	Distribution of the root removal on 2026-10-27
Firefox	NSS	OneCRL from 2026-10-17; NSS 3.131.1 removes the root	158.0.1, ESR 115.43.1, ESR 153.5.1 (2026-10-20) carry OneCRL	Nothing for standard configurations; update if Remote Settings is blocked	—	Mozilla Security Blog	The NSS version that removes the root (the sources disagree; see Section 7)
Safari and apps using Apple's frameworks	Apple trust store and certificate configuration data	Block of 12 certificates from 2026-10-19; `emSign ECC Root CA - G3` from 2026-10-23	No software update needed	Nothing	—	Apple Support 149555	—
macOS command-line tools (curl, git, python3, ruby, perl, openssl)	`/etc/ssl/cert.pem`	Root removal in a future macOS update	Not dated by Apple	Wait for the update, or remove `emSign ECC Root CA - G3` from the file with Apple's steps (Apple notes that a macOS software update can replace the file); Apple marks removing `AAA Certificate Services` as an optional step that also stops the six cross-signed certificates	`these tools don't check Apple's block or whether the certificate has been revoked`	Apple Support 149555	Whether the macOS updates of 2026-10-26 changed the file (no statement in their security notes)
Windows and Microsoft Edge	Windows trust list and Disallowed CTL; Edge CRLSet	Disallowed CTL (SPKI) and Edge CRLSet from 2026-10-20; seven certificates removed on 2026-10-26 (Windows) and 2026-10-27 (Edge)	Automatic CTL updates	Keep automatic updates on; deliver the CTL to disconnected devices	—	MSRC; Microsoft Trusted Root Program `Announcements.md`	—

A — in the Online Revocation Check by Default column means that this article did not search the sources in Section 1.3 for a statement about the product's default revocation checking. Product revocation policies fall outside the scope of this article.

5.2 Language Runtimes and Libraries

Client	Trust Store Source	Protected By	First Fixed Version and Date	What the User Must Do	Online Revocation Check by Default	Where It Is Written	No Statement Found
Go `crypto/x509`	On Linux, the system CA file (`root_linux.go`); on macOS and Windows, the OS verifier	Compiled-in denylist (8 SPKI hashes) plus whatever the system store removes	go1.27.3 and go1.26.10 (2026-10-19)	Rebuild with a fixed toolchain; also update the system store	`WARNING: this function doesn't do any revocation checking.`	go.dev release history; `crypto/x509` source; Go issue #82345	The CA name in Go's own announcement and issue
Node.js	Bundled snapshot of the Mozilla CA store; `--use-openssl-ca` uses OpenSSL's store instead; `--use-system-ca` adds the system store to the bundled store	Compiled-in denylist and bundled root removal (NSS 3.131.1: `emSign ECC Root CA - G3`, `emSign Root CA - C1`, `emSign ECC Root CA - C3`)	22.23.4, 24.22.1, 26.12.1 (2026-10-21)	Update Node.js; updating the OS store does not change the bundled store	`no default online revocation checking` (pull request #66871)	nodejs.org security release; CLI documentation; pull requests #66871 and #66877	—
Python requests	certifi (`from certifi import where`) unless a distributor changes `where()`	certifi root removal	certifi 2026.10.18 (PyPI 2026-10-18)	Update certifi	—	requests `certs.py`; PyPI	—
Python botocore	certifi if importable, otherwise botocore's bundled `cacert.pem`	Bundled root removal (`AAA Certificate Services`) or certifi	botocore 1.43.117 (PyPI 2026-10-21)	Update botocore to 1.43.117 or later; if certifi is installed, update certifi to 2026.10.19 or later	—	botocore `httpsession.py` and CHANGELOG; AWS Security Bulletin	—
Java (Oracle JDK, Amazon Corretto)	JDK `cacerts`	Removal of trust for the intermediate CAs (CVE-2026-91403) and root removal (CVE-2026-114820)	Oracle alerts of 2026-10-21 and 2026-10-24; Corretto 21.0.13.0.11 (2026-10-24)	Update the JDK; custom trust stores are not changed by the update	—	Oracle Security Alerts; JDK 27 release notes; Corretto 21 CHANGELOG	How the removal of trust for the intermediate CAs in CVE-2026-91403 is implemented
Linux `ca-certificates`	Distribution package	Root removal	Ubuntu USN-8944-1 (2026-10-20); Amazon Linux 2 and AL2023 (2026-10-24)	Update the package	—	Ubuntu USN-8944-1; ALAS CVE-2026-113470	Debian, Fedora, and Alpine notices (not searched beyond the Debian tracker)
curl CA bundle (`cacert.pem`)	Extracted from Mozilla's store	Root removal	Bundle updated by Mozilla on 2026-10-20	Fetch the new file	—	curl CA extract page	—

The two Python rows indicate that even in the same Python process, different libraries may read different files. The requests library uses certs.py, which is written as:

This module returns the preferred default CA certificate bundle. There is
only one — the one from the certifi package.

The same file states that, for a Linux distribution, it may be acceptable to modify where() to return a different bundle. The CHANGELOG for botocore version 1.43.117 states:

The vendored bundle is only used when ``certifi`` isn't installed; ``certifi`` users should upgrade to
``certifi>=2026.10.19``.

The results of counting the cacert.pem file in the wheel package are as follows. The name of the certifi version and the publication date on PyPI may not always match.

Package and Version	Published on PyPI (UTC)	Certificates	emSign Roots Present	`AAA Certificate Services`
certifi 2026.7.22	2026-07-22	121	G1, ECC G3, C1, ECC C3	No
certifi 2026.10.18	2026-10-18 16:21	117	None	No
certifi 2026.10.19	2026-10-20 02:24	120	G1, C1, ECC C3	No
certifi 2026.10.23	2026-10-23 11:36	118	G1	No
botocore 1.43.116 (bundled `cacert.pem`)	2026-10-20 19:34	127	None	Yes
botocore 1.43.117 (bundled `cacert.pem`)	2026-10-21 19:29	126	None	No

Version 2026.10.18 of certifi removed all emSign roots. Version 2026.10.19 reintroduced emSign Root CA - G1, emSign Root CA - C1, and emSign ECC Root CA - C3, but still excluded emSign ECC Root CA - G3. Version 2026.10.23 retains only G1. The bundled version of botocore previously did not include any emSign roots, but only contained the AAA Certificate Services cross-signing path.

Regarding Java, Oracle's Security Alert CVE-2026-91403 states:

This Security Alert addresses CVE-2026-91403 by providing Java updates which distrusts the set of impacted
intermediate CA certificates related to eMudhra.

No statement on whether this removal of trust for the intermediate CAs is implemented through java.security settings, cacerts, or other methods could be found in two Oracle Security Alerts, the JDK 27 release notes on jdk.java.net, the Oracle release notes for versions 27.0.1 and 21.0.13, the Java cryptography roadmap, or the Amazon Corretto 21 CHANGELOG. This article will refer to this situation as no statement was found. The ops.java/emudhra URL referenced by Oracle returned an HTTP 403 error on the date of verification. The release notes for JDK version 27.0.1.0.3 state that it removed four aliases from cacerts.

emsigneccrootcag3
emsignrootcag1
emsignrootcag2
comodoaaaca

5.3 Where Each Runtime Reads Its Trust Store

The arrows in the diagram indicate the default locations where each runtime reads its trust store. These locations can be modified through configuration settings and environment variables. According to the Node.js CLI documentation, the --use-openssl-ca flag uses the default OpenSSL trust store instead of the bundled store, while --use-system-ca uses both the bundled store and the operating system's trust store. In the latter case, the root certificates from the original bundled Node.js store remain. The Node.js environment variable NODE_EXTRA_CA_CERTS only adds certificates to the bundled store; it does not remove the root certificates from the bundled store. For the AWS CLI v2, the ca_bundle setting, the AWS_CA_BUNDLE environment variable, and the --ca-bundle option allow you to specify alternative files to read.

5.4 How G1 Is Handled Differs by Party

The handling of emSign Root CA - G1, another root certificate from eMudhra, differs depending on the entity, as of the verification date.

Mozilla, in Comment 18 of Bug 2083449, stated:

At this time we are not removing trust in emSign Root CA - G1.

Google wrote that they are closely investigating whether to continue including eMudhra's remaining CAs in the Chrome Root Store.
Version 27.0.1.0.3 of the JDK removed emsignrootcag1 from cacerts.
Versions 2026.10.23 of certifi and 3.131.1 of NSS, along with the bundled store in Node.js, retain G1.

This article does not state which decisions are correct. Readers who use certificates leading to G1 should verify whether their processes are using a store version that includes G1.

6. The AWS Column

This section lists AWS Security Bulletin 2026-150-AWS and the responses of Amazon Linux, the AWS SDKs and CLI, Lambda, and the trust bundles of AWS services. The bulletin was published on October 24, 2026, at 8:00 PM PDT, and the final revision available as of the time of review was October 28, 2026, at 1:30 PM PDT. Some items in the bulletin have been updated with revised dates.

6.1 What the AWS Security Bulletin Says

The Security Bulletin describes the AWS trust bundle as follows:

AWS-owned TLS trust bundles are certificate stores used by AWS services to validate outbound TLS connections to
customer-configured endpoints, including identity provider endpoints, origin servers, and webhook destinations.

It lists three root certificates that are affected: AAA Certificate Services, emSign Root TLS CA – G3, and emSign ECC Root CA – G3. The statement that clients performing fail-closed revocation checks are not affected is referenced in Section 4.1.

The AWS trust bundle is designed to validate connections made by AWS services to external systems. It does not pertain to clients connecting to AWS service endpoints. The CHANGELOG for the AWS SDK for Ruby's aws-sdk-core also states that AWS service endpoints are not affected (Section 6.3).

6.2 Amazon Linux

The ALAS page for CVE-2026-113470 states information about ca-certificates. Reading only the first part of the page might lead you to believe there is no impact. However, it is necessary to read the entire page.

The ca-certificates package is not itself vulnerable because it contains no compromised certificates, but it
does include the eMudhra root CAs that signed the compromised intermediate certificates. Because those roots are
trust anchors for the intermediates, Amazon Linux will remove the affected eMudhra root certificates from the
package.

As of the verification date, the table on the same page lists ca-certificates as follows:

Platform	Package	Advisory	Status	Release Date	Where It Is Written
Amazon Linux 2	`ca-certificates`	`ALAS2-2026-4037`	Fixed	2026-10-24	ALAS CVE-2026-113470
Amazon Linux 2023	`ca-certificates`	`ALAS2023-2026-3306`	Fixed	2026-10-24	ALAS CVE-2026-113470
Amazon Linux 2027 Preview	`ca-certificates`	—	Pending Fix	—	ALAS CVE-2026-113470

The ALAS entry for CVE-2026-114406 removes the remaining CA certificates associated with the same CA operators. ALAS2-2026-4045 for Amazon Linux 2 and ALAS2027-2026-256 for Amazon Linux 2027 Preview were marked as "Fixed" on October 28, 2026. When this article first checked the page on October 29, 2026, Amazon Linux 2023 was listed as "Pending Fix"; when the page was checked again at 05:13 UTC the same day, ALAS2023-2026-3337 was listed as "Fixed" with the release date October 29, 2026. The Security Bulletin notes that AAA Certificate Services has been removed from the system-wide bundle for Amazon Linux since mid-2025.

Amazon Linux 2 reached its end of support on June 30, 2026. Nevertheless, ALAS has released updates for this vulnerability in Amazon Linux 2 as well. ALAS designates Amazon Linux 2027 as a preview version. Please refer to "Amazon Linux History and Timeline" for details on its support period.

Regarding Go programs, the Security Bulletin and the ALAS page for CVE-2026-111943 state the following:

By default, Go programs on Amazon Linux use the system-wide certificate authority (CA) store. Therefore, the
primary fix for this issue is the ca-certificates update from CVE-2026-113470 that removes the root CA
certificates that signed the affected intermediates.

The same documents describe rebuilding Amazon Linux packages, originally built with Go, using the fixed crypto/x509 library, as a defense-in-depth measure. The original words are as a defense-in-depth measure. The ALAS table for CVE-2026-111943 indicates that, as of the verification date, many packages were marked as "Pending Fix."

6.3 AWS SDKs and the AWS CLI

SDK or Tool	Trust Store Source	Change	Version and Date	Where It Is Written	No Statement Found
AWS SDK for Python (botocore)	certifi if importable, otherwise bundled `cacert.pem`	`AAA Certificate Services` removed from the bundled file	1.43.117 (PyPI 2026-10-21)	AWS Security Bulletin; botocore CHANGELOG and `httpsession.py`	—
AWS CLI v2	Its own copy of botocore (`awscli/botocore/httpsession.py`): certifi if importable, otherwise bundled `cacert.pem`	`AAA Certificate Services` removed from the vendored bundle	2.38.4 (release page 2026-10-21)	AWS CLI v2 CHANGELOG; `httpsession.py` on the `v2` branch	Which file the installer build reads by default (this article's reading: the vendored bundle)
AWS SDK for Ruby	The bundled `ca-bundle.crt` only for applications that opt in with `Aws.use_bundled_cert!`	`AAA Certificate Services` removed from the bundled file	`aws-sdk-core` 3.260.0 (2026-10-21)	`aws-sdk-core` CHANGELOG; issue #3460	—
AWS SDK for JavaScript v3	Node.js default trust stores	—	—	AWS SDK for JavaScript v3 Developer Guide	Any statement about this incident
AWS SDK for Java 2.x	—	—	—	—	Any statement about this incident or the default trust store
AWS SDK for Go v2	Go `crypto/x509` (5.2)	—	—	—	Any statement about this incident

botocore and AWS CLI v2's CHANGELOG entries both state that AAA Certificate Services was removed from the bundled files because Sectigo used this root to cross-sign eMudhra's intermediate CAs. The pyproject.toml file, which lists the dependencies for AWS CLI v2, does not include certifi. Therefore, it is likely that the AWS CLI v2 installed via the installer reads from the bundled file. This is this article's reading, not an AWS statement. The record in Section 8 shows that the directory for certifi was not present in the installation directory for AWS CLI v2 version 2.38.5.

The CHANGELOG for version 3.260.0 of the AWS SDK for Ruby's aws-sdk-core states:

Remove the `AAA Certificate Services` root from the bundled CA file. It cross-signed eMudhra intermediate CAs
whose private keys were compromised. This only affects applications that opt in with `Aws.use_bundled_cert!`
and use it to reach non-AWS endpoints; AWS service endpoints are not affected.

The developer guide for AWS SDK for JavaScript v3 states:

The default trust stores for Node.js include the certificates needed to access AWS services.

It can be stated that this SDK relies on Node.js's default trust store. The Security Bulletin specifically mentions only the AWS SDK for Python. No AWS statement related to this incident was found in the Security Bulletin, AWS documentation searches, or the GitHub repositories for each SDK (AWS SDK for JavaScript v3, AWS SDK for Java 2.x, and AWS SDK for Go v2). This article describes this situation as no statement was found. This article does not claim that this constitutes a lack of impact.

6.4 AWS Lambda

The Security Bulletin states the following regarding Lambda:

AWS Lambda will make patches images available at Amazon ECR Public Gallery by 2026-10-28. Managed runtimes used
by ZIP packages are receiving patches, which will be available in all regions by 2026-10-31.

For users who deploy functions using container images, the bulletin advises rebuilding and redeploying functions from the latest image available on or after October 28, 2026. Functions deployed as ZIP files will be automatically updated by October 31, 2026, according to the bulletin. Lambda's runtime updates page states that automatic runtime updates do not apply to functions set to the Function update or Manual runtime update mode. Previous versions of the Security Bulletin, dated October 24, 2026, indicated dates of October 27, 2026, and October 30, 2026, respectively. The revision of October 28, 2026 moved both dates later.

On GitHub, in the aws/aws-lambda-base-images repository, commits were made on October 28, 2026, between 6:37 AM and 6:47 AM (UTC), across the nodejs22.x, nodejs24.x, python3.12, python3.13, python3.14, java21, java25, ruby3.4, dotnet8, and provided.al2023 branches. The commit messages consist of a single, standard line, such as Update source for nodejs22.x image, and do not specify the changes made. At the time of verification, primary documentation detailing which versions of the ZIP managed runtimes were corrected was not found. The verification date was prior to the target date of October 31, 2026.

The Lambda Node.js page states the following regarding Node.js runtimes version 20 and later:

Starting with Node.js 20, Lambda no longer loads additional CA certificates by default. The Node.js 20 runtime
contains a certificate file with all Amazon CA certificates located at /var/runtime/ca-cert.pem.

This page indicates that specifying /var/runtime/ca-cert.pem for NODE_EXTRA_CA_CERTS will restore functionality equivalent to that of the Node.js 18 and earlier runtimes. NODE_EXTRA_CA_CERTS adds certificates to the Node.js bundled store. Removing root certificates from the bundled store is a feature of newer Node.js versions.

On AWS re:Post, there is a user question reporting that a nodejs24.x function is running on an older version of Node.js, specifically version 24.22.0. This question and its answer are from a user, not from AWS.

6.5 AWS-Side Trust Bundles: Target Dates and Completed Items

The following table lists the dates that the October 28, 2026 edition of the Security Bulletin gives for each AWS service. The Date Type column refers to the distinctions outlined in Section 2.3.

Service	What the Bulletin Says	Date in the Bulletin	Date Type	What the Customer Does	Where It Is Written
Shared AWS trust store	Root removal released to Amazon service owners for general deployment	Beginning on 2026-10-21	`Completed` (release to service owners)	—	AWS Security Bulletin
AWS STS, Amazon Cognito	Have completed deploying trust store updates	—	`Completed`	—	AWS Security Bulletin
Amazon CloudFront	Deploying root removal from the edge CA bundle	2026-10-28	`Target Date`	Origins whose certificates chain to an affected root may fail validation; notified through the Personal Health Dashboard	AWS Security Bulletin
Application Load Balancer (OIDC and JWT authentication)	Removing the affected roots from the trust store for identity provider endpoints	2026-10-29 to 2026-10-31; new load balancers by 2026-11-02	`Target Date`	Replace an identity provider certificate that chains to an affected root (the bulletin gives 2026-10-28)	AWS Security Bulletin
Amazon RDS for SQL Server	Updating managed hosts	2026-10-30	`Target Date`	No action required, per the bulletin	AWS Security Bulletin
Amazon EMR	Releasing updated versions	2026-10-31	`Target Date`	Update when available	AWS Security Bulletin
AWS Lambda	Base images in Amazon ECR Public; ZIP managed runtimes	2026-10-28; 2026-10-31	`Target Date`	Rebuild container images; ZIP functions in the Auto runtime update mode are updated automatically	AWS Security Bulletin
AWS Amplify	Updating applications on Node 22 and Node 24	2026-10-31	`Target Date`	—	AWS Security Bulletin
Bottlerocket	Updated AMIs; AMI parameters	2026-10-26; 2026-10-28	`Target Date`	Interim per-node trust override through the API for AMI versions at or below v1.67.0, per the bulletin	AWS Security Bulletin
Amazon Linux 2 and AL2023	`ca-certificates` updates	Available now	`Completed`	Update `ca-certificates` (for AL2023, the bulletin gives `sudo dnf update ca-certificates --releasever=latest`)	AWS Security Bulletin; ALAS
Amazon Corretto	Updated JDK versions across all supported lines	—	`Completed`	Upgrade	AWS Security Bulletin
Amazon EC2 Windows Server	Depends on Microsoft's trust list updates	—	—	Verify that instances with restricted internet access, disabled automatic certificate updates, or customized stores received the updates	AWS Security Bulletin

The Security Bulletin does not give a time zone for its target dates. As of the verification date (October 29, 2026), the Security Bulletin does not indicate that CloudFront (target date: October 28, 2026) is complete. This article will maintain the "Target Date" designation. The same applies to the row for Bottlerocket and to the target date for the Lambda container images (October 28, 2026).

7. Where the Sources Disagree or Are Silent

This section will identify discrepancies between the documents and areas that were not documented as of the verification date.

Topic	What the Sources Say	Status	Where It Is Written
eight and six	Google's announcement uses both numbers on the same page without explaining the difference; Apple, AWS, Microsoft, and Mozilla give six TLS and two code signing CAs	Google's page does not explain; others do	Google; Apple Support 149555; AWS Security Bulletin; Microsoft; Bug 2083449
Chrome root removal	Google wrote that the removal is `expected` to be released on 2026-10-27 (PDT)	`no statement was found` about the actual release	Google announcement
NSS version that removes `emSign ECC Root CA - G3`	Mozilla's blog names NSS 3.131.1; other Mozilla sources name a later version	`the sources disagree` (details in Web PKI CA Distrust History and Timeline)	Mozilla Security Blog; NSS release notes; CCADB
`emSign Root CA - G1`	Mozilla keeps it `At this time`; Google is `closely investigating`; JDK 27 removed it; certifi 2026.10.23 and Node.js keep it	Each party decides differently (Section 5.4)	Bug 2083449; Google; JDK 27 release notes; PyPI
Java: trust removed for the intermediates	Oracle wrote `distrusts` for the intermediates	`no statement was found` about the mechanism	Oracle Security Alert CVE-2026-91403
macOS `/etc/ssl/cert.pem`	Apple wrote the file will be updated in a future macOS update	`no statement was found` that an update has done so	Apple Support 149555; security notes of 2026-10-26
AWS CLI v2 default bundle	The code reads certifi if importable; the dependency list has no certifi; the 2.38.5 installer on the Mac in Section 8 had no `certifi` directory	This article's reading: the vendored bundle	AWS CLI v2 `v2` branch; Section 8
AWS SDK for JavaScript v3, Java 2.x, Go v2	No AWS statement about the incident	`no statement was found`	Section 6.3
Lambda ZIP runtime versions	Target date 2026-10-31	`no statement was found` about fixed versions	AWS Security Bulletin
Certificate Transparency after the block	Google's statement is limited to `before our blocking action`; a bug participant reported certificates logged after the block	Third-party report, not verified by this article	Google; Bug 2083449, Comment 44

Bug 2083449 continues to receive participant posts from the day before the verification date through the verification date itself. This article will simply list the facts, based solely on what is written in the root program, CA, and vendor documentation. With the exception of a single sentence in Section 3.4, participant posts will not be included.

8. What This Local Setup Showed

This section documents the trust stores that the runtimes on a local Mac read, specifically for the purposes of this article. It is a record of this configuration on that day, not a statement of any source. The system was not connected to a network, and certificate chain validation was not tested.

8.1 Setup and How to Read the Record

On October 29, 2026, at 01:03 UTC, a read-only script was executed on a Mac running macOS 27.2. The script examined Python, Node.js, Go, and Java environments, as well as macOS's /etc/ssl/cert.pem file, the bundle shipped in the AWS CLI v2 installer, and the system's root keychain, and checked whether six root names were present. The Python environment utilized a virtual environment with boto3 and botocore installed. Home directories were represented as ~ in the paths.

The table entries ECC_G3 refer to the presence of emSign ECC Root CA - G3, AAA indicates the presence of AAA Certificate Services, and G1 indicates the presence of emSign Root CA - G1. emSign Root TLS CA - G3 was not found in any of the stores.

8.2 What Was Read

Component	Version	Store Read	Certificates	`ECC_G3`	`AAA`	`G1`	Note
Python certifi	Python 3.14.10, certifi `2026.01.04`	`certifi.where()` in the virtual environment	136	Yes	No	Yes	—
Python botocore	botocore 1.43.120	`botocore.httpsession.where()` resolved to the certifi file above	136	Yes	No	Yes	botocore's own bundled `cacert.pem` (126 certificates, none of the six roots) was not used
Python `ssl` default	Python 3.14.10	`/opt/homebrew/etc/openssl@4/cert.pem`	188	No	No	Yes	Read by code that uses Python's default `ssl` context, not by requests or botocore
Node.js bundled store	v26.13.0	`tls.rootCertificates`	118	No	No	Yes	—
Node.js system store	v26.13.0	`tls.getCACertificates('system')` with `--use-system-ca`	0	—	—	—	Returned no certificates on this Mac
Go toolchain	go1.27.3	`crypto/x509/verify.go` in the toolchain	—	—	—	—	`distrustedSPKIHashes` present with 8 entries
Java	OpenJDK 25.0.2 (2026-01-20)	JDK `cacerts`	158	—	—	—	All four aliases present: `emsigneccrootcag3`, `emsignrootcag1`, `emsignrootcag2`, `comodoaaaca`
macOS command-line tools	macOS 27.2	`/etc/ssl/cert.pem`	128	Yes	Yes	Yes	—
AWS CLI v2	2.38.5	`/usr/local/aws-cli/awscli/botocore/cacert.pem`	126	No	No	No	No `certifi` directory was found under the installer directory
macOS system roots	macOS 27.2	`SystemRootCertificates.keychain`	151	Yes	Yes	Yes	Apple's block is configuration data; the roots remain in this keychain

Here are five key findings from this analysis:

While botocore was a newer version (1.43.120) compared to 1.43.117, it was able to import certifi and was therefore reading certifi files. This certifi version was 2026.1.4 (released on January 4, 2026) and included emSign ECC Root CA - G3. Even if botocore is updated, without updating certifi, this environment will continue to trust G3. The botocore CHANGELOG recommends updating certifi to version 2026.10.19 or later (as detailed in Section 5.2).

macOS 27.2's /etc/ssl/cert.pem file contained both emSign ECC Root CA - G3 and AAA Certificate Services. Apple's documentation states that this file will be corrected in future macOS updates, but it does not specify which versions will include the fix.

Java, using OpenJDK version 25.0.2, still contained all four aliases in the cacerts file. This is an earlier version than the Java 25 versions that Oracle's two Security Alerts list as affected (25.0.5 and 25.0.5.0.2).

Node.js version v26.13.0's bundled store did not include emSign ECC Root CA - G3, but did include G1. This is consistent with the contents of NSS version 3.131.1. When using --use-system-ca, no system certificates were read. Node.js's CLI documentation states that on macOS, this option reads certificates set to Always Trust in the default and system keychains.

The installer for AWS CLI v2 version 2.38.5 included awscli/botocore/cacert.pem but did not contain a certifi directory. The SHA-256 hash of this bundled file matched the bundled file included with the locally installed botocore version 1.43.120. This finding aligns with the analysis in Section 6.3, which identified the AWS CLI v2 installer as reading a bundled file.

8.3 What This Setup Does Not Show

This record does not demonstrate:

Whether the compromised intermediate CA certificate is actually rejected on each runtime of this Mac. This article does not attempt to test connections to or validation of the compromised chain.
The behavior of Safari and of applications that use Apple's frameworks. Apple's blocking is provided as configuration data and does not remove the root from the system's root keychain.
The contents of Python, Node.js, or Java on a different Mac, with a different distribution, or on a different day.

This record does not create any AWS resources.

9. Failure Modes

This section outlines what happens when you misunderstand the origins and workings of a trust store.

9.1 Assuming the Application Is Safe Because the Browser Has Responded

The browser is protected by reading CRLSet and OneCRL. Programs running on the same device, such as Go, Node.js, Python, and Java, as well as macOS's curl, do not read these lists. Apple states that tools reading /etc/ssl/cert.pem do not verify Apple's blocklist.

9.2 Assuming That Updating the OS `ca-certificates` Covers Every Runtime

This update applies to processes that read the operating system's store. However, it does not apply to processes that read the bundled stores included with Node.js, certifi, botocore, the JDK's cacerts, or the AWS SDK for Ruby's ca-bundle.crt. The Node.js CLI documentation describes the bundled stores as fixed snapshots as of the release.

9.3 Treating Python as One Thing That Uses certifi

The requests library reads from certifi. botocore, on the other hand, only reads from certifi if it can be imported; otherwise, it reads from its own bundled certificates. The python3 version included with macOS reads from /etc/ssl/cert.pem. Depending on the distribution, where() might return a different bundle. Even in the same Python process, it may be necessary to verify for each library individually.

9.4 Assuming Nothing Is Needed Because the CA Revoked the Certificates

Only clients that check the revocation of the CA certificates in the chain, and that reject the connection when they cannot check it, need no action. Chrome, Go, and Node.js do not verify revocation status online by default (see Section 4.1).

9.5 Generalizing That Programs Built with Go Before 1.26.10 or 1.27.3 Are Not Protected

Even in versions without a denylist, if the root is removed from the system store that processes read, those processes will be protected by the root removal. AWS notes that for Go programs on Amazon Linux, the primary fix involves updating ca-certificates (see Section 6.2). Conversely, even if rebuilt with newer versions of Go, without updating the system store, these programs will not be protected beyond the eight items on the denylist.

9.6 Assuming That Removing Only `emSign ECC Root CA - G3` Is Enough

Stores that possess AAA Certificate Services retain a chain of cross-signatures (see Section 3.3). Apple's /etc/ssl/cert.pem and the bundled files previously included with botocore, AWS CLI v2, and the AWS SDK for Ruby all contained this root certificate.

9.7 Reading the Dates in the AWS Bulletin as Completed

Many of the dates listed in the Security Bulletin represent target dates. Unless a "completion" status is indicated, this article will not state that a particular item is complete (see Section 6.5). The dates for Lambda moved later in the revision of October 28, 2026.

9.8 Citing 8 as a Standalone Number Without Its Source

The number 8 is the number of keys. There are six intermediate Certificate Authorities (CAs) in TLS, Apple blocked 12 certificates, and Microsoft removed 7 certificates (see Section 3.2).

10. Frequently Asked Questions About Compromised Intermediate CA Keys

Q1. If the browser has blocked the certificates, does the application still need to do anything?

It depends on the trust store that the application reads. Applications that do not read the browser's blocklist may require updates to their runtime or libraries, or an update of the operating system's store. Please check the row corresponding to your application's runtime in the tables in Section 5.

Q2. Is updating the OS `ca-certificates` enough?

This will address issues related to reading certificate stores in the OS. For example, this applies to Go programs on Linux, as well as Node.js configured with --use-openssl-ca. Node.js configured with --use-system-ca will add the OS's certificate store to the bundled store, so the bundled store's root certificates will remain. This will not resolve issues with reading certificate stores in the Node.js bundled store, certifi, botocore's bundled file, or the cacerts in the JDK.

Q3. To which versions should boto3 and botocore be upgraded?

The AWS Security Bulletin recommends updating botocore to version 1.43.117 or later. In environments that include the certifi package, botocore reads from certifi. The botocore CHANGELOG specifies that in such cases, certifi should be updated to version 2026.10.19 or later.

Q4. Are Lambda functions fixed automatically?

The Security Bulletin states that the managed runtime for functions distributed via ZIP will automatically update by October 31, 2026. Lambda's runtime updates page states that automatic runtime updates do not apply to functions set to the Function update or Manual runtime update mode. Functions distributed within container images will need to be rebuilt and redeployed using the latest image available on or after October 28, 2026. At the time of verification, no primary documentation was found detailing the updated managed runtime for ZIP distributions.

Q5. Do Go programs need to be rebuilt?

To ensure the denylist is effective, you need to rebuild the program using Go version 1.27.3 or later, or Go version 1.26.10 or later. On Linux, since Go reads the system's CA files, updating ca-certificates can also achieve the effect of removing root certificates. AWS states that for Go programs on Amazon Linux, updating ca-certificates is the primary recommended fix.

Q6. If a client is set to check revocation, is nothing else needed?

Mozilla's documentation and the AWS Security Bulletin state that clients that verify revocation and reject connections when revocation cannot be confirmed do not require further action. In this instance, the certificates that were revoked are intermediate CA certificates. Therefore, the appropriate configuration is one that verifies the revocation status of intermediate CA certificates in the chain and rejects connections when revocation information is unavailable. This explanation is this article's reading, not a statement from Mozilla or AWS. Please refer to the documentation for the specific client you are using to confirm whether its configuration meets this requirement.

11. Summary

Four mechanisms stopped the same eight keys: fail-closed revocation checking, pushed blocklists, compiled-in denylists, and root removal. Which mechanism protects a process is determined not by the process's language, but by the origin of the trust store the process reads and, for compiled-in denylists, by its runtime version.
Mozilla's three-step guide can be read as a process for selecting these four mechanisms in sequence (this article's reading). If the revocation of the CA certificates in the chain is checked fail-closed, no action is needed. If an intermediate CA can be blocked, it should be blocked. If neither is possible, consider root removal.
Mechanisms that block by key also stop the cross-signed path. If using root removal, both emSign ECC Root CA - G3 and AAA Certificate Services must be removed.
Python, Node.js, Java, and AWS SDKs may have their own trust stores, separate from the operating system. Relying solely on OS updates may not be sufficient.
Many dates listed in the AWS Security Bulletin represent target dates. STS, Cognito, Amazon Linux 2 and AL2023's ca-certificates, Corretto, and botocore are marked as "complete." CloudFront, Application Load Balancer, Lambda, and others remain at their target dates as of the verification date.
The numbers provided are as follows: 8 is the number of keys, 6 is the number of intermediate CAs for TLS, 12 is the number of certificates blocked by Apple, and 7 is the number of certificates removed by Microsoft.

All information is current as of October 29, 2026.

12. References

Mozilla: Bug 2083449 - eMudhra: Private key compromise of Intermediate Certificates (Bugzilla)
Mozilla Security Blog: Protecting Firefox users following the compromise of eMudhra intermediate certificates
Mozilla dev-security-policy: Compromised eMudhra Intermediate Certificates
Mozilla Wiki: CA/Revocation Checking in Firefox
Google: Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates
The Chromium Projects: CRLSets
Apple Support: About the compromised eMudhra intermediate CAs
Microsoft Security Response Center: Microsoft's response to compromised eMudhra certificate authority keys
Microsoft Trusted Root Program: Announcements
eMudhra: eMudhra Statement on Recent Certificate Security Incident
Go: Release History
Go: crypto/x509: mitigation for security concerns with a specific Certificate Authority (issue #82345)
Go: src/crypto/x509/verify.go at go1.27.3
Node.js: Wednesday, October 21, 2026 Security Releases
Node.js: Node.js v22.23.4 release notes
Node.js: Command-line API
Node.js: tls: reject chains containing blocked public keys (pull request #66871)
Node.js: crypto: update root certificates to NSS 3.131.1 (pull request #66877)
PyPI: certifi
Requests: src/requests/certs.py
PyPI: botocore
botocore: botocore/httpsession.py
botocore: CHANGELOG
Oracle: Oracle Security Alert Advisory - CVE-2026-91403
Oracle: Oracle Security Alert Advisory - CVE-2026-114820
OpenJDK: JDK 27 Release Notes
Amazon Corretto: Change Log for Amazon Corretto 21
Ubuntu: USN-8944-1: ca-certificates update
curl: Extract CA Certs from Mozilla
Debian: Security Tracker - CVE-2026-111943
AWS: CVE-2026-111943: eMudhra intermediate CA key recovery in AWS trust bundles (AWS Security Bulletin 2026-150-AWS)
AWS: Amazon Linux 2 FAQs
Amazon Linux Security Center: CVE-2026-113470
Amazon Linux Security Center: CVE-2026-114406
Amazon Linux Security Center: CVE-2026-111943
AWS CLI: AWS CLI v2 CHANGELOG
AWS Command Line Interface User Guide: Configuration and credential file settings in the AWS CLI
AWS SDK for Ruby: aws-sdk-core CHANGELOG
AWS SDK for JavaScript v3 Developer Guide: Register certificate bundles in Node.js
AWS Lambda Developer Guide: Building Lambda Event Functions with Node.js
AWS Lambda Developer Guide: Understanding how Lambda manages runtime version updates
GitHub: aws/aws-lambda-base-images
AWS re:Post: Lambda patching for compromised eMudhra intermediate CA certificates?

References:
Tech Blog with curated related content

Written by Hidekazu Konishi