Skip to main content

Action required: Replace your Stanford SSL/TLS certificates by Nov. 16, 2026

Stanford's SSL/TLS certificates are issued through InCommon by the certificate authority emSign. emSign is ending its public certificate service and InCommon is moving all members to a new certificate authority, SSL.com. 

Every Stanford certificate issued by emSign will need to be replaced. Apple removes trust in all emSign certificates on Nov. 30, 2026, regardless of when they were issued, and some recent macOS versions (27.2.1) already reject them.

Note: Certificates issued prior to July 10, 2026, were issued through Sectigo and are not affected. 

Please don't renew or replace your certificates until we tell you SSL.com is live. Anything issued before then still comes from emSign and would have to be replaced again.

Key dates

  • Nov. 12 (night): SSL.com goes live for Stanford. From then on, new and renewed certificates are issued by SSL.com.
  • Nov. 13: Start replacing or renewing your certificates
  • Nov. 16: emSign stops issuing new certificates.
  • Nov. 16: Microsoft starts to remove the remaining eMudhra root certificates across its products and services.
  • Nov. 30: Replace existing certificates by this date. Apple removes trust in all emSign certificates on Nov. 30, regardless of when they were issued.

Do my current certificates still work?

  • In Chrome and Firefox, yes: Certificates issued before Nov. 16 keep working until they expire. 
  • On Apple devices, no: Apple removes trust in all emSign certificates on Nov. 30, 2026, and some recent macOS versions (27.2.1) already reject them. Java, Oracle, Amazon Linux and VMware products have also already stopped trusting emSign.
  • Replace everything before Nov. 30. Anything reached from Macs, iPhones or iPads stops working that day.
  • Replace these first: Services used from Macs and iPhones, and anything with a custom trust store.

What you need to do

  1. Find your certificates. List the servers, services, and applications you run that use a Stanford certificate issued by emSign (issuer: "InCommon Intermediate CA").
  2. Replace each certificate once SSL.com is live. Use the same request form at certificate.stanford.edu. If you use ACME (for example, certbot) or the Certificate API, run a forced renewal after the switch; your settings and credentials don't change.
  3. Install the full chain. Download the "Certificate (w/ chain)" version so your server sends the new SSL.com intermediate certificate.
  4. Update anything that trusts the old chain. This includes Java keystores, load balancers (F5), appliances, client certificate (mTLS) setups, and Wi-Fi/RADIUS or Mac configuration profiles that include the emSign certificates.

What changes for you

  • Browsers: No change. SSL.com is trusted by all major browsers and operating systems.
  • Certificate type: Certificates are initially issued as Domain Validated (DV) rather than Organization Validated (OV), until SSL.com OV is available. Most services are unaffected. If your service requires OV (the organization name in the certificate), contact us.
  • Request process and eligibility: Unchanged. The name must still exist in NetDB, and you must be listed on its NetDB record.

More information

Add these links “Known emSign G1 removals / impacts":

Check the SSL service page for the latest information and updates. For help, submit a Help request. We'll send email updates as dates are confirmed.

Last modified