Salesforce Certificate Changes: Dual-Use, mTLS, and 47-Day Lifetimes

Salesforce emailed administrators with the subject ACTION REQUIRED: Prepare for Certificate Changes. The message is about an industry PKI change. People who only log in to Salesforce with a current browser are mostly unaffected. The business risk is quieter: an integration renews a certificate, the new file is legal for only one job, and a callout, a mutual-TLS login, or a custom domain stops. That failure arrives on the renewal date, which is why an org that looks healthy today can still be exposed.

The three changes

Three separate rules are traveling together in that email. They hit different certificates. Treat them as a checklist, and record which rule applies to each file you own.

• Dual-use certificates. A public CA certificate that is both a TLS server certificate and a client certificate for mutual TLS. Public CAs are stopping that combination. Chrome’s rule for new certificates is March 15, 2027. Some CAs, including DigiCert, moved earlier.
• Shorter lifetimes. Public TLS server certificates are already capped at 200 days. The cap becomes 100 days on March 15, 2027 and 47 days on March 15, 2029. A certificate already issued keeps the expiry printed on it.
• Trust stores. Callers with a custom trust store need the Mozilla TLS server root set when they connect to Salesforce. Pinning one DigiCert root is the fragile pattern. Salesforce can change which root it presents.

Salesforce rotates the certificates on its own hostnames, including *.my.salesforce.com, unless you brought your own certificate for a custom domain. The work that belongs to you is every certificate you uploaded, every client certificate your integrations present, and every trust store you curate outside Salesforce.

Dual-use certificates and inbound mTLS

A dual-use certificate is a public CA certificate used in both roles: TLS server authentication and client authentication for mTLS. The extended key usage extension lists both server authentication and client authentication. Teams created these because one purchased file could terminate TLS on a custom domain and also be the certificate Apex or a partner presented during mutual TLS. That shortcut is what the policy removes.

The Chrome Root Program Policy requires subscriber certificates issued on or after March 15, 2027 that chain to a Chrome-trusted root to carry server authentication only. Salesforce’s guide to these certificate changes says that date moved from June 15, 2026. A certificate you already hold keeps working until it expires. Salesforce has not published an earlier hard cutoff of its own.

Your CA may still be ahead of Salesforce. DigiCert turned client authentication off by default on October 1, 2025, and removes it, including on renewals, on March 1, 2027. Some customers already fail at renewal because their CA dropped clientAuth before the Chrome date. If DigiCert is your CA, March 1, 2027 is the renewal cliff for a dual-use file, even though Chrome’s line is March 15.

Inbound mTLS is the case where an external user or application presents a client certificate to Salesforce. Salesforce’s guide to these certificate changes says Salesforce does not currently accept a private CA for that direction. The client certificate needs the clientAuth extended key usage, and it has to chain to a root Salesforce is adding:

• DigiCert Assured ID Root G2 and DigiCert Assured ID Root G3
• SSL.com Client ECC/RSA Root CA 2022
• Sectigo Public Email Protection Root R46 and Sectigo Public Email Protection Root E46

Those Assured ID roots are the client-authentication roots. They are a different pair from DigiCert Global Root G2 and G3, which are server roots Salesforce has used on its own hostnames. Buying “a DigiCert G2” without reading the product name is how this goes wrong.

Confirm the issuing root on that org’s https://<my-domain>/cacerts.jsp page before you purchase. The list can differ by instance. The certificate also has to send the chain, and it has to be mapped to the user or uploaded on the Mutual Authentication page, depending on whether the caller is a person or an API. A certificate that completes the TLS handshake and is not mapped to an account still fails at the application layer.

Where the two Salesforce documents disagree

On March 18, 2026 Salesforce published a taxonomy of certificates in the short-lived era. The call to action in that post tells customers to handle the clientAuth restriction by sourcing mTLS client certificates from a private PKI, or, if they stay with a public CA, to move to a server-only certificate or another authentication method. The same post also says inbound client certificates must chain to a root on cacerts.jsp, that Salesforce cannot trust a private PKI for the third-party servers it calls, and that a private PKI certificate is usable when Salesforce itself is the client on an outbound mTLS call.

Those sentences describe different directions. Salesforce’s guide to these certificate changes matches the admin email, and it is the one to follow for inbound mTLS: a private CA is not accepted there today. Private PKI is a sound choice for outbound client certificates, where Salesforce presents the certificate to your server, and for SAML or JWT signing. Split the inventory by direction before you place an order with a CA.

Shorter public certificate lifetimes

CA/Browser Forum ballot SC-081v3 passed in April 2025. It reduces the maximum validity of public TLS server certificates on a fixed schedule. A certificate already issued keeps its original expiry. The pain is the next renewal, when the CA will only sell you the shorter window.

The March 2026 Salesforce post illustrates the operational problem with a certificate that expires about every 45 days. The ballot’s number is 47 days, and that cap starts March 15, 2029. Use the ballot dates when you build the renewal calendar. Use the blog for the taxonomy of who rotates what.

This cap covers public TLS server certificates. It does not cover self-signed certificates you use to sign SAML assertions or JWTs. Salesforce-generated self-signed certificates last one year at 2048 bits and two years at 4096 bits. Customer-uploaded certificates in Certificate and Key Management do not auto-renew, whether they are CA-signed server certificates or signing certificates you uploaded yourself. Someone, or a runbook you trust, has to replace them.

Salesforce continues to rotate certificates on hostnames it owns. The exception is Bring Your Own Certificate: a custom domain whose certificate you uploaded. That file follows your CA’s lifetime, and Salesforce will not renew it for you. A 200-day certificate purchased this quarter is already a calendar problem. A 47-day certificate in 2029 is the same problem on a shorter loop. If renewal is a ticket that waits on one person, fix that process while the maximum is still 200 days.

Trust stores and Mozilla roots

The third change is about callers that connect to Salesforce with ordinary one-way TLS and that do not use the operating system’s trust store. Browsers and up-to-date OS trust stores already carry a broad public root set. A JVM trust store, an API gateway, a corporate proxy, an old Data Loader install, or a MuleSoft truststore often contains a shorter list, sometimes a single pinned DigiCert root.

Those callers need to trust the Mozilla TLS server root set. Salesforce has presented chains under DigiCert Global Root G2 and DigiCert Global Root G3, and it can change roots again. There is no published date for the next swap. Trusting the Mozilla server set, and keeping it current, is what makes the next swap boring. Trusting whichever root you observed last year is what makes it an incident.

Self-signed certificates and custom-CA certificates that you use for your own SSO are outside this requirement. An identity provider’s signing certificate is trusted explicitly, certificate to certificate, with no public root involved. Leave that trust entry as it is. The Mozilla requirement is for the TLS path into Salesforce.

MuleSoft is in scope when Mule calls Salesforce. A custom Mule truststore has to include the current Salesforce chain. Salesforce’s note on MuleSoft and the DigiCert root covers the DigiCert Global Root G2 cutover on February 5, 2026, which is already past. If that truststore was updated in February, the remaining job is to carry the Mozilla server roots so the next change does not depend on another emergency pin. Leave TLS verification enabled. A connection that “works” because verification was turned off is not a completed change.

How to see whether your org is affected

There is no metadata field named dual-use. The closest signal you can defend in a design review is a single Certificate used in two places at once: as the API client certificate, on a Named Credential, or in Apex via setClientCertificateName, and also as the server certificate on a custom domain. Confirm it by reading the public .crt. Extended key usage of serverAuth plus clientAuth, on a certificate issued by a public CA, is the dual-use case.

Metadata will not show you everything. A retrieve of Certificate returns the public chain. It does not return the private key. Keep keystores and private keys out of git. Salesforce’s own edge certificates, the trust stores on your proxies and JVMs, and the MuleSoft control plane are outside the org metadata. The API Client Certificate selection is visible in the Certificate and Key Management UI and is not marked on the Tooling row.

What to open

Read-only queries

List the certificate metadata, then run the Tooling query. Repeat the list for InboundCertificate, UserAuthCertificate, NamedCredential, ExternalCredential, SamlSsoConfig, CustomSite, and ConnectedApp.

sf org list metadata -m Certificate

sf data query --use-tooling-api --query "SELECT Id, DeveloperName, MasterLabel, KeySize, ExpirationDate, OptionsIsCaSigned, OptionsIsUnusable FROM Certificate"

Download the public certificate from Certificate and Key Management, or use the public certificate in the retrieved metadata, and read the extension:

openssl x509 -in file.crt -noout -text

In that text, read Serial Number, Not After, Issuer, and Extended Key Usage. Server Authentication alone is a normal public server certificate. Client Authentication alone is a client certificate. Both, from a public CA, is the dual-use file you need to split. Then search the repo for setClientCertificateName so a certificate referenced only from Apex still shows up. The API Client Certificate dropdown still has to be read on screen. No query replaces that click.

Sort each row into one of these outcomes. The sort is the decision. The documents disagree if you skip it.

• Inbound mTLS into Salesforce. Public certificate with clientAuth, chaining to a root named in Salesforce’s certificate guide and present on this org’s cacerts.jsp. A private CA is the wrong purchase while that guidance stands.
• Outbound client certificate. Salesforce is the client: Apex, a Named Credential, or an External Credential. Private PKI is appropriate. A public dual-use renewal will fail when the CA stops issuing clientAuth.
• Custom-domain or Bring Your Own Certificate server certificate. Public CA, serverAuth only, with a lifetime inside the cap that applies on the day you renew. Salesforce rotates *.my.salesforce.com when you have not uploaded a certificate.
• SAML, JWT, or Connected App signing. Outside the public TLS lifetime cap. Self-signed is normal. Salesforce-generated certificates last one year at 2048 bits and two years at 4096 bits. Uploaded certificates do not auto-renew. Private PKI is fine.
• Custom trust store calling Salesforce. Mozilla TLS server roots, including MuleSoft when Mule is the caller. Your own IdP signing certificate is a different trust decision and stays as an explicit pin of that certificate.

What to do before March 2027

From October 29, 2026, the plan is an inventory finished in November, a sandbox proof by late December, and a production cutover with overlap before March 2027. March matters because DigiCert’s clientAuth removal on renewals is March 1, 2027, and the Chrome serverAuth-only rule for newly issued public certificates is March 15, 2027. You do not need a big-bang weekend. You do need the new certificate live beside the old one.

Read the new serial from openssl x509 -in file.crt -noout -text and match it to the serial the handshake or the Mutual Authentication page is showing. When those two serials are the same, remove the old certificate. Deleting the old file on the day you upload the new one is how you turn a planned renewal into an outage of your own making.

Put the next expiry on a calendar that matches the cap in force that day: 200 days for a public server certificate issued now, 100 days once you renew on or after March 15, 2027. Signing certificates follow their own one-year or two-year Salesforce lifetimes, or whatever expiry you uploaded. Neither kind renews itself.

The admin email includes three live sessions. They are not on the public Salesforce events page, and recordings will not be shared. Confirm the registration link in the message you received:

• November 4, 2026, 09:00 UTC
• November 4, 2026, 15:00 UTC
• November 5, 2026, 23:00 UTC

A session is useful context. It does not replace the inventory. The person who owns the Mule truststore and the person who owns the Apex callouts should be in the same working session as the Salesforce admin. This change crosses that boundary.

Documents to read before you change production

• Salesforce’s guide to these certificate changes — the article that moved the dual-use date from June 15, 2026 to March 15, 2027, and that states the inbound mTLS rules.
• Changes to public key infrastructure — Mozilla roots, shorter lifetimes, and why pinning one certificate causes outages.
• Salesforce SSL/TLS certificate trust — which roots Salesforce accepts when it calls another system.
• Impact on MuleSoft applications — the DigiCert Global Root G2 change on February 5, 2026.
• From manual to automated — Salesforce’s March 18, 2026 breakdown of who rotates which certificate. Where that post and the PKI guide disagree on inbound mTLS, follow the PKI guide.
• CA/Browser Forum ballot SC-081v3 — the 398 / 200 / 100 / 47 day schedule.
• Chrome Root Program Policy — serverAuth-only subscriber certificates issued on or after March 15, 2027.

Frequently asked questions