Your certificate expires next year. Will Chrome still trust it tomorrow?

Imagine your hosting dashboard says the certificate is valid for another eight months. You’ve checked the expiry date, the padlock works, and renewal is someone else’s problem until spring. Then your host sends a notice about a browser trust change arriving tomorrow.

The expiry date doesn’t answer whether a browser still trusts the certificate’s chain. For website operators affected by the current eMudhra change, that’s the question to put to the host today.

Check the chain named in the notice

Google’s October 20 notice says removal of emSign ECC Root CA - G3 from the Chrome Root Store is expected Tuesday morning, October 27, Pacific time, with prerelease channels earlier. Some legitimate certificates chaining to that root will stop working. Google directs affected website operators to obtain and install a replacement from another hierarchy included in the Chrome Root Store.

That’s a specific chain, rather than a finding that every certificate from the company is affected. Ask your provider to identify the chain actually served by your domains, including custom domains sitting behind a CDN or managed platform. Keep an unanswered domain on the list until someone has established its status.

Give the host a question it can finish

For our hypothetical business owner, I’d send a short request with the domains and a named contact: “Does the certificate chain currently served for each of these domains include emSign ECC Root CA - G3? If so, what replacement will you deploy, who owns the change, and how will we verify the served chain afterward?”

Use the certificate-chain handoff brief to keep the scope, provider answer and unresolved domains together. It creates a local text record. It doesn’t inspect certificates, determine trust or make a server change.

If the provider confirms a replacement is needed, coordinate the change with whoever manages TLS for the service. Ask for evidence from the deployed endpoint after the change, including relevant alternate endpoints. A certificate order or a reassuring account-level message can leave the actual served configuration unverified.

Keep the check separate from a site rebuild

A browser trust change doesn’t give an assistant permission to install packages, change DNS, replace keys or rewrite your application. Keep the task narrow. Establish what’s served, get the operator’s plan and verify the authorized change. Don’t ask visitors to click through a certificate warning as a workaround.

If your own site isn’t affected, keep the answer and its scope instead of turning this into an emergency project. A dated record is useful when another domain is added or a provider changes its certificate configuration.

Illustrative workflow, not a scan of your sites. Browser schedules and provider instructions can change; recheck the linked notice before acting. We haven’t assessed a live certificate chain for this article.