emSign Checker

Checker › Fix guide

How to replace a certificate on the emSign ECC Root CA - G3 chain

Firefox stopped trusting emSign ECC Root CA - G3 on 20 October 2026 and Chrome follows on 27 October. If your site still uses that chain, visitors will start seeing security warnings. Here is how to move off it.

Last updated

Check your site first

The short version

  1. Confirm you are affected. Run your domain through the checker. You need to act only if the chain includes emSign ECC Root CA - G3 or one of the revoked intermediates.
  2. Choose where to reissue. Either reissue with eMudhra on its RSA chain, which eMudhra says is the migration path, or switch to another publicly trusted CA.
  3. Reissue the certificate. For ACME clients (certbot, acme.sh, Caddy, cert-manager), force a renewal against the new chain or CA. For manually issued certificates, generate a new CSR and request reissuance.
  4. Install the full new chain. Deploy the new certificate together with its new intermediate. Remove the old emSign G3 intermediate from your server chain file.
  5. Verify. Re-run the checker and confirm the chain no longer mentions emSign ECC Root CA - G3.

What is ACME?

ACME (Automatic Certificate Management Environment) is the standard protocol servers use to get and renew certificates automatically. A small program on your server, such as certbot, acme.sh, Caddy or Kubernetes cert-manager, asks the certificate authority for a certificate, proves it controls the domain, installs the certificate, and renews it before it expires. Each certificate authority publishes an ACME directory URL that the program talks to; for example, Let's Encrypt's is https://acme-v02.api.letsencrypt.org/directory.

If your certificate was issued through ACME, fixing it usually means changing that one URL (to eMudhra's RSA chain or to another certificate authority) and forcing a renewal. No purchase or paperwork is needed.

Reissuing with an ACME client

Most affected certificates (about 97%, per eMudhra) were issued through ACME. Point the client at the ACME directory URL your new CA or eMudhra's RSA chain gives you, then force a renewal. Replace <ACME_DIRECTORY_URL> with that URL.

certbot

sudo certbot certonly --server <ACME_DIRECTORY_URL> \
  --cert-name example.com -d example.com -d www.example.com \
  --force-renewal
sudo systemctl reload nginx   # or apache2

acme.sh

acme.sh --issue --server <ACME_DIRECTORY_URL> \
  -d example.com -d www.example.com -w /var/www/html --force
acme.sh --install-cert -d example.com \
  --fullchain-file /etc/ssl/example.com/fullchain.pem \
  --key-file /etc/ssl/example.com/key.pem \
  --reloadcmd "systemctl reload nginx"

Caddy

{
  acme_ca <ACME_DIRECTORY_URL>
}

Then delete the stored certificate for the site from Caddy's data directory and reload so it obtains a fresh one.

Kubernetes cert-manager

Update the server: field of your Issuer or ClusterIssuer, then delete the certificate's Secret (or run cmctl renew <certificate-name>) so cert-manager reissues it.

Manually issued certificates

Generate a new key and CSR, request reissuance from your provider, and install the new certificate with its new intermediate. Do not reuse a chain file that still contains the old emSign G3 intermediate.

openssl req -new -newkey rsa:2048 -nodes \
  -keyout example.com.key -out example.com.csr \
  -subj "/CN=example.com"

Update trust stores on servers and containers

Browsers update themselves, but servers, containers, and apps that make outbound HTTPS calls use their own trust stores. Update these so your systems also stop trusting the removed root:

Check for code-signing certificates too

Two of the eight compromised intermediates were for code signing. If your organization signs software with an eMudhra code-signing certificate, paste it into the checker's certificate tab and contact eMudhra about reissuance.

Re-check your site