Security · eMudhra

emSign's wind-down has dates now: 16 November for Chrome and Mozilla, 30 November for Apple

The eight recoverable emSign intermediates are revoked and blocked, which the desk covered in October. What readers still need is the calendar: Chrome 153 and later distrust G1-chained TLS certificates whose earliest SCT falls after 16 November 2026, and Apple removes the root on 30 November, where every G1-issued certificate stops being trusted, including the ones in /etc/ssl/cert.pem that curl, git and python3 read. eMudhra has appointed KPMG as an independent reviewer and says it is issuing Sectigo certificates through the transition.

By BoneWednesday 11 November 20263 min readSecurity

entryread only

filedWednesday 11 November 2026

length3 min

sectionSecurity

subjecteMudhra

sourceson the page

The emSign keys were the emergency. The desk covered that in October, when eight intermediates turned out to be derivable from their own public certificates. What is left is a wind-down, and the wind-down now has dates.

What the CA says changed

eMudhra’s statement of 5 November concedes the finding without hedging: “The flaw was ours.” It says “the private keys associated with eight of our emSign G3 intermediate TLS CAs were recoverable”. “The affected intermediate CAs were revoked within 14 hours of our confirming the issue”, and “Seven of the eight intermediates were never used in production.”

The company has also appointed “KPMG as its independent external reviewer following the incident”. It says it is “offering Sectigo-issued certificates”, with G1 issuance used only to support the transition.

No forged certificate has been shown in use. Chrome’s explanation is the one to keep. It says “no fraudulent certificates issued by these CAs could have been used against CT-enforcing clients”, because none were logged to Certificate Transparency before the block.

The two dates

Chrome’s wording is specific. G1-chained TLS certificates “will no longer be trusted by default in Chrome 153 and higher”. That applies when the earliest Signed Certificate Timestamp is after 16 November 2026, 23:59:59 UTC. An earlier timestamp “will be unaffected by this change”.

Mozilla’s cutoff is the same date per eMudhra and InCommon, since no Mozilla page was read here. InCommon put it operationally: “Google and Mozilla will continue to trust certificates issued before Nov 16 (for their full lifetime), but will not trust certificates issued after Nov 16”.

Apple is the harder one. “Apple will remove and distrust the root on November 30, 2026”, and there the date is not a cutoff. Everything issued under G1 stops being trusted, whenever it was issued.

InCommon, which runs certificates for universities, told members the quiet part: “Our current G1 issuing Certificate Authority (CA) is no longer viable for public trust.” It has been bringing SSL.com into production as a replacement issuer.

Why a server’s own tools break

Apple explains where the trust lives: tools “(including curl, git, python3, ruby, perl, and openssl) check certificates against /etc/ssl/cert.pem”.

From macOS 27.2.1, with 26.7.3 and 15.8.3 for older systems, those tools stop accepting the affected certificates. The roots come out of that file too. If you cannot update, Apple documents removing them by hand, starting with a backup:

[ -e /etc/ssl/cert.pem.orig ] || sudo cp -p /etc/ssl/cert.pem /etc/ssl/cert.pem.orig

Two further commands rewrite the file without the emSign root and the Sectigo cross-sign. Apple’s page carries both. A fourth checks the result:

openssl crl2pkcs7 -nocrl -certfile /etc/ssl/cert.pem | openssl pkcs7 -print_certs -noout | grep -E 'emSign ECC Root CA - G3|AAA Certificate Services'

Apple warns the change is not contained: “These steps affect every tool that uses /etc/ssl/cert.pem”. Tools reading only that file may then fail to verify sites chaining to these roots through untouched intermediates.

Containers and language runtimes with their own trust store sit outside this. Apple says: “Some apps and tools include their own list of root CA certificates and don’t use Apple’s block or /etc/ssl/cert.pem”.

What to do

Inventory what still chains to emSign, starting with anything public-facing, and replace it before the dates. On Linux, the CA bundle update the October piece described is the same work a month later.

If you run macOS servers or CI machines, plan for the command-line change rather than the browser one. Browsers update themselves. A build box calling curl or python3 against an affected host does not.

What this piece does not say

Mozilla’s own announcement was not read. There is no CVE here, and none is implied. The CA’s list of unaffected products, DSC, eSign, emSigner, CertiNext, emCA, PrivaTrust and SecurePass, is its own claim, not an independent finding.

Sources: eMudhra’s statement, Google’s Chrome Root Program post, Apple’s support article, and InCommon’s update, all read on 11 November 2026. The earlier piece on the keys is eMudhra’s CA keys were the number 4.

SecurityeMudhra's CA keys were the number 4, and the company is leaving TLSEight eMudhra intermediate CA private keys were single-byte values recoverable from public certificates, so any trust store that still holds them can be forged against. Distributions have shipped ca-certificates updates, and eMudhra has announced it is withdrawing from the global SSL/TLS business.

SecurityPyPI's new Security tab says where a release came from, and that is not a verdictPyPI's redesigned project pages went live on 6 November with a Security tab that reports a release's provenance: full, none, incomplete, inconsistent, changed or lost. The post is explicit that no provenance does not mean malicious, that it means the file origin cannot be cryptographically verified, and that the states worth checking before you install are the warnings.

SecurityPwnEscape Part 2: from a Firecracker guest to root on the host, in a setup without the jailerThe researchers behind October's kernel bug have published the other half: using that host-memory primitive to find Firecracker in memory, take over a live vCPU thread and redirect its return from KVM to a call of their choosing, with the VM left running and reachable. Their test used Firecracker v1.16.1 with the VMM launched as root and no jailer, and they say a jailer-hardened deployment needs a separate assessment. No new CVE, no vendor advisory and no Firecracker fix appears in the source.