What happened
On 2 November SF Ben reported that Salesforce had emailed admins about three certificate changes, citing security vulnerability and service disruption risks (independent, SF Ben). Partner write-ups name the three as the root move, shorter lifespans, and the end of dual-use certificates (independent, enosix and Tython).
Most orgs have one question to answer, not three: does anything authenticate to Salesforce with a client certificate? If yes, this note is for you.
| Change | Date | Who has work |
|---|---|---|
| Root move to DigiCert Global Root G2 | From 5 February 2026 (independent) | Middleware and custom clients whose trust stores lack the root |
| Shorter public certificate lifespans | 200 days from 15 March 2026, 100 from 15 March 2027, 47 from 15 March 2029 (independent) | Anyone renewing CA-signed certificates by hand. Salesforce manages the server certificate unless you use a custom one (vendor) |
| End of dual-use client certificates | 15 March 2027 (vendor) | Orgs with mTLS on a public root in the Chrome Root Store |
The fix that does not work here
From 15 March 2027, Chrome's root policy lets public subordinate CAs and subscriber certificates assert server authentication only. The usual advice is to move client certificates to a private CA, and that is sound in plenty of estates (independent, WorkOS).
Salesforce's PKI article contains two sentences that are easy to merge into one. It says private and enterprise CAs are outside the change. It also says: "Salesforce doesn't currently support private PKI offerings in our application for mTLS" (vendor, Salesforce).
Both are true. Chrome is not stopping you using a private CA. Salesforce is. Its setup guide says a client certificate must chain to a valid root for your instance, listed at /cacerts.jsp (vendor, Salesforce Help). So an inbound integration needs a public client certificate, from a separate hierarchy, with the Client Authentication EKU.
Salesforce names the roots it has confirmed will keep issuing them (vendor):
- DigiCert Assured ID Root G2 and G3
- SSL.com Client ECC Root CA 2022 and Client RSA Root CA 2022
- Sectigo Public Email Protection Root R46 and E46
- GlobalSign Client Authentication Root E45 and R45
Which date to believe
Salesforce's PKI article says enforcement moved from 15 June 2026 to 15 March 2027, under Chrome Root Program Policy v1.8 (vendor). When we read it on 3 November, Salesforce's own mutual authentication setup guide still said v1.7 and 15 June 2026 (vendor). Partner pages carry the June date too (independent). If your runbook says June, it is out of date. It does not mean you have months to spare.
The date that matters is your renewal. An existing certificate keeps working until it expires, and the failure arrives when the replacement comes back without the client EKU (independent, WorkOS). WorkOS lists Sectigo ending it on 10 February 2027 and DigiCert on 1 March 2027 for public TLS certificates. Salesforce warns that some CAs are dropping the EKU before the deadline (vendor).
Find your row
| Your setup | Position | Action |
|---|---|---|
| No user holds Enforce SSL/TLS Mutual Authentication, and no mutual authentication certificate is uploaded | No inbound mTLS | Record that and close it |
| Inbound mTLS, client certificate on a public root in the Chrome Root Store | Affected (vendor) | Reissue from a listed root before your expiry |
| Inbound mTLS, client certificate already on a listed root with the client EKU | Matches Salesforce's stated requirements | Confirm against /cacerts.jsp and log it |
| Inbound mTLS planned on a private CA | Not supported today (vendor) | Stop and take it to Salesforce |
| Outbound callouts presenting a client certificate | Salesforce covers these in a separate document we have not read | Check with the owner of the receiving endpoint |
Five steps
Prerequisites: Customize Application permission, access to each integration's owner, and a sandbox with the mutual authentication feature enabled.
- Step 1. Find the integrations. Check Certificate and Key Management for mutual authentication certificates, and list users holding Enforce SSL/TLS Mutual Authentication. These connect on port 8443. Owner: Salesforce platform owner.
- Step 2. Read each certificate. Record issuer, expiry, and EKUs:
openssl x509 -noout -issuer -enddate -ext extendedKeyUsage. Owner: integration team. - Step 3. Match the chain. Compare each root with
/cacerts.jspon your instance and the list above. Owner: security. - Step 4. Reissue and test. Ask your CA for a client certificate from the separate hierarchy, then test on port 8443 in a sandbox. Owner: integration team.
- Step 5. Cut over and calendar it. Upload the new certificate before removing the old one. Salesforce says removal can take up to five minutes to clear sessions and the cached certificate (vendor). Add every expiry to one owned calendar. Owner: Salesforce platform owner.
Publishing the truststore is Salesforce's job. Knowing what your integrations present is yours.
Trade-offs
- Stay on mTLS with a listed root. Least change to the integration. You now run a separate client certificate hierarchy and pay for it.
- Replace mTLS with OAuth where it only proves identity. One fewer certificate to renew, but you change the integration and need your security team's sign-off. If a regulator or contract names mTLS, this route is closed.
- Wait for the renewal. Cheapest today. It only works if the expiry falls after your CA's cut-off and you have checked that date.
Missing
- The full text of Salesforce's email. We could not read SF Ben's article, only its summary.
- The count of orgs affected. Salesforce gives none.
- Any date for private PKI support. Salesforce says "currently" and gives no roadmap.
- Salesforce's outbound mTLS document, and its release note on mTLS certificates, which would not load.
Frequently asked questions
Does every Salesforce org need to do this?
No. The dual-use change matters if your org uses inbound mTLS and the client certificate chains to a public root in the Chrome Root Store. An org with no mTLS has no work on this change.
Can we move our client certificate to a private CA?
Not for inbound mTLS today. Chrome's rule does not touch private CAs, but Salesforce says it does not currently support private PKI in its application for mTLS. Use a public client certificate from a root Salesforce lists.
What is the real deadline?
Salesforce's PKI article says enforcement moved from 15 June 2026 to 15 March 2027. Your CA may stop issuing sooner, and a certificate fails at renewal, so work back from your own expiry date.
Living page. Last updated 3 Nov 2026. We update this note when Salesforce changes its private PKI position or corrects its setup guide.