Google’s 4 November update sets a timestamp cutoff for newly issued certificates under an eMudhra root. Enterprise responses show why browser fixes and application trust stores need separate attention.
Google has added a further certificate-trust restriction following the eMudhra intermediate certificate authority incident. In a 4 November update, the company said Chrome 153 and higher will cease trusting TLS server certificates validating to emSign Root CA – G1 when their earliest Signed Certificate Timestamp is after 16 November 2026 at 23:59:59 UTC.
Certificates whose earliest timestamp is on or before that cutoff are unaffected by this particular change, Google said. The distinction matters: the notice describes a specific root, timestamp condition and browser version, rather than the immediate rejection of every certificate issued by eMudhra.
A new trust decision after emergency blocking
The new deadline follows the October discovery of weak private keys associated with eight intermediate CA certificates. Google’s original response included emergency blocking of the affected keys and a separate decision to remove emSign ECC Root CA – G3. It also reported that no TLS certificates from the six affected TLS intermediates had appeared in Certificate Transparency logs before its blocking action.
Those are related but separate protections. Blocking an identified compromised key addresses a known route to fraudulent trust. Removing a root changes the broader set of chains a platform accepts. An issuance cutoff introduces another boundary, allowing administrators to distinguish existing certificates from newer ones that fall under the announced restriction.
For website operators, the practical question is which chain their services actually present. A company name on an invoice is insufficient to establish that. Administrators need the certificate hierarchy, issuance information and the behaviour of the clients using the service. That assessment also needs to include renewal arrangements, because a replacement certificate can encounter a different trust rule from the one currently deployed.
Windows and browsers follow distinct update paths
Microsoft’s response describes several layers of remediation. It published a Windows disallowed-certificate update on 20 October, deployed separate component-based protections for Edge and WebView2, and subsequently removed seven certificates associated with the affected hierarchies from the Windows and Edge trust lists.
Microsoft emphasises that removing roots is a broader decision than revoking the identified intermediates. It also warns that locally restoring trust can leave exposure where software does not reliably check revocation or the disallowed list. Its customer guidance includes keeping certificate updates flowing, checking disconnected devices and replacing certificates that depend on removed chains.
The wider lesson is that updating the browser on one laptop does not demonstrate that every application in an organisation now uses the same trust information. Operating systems, browsers and packaged applications may obtain that information through different mechanisms. A complete remediation record needs to identify the responsible component and the update that reached it.
The issuer’s account remains an attributed account
In its public incident statement, eMudhra says it revoked all eight intermediates the following day after being notified on 17 October. The company says the intermediates had not issued certificates, its infrastructure and customer data were not compromised, and it is unaware of exploitation before disclosure.
The issuer attributes the weak published keys to a flaw in a step of its key-generation ceremony, despite the use of certified hardware security modules. It says its exact root-cause investigation is continuing. These are the company’s findings and explanations; they should not be read as an independent determination that every possible downstream consequence has been excluded.
Enterprise remediation reaches beyond public websites
An interim advisory issued by Druva on 4 November illustrates the application-level work. Druva says its own presented certificates are unaffected and it is not aware of malicious use affecting its customers. Its concern is inbound trust in certain customer-deployed components connecting to its cloud services.
The company separates components needing operating-system certificate updates from those receiving updated releases or requiring additional action. It also distinguishes automatically updated Windows systems from offline or policy-restricted environments. The advice is product-specific, but demonstrates why a general assurance that a vendor has responded cannot replace checking the deployed components.
For security teams, the defensible completion test is therefore concrete: establish which certificates and trust stores are in use, confirm the applicable vendor changes, and test that services remain accessible through supported chains. The November cutoff adds a date to that work. It also reinforces a longstanding operational requirement—trust decisions must reach the actual software making the connection.
Sources
Google: Chrome and Android protections, updated 4 November
Microsoft: Response to compromised eMudhra CA keys
