Fix Guides

Salesforce “Prepare for Certificate Changes”: What Changes, Who Is Affected, What to Do

Updated 2026-11-10

Key dates

• Feb 5, 2026: Salesforce's own certificates began moving to a chain that ends at DigiCert Global Root G2. A system that trusts only one older root, or pins a certificate, fails the handshake after a change like this. (Salesforce KB 005252999)
• Mar 15, 2026: Maximum lifespan of a publicly trusted TLS certificate: 200 days (from 398). (CA/Browser Forum SC-081v3; Salesforce release note)
• Mar 15, 2027: Chrome Root Program v1.8 enforced: subscriber certificates must assert server authentication only, so one public certificate can no longer serve as both server and client (mutual TLS) certificate. Public lifespan limit drops to 100 days. (Salesforce KB 005237282; Chrome Root Program policy)
• Mar 15, 2029: Maximum lifespan of a publicly trusted TLS certificate: 47 days. (CA/Browser Forum SC-081v3; Salesforce “Certificates in Salesforce”)

Symptoms

1. 1. You received the email and do not know if it applies to you. It applies if a system logs in to Salesforce with a client certificate (mutual TLS), if you own CA-signed certificates in Certificate and Key Management, or if a system that calls Salesforce pins a certificate or holds a narrow truststore.
2. 2. An integration authenticates to Salesforce with a certificate that is also its website certificate. That is a dual-use certificate. Per Salesforce's KB article, a single certificate can no longer be valid for both server and client authentication once the Chrome policy is enforced.
3. 3. A certificate renewal is due and your CA offers shorter terms. Public TLS certificates are capped at 200 days now, and the cap falls to 100 days on Mar 15, 2027. Renewal calendars built around a yearly cycle will miss.
4. 4. Callouts or inbound connections fail with an SSL handshake or certificate error. An expired or replaced certificate, or a truststore that lacks the issuing root, produces this. Check the certificate dates and the truststore before anything else.

What to Check

1. 1. List who logs in with mutual TLS. Find the users and API clients that use a Mutual Authentication Certificate for API login. Those are the integrations the dual-use change reaches.
2. 2. Find out where each client certificate comes from. Is the certificate issued by a public CA that chains to the same root as the server certificate? If so it is dual-use. Salesforce's KB says private or enterprise CAs are not affected by the Chrome policy, but also that Salesforce does not currently support private PKI for inbound mutual TLS, so check which CA is in play.
3. 3. Open Certificate and Key Management. In Setup, list every certificate with its expiry date and whether it is CA-signed. Note which are self-signed: per Salesforce, self-signed certificates are not subject to the new lifespans.
4. 4. Inventory certificates used by credentials. Check Named Credentials with a client certificate, External Credentials with a signing certificate and connected apps using the JWT bearer flow. Each depends on a certificate that expires.
5. 5. Check what trusts Salesforce. For systems that call Salesforce, confirm they trust the full Mozilla root list, not one named root, and do not pin a Salesforce certificate. Salesforce's customer email says it may switch or add root CA providers. Old Java is the usual gap: Salesforce's MuleSoft article says Java 8 before update 75 lacks DigiCert Global Root G2.
6. 6. Check what Salesforce trusts. For systems that Salesforce calls or that log in with a certificate, open /cacerts.jsp on your org's hostname. It lists the root CAs Salesforce trusts, and per the KB the same list is used for inbound mutual TLS.

How to Fix It

1. 1. Get a separate client certificate for each mutual TLS client. Use a public CA for the server identity and a different CA for the client identity. Per Salesforce's KB, the client certificate must contain the client authentication EKU and the issuing CA must be trusted by Salesforce. The KB names six roots whose CAs will still issue public client certificates: DigiCert Assured ID Root G2 and G3, SSL.com Client ECC and RSA Root CA 2022, and Sectigo Public Email Protection Root R46 and E46. GlobalSign Client Authentication Root E45 and R45 are not named in the KB but were on Salesforce's trusted root list at login.salesforce.com/cacerts.jsp when we read it on Nov 10, 2026. Confirm your chosen root is on your own org's list before you buy.
2. 2. Upload it and switch before March 15, 2027. Upload the new certificate as the Mutual Authentication Certificate, move the client over, and confirm a login in Login History before the old certificate is retired. Do this well ahead of your CA's own cutoff; the CAs' dates are earlier (see the FAQ).
3. 3. Move renewals to a shorter, calendared cycle. For certificates you own, plan to rotate more often and give the receiving system the new public certificate before you switch. Salesforce's release note asks you to assign the Expired Certificate Notification permission to specific admins and to use the Certificate metadata API type. Those notifications cover certificates stored in your org, not Salesforce's own TLS certificates.
4. 4. Trust the root list, drop pinning. Create a truststore from the Mozilla Server Authentication root list on any system that calls Salesforce, and remove certificate pinning. Salesforce guarantees only that its certificates chain to a root on that list, not to any one root. It says it typically rotates its certificates at least 45 days before they expire, that pinning is not supported on Hyperforce or for Marketing Cloud Engagement, and that it planned to stop announcing certificate rotations for first-party data center production orgs on July 6, 2026.
5. 5. Record the owner and the dates. Write down each certificate, what depends on it, the expiry and who renews it. Put Mar 15, 2027 on the calendar.

Check your org's certificate posture free: the free health check is a short questionnaire that gives a peer-benchmarked score, with no account and no org connection. Connected orgs get the CERT_001 to CERT_004 certificate checks.

Sources: Salesforce Help 005237282, 000385468, Certificates in Salesforce, Prepare for Shorter Certificate Lifespans, Mutual Authentication Certificate setup and 005252999 (MuleSoft); the Chrome Root Program policy and CA/Browser Forum SC-081v3. All were re-read on Nov 10, 2026. Dates can move, so confirm them in the live articles.

FAQ

Wrenk runs this kind of audit and the fixes that follow across every connected org as part of managed Salesforce operations.