You are here:
Certificates in Salesforce
Understand how certificates are used in Salesforce and how they expire. To prevent disruption and potential downtime, replace your certificates before they expire. Processes can stop working when a certificate expires, which can lead to outages.
Required Editions
| Available in: both Salesforce Classic and Lightning Experience |
| Available in: all editions |
Certificate Compliance and Expiration
Salesforce complies with the guidance of the Certification Authority Browser Forum (CA/Browser Forum), the organization that sets most of Web Public Key Infrastructure (WebPKI) rules. Salesforce adheres to their Transport Layer Security (TLS) Server Baseline Requirements, which change regularly. These requirements are outside of Salesforce control, and all certificate vendors are bound by the rules of the CA/Browser Forum.
The CA/Broswer Forum is implementing a phased approach to shorten the maximum allowed certificate lifespan and the maximum reuse period for domain validation information.
- Until March 15, 2027, the maximum lifespan and maximum reuse period for domain validation information is 200 days.
- As of March 15, 2027, the maximum lifespan and maximum reuse period for domain validation information is 100 days.
- As of March 15, 2029, the maximum lifespan is 47 days and the maximum reuse period for domain validation information is 10 days.
These maximum lifespans and reuse periods apply at the time of certificate creation. For example, the latest possible expiration date of a TLS certificate created on June 1, 2025 is July 4, 2026. But the latest possible expiration date of a TLS certificate created on June 1, 2026 is December 18, 2026.
Because Salesforce complies with the guidance of the Certification Authority Browser Forum (CA/Browser Forum), these changes apply to certificates created in Salesforce.
Currently, when you create a self-signed certificate in Salesforce, that certificate expires after one year. CA certificates that you import into Salesforce expire based on the rules of your vendor, which conform to CA/Browser Forum rules. The current maximum time period for domain validation information reuse is 200 days, after which Domain Control Validation (DCV) is required. Salesforce plans to publish a release note as we reach each milestone.
To receive notifications about upcoming expirations for certificates stored in your org, assign the Expired Certificate Notification permission to specific admins. See Set Expired Certificate Notification Permission. Those notifications apply to certificates that are stored in your org, not Salesforce TLS certificates.
Salesforce Certificates
To deliver a trustworthy experience, Salesforce uses High Availability (HA), Disaster Recovery (DR), load balancing, and auto-scaling technologies. With this approach, Salesforce orders and provisions certificates as needed. Hyperforce services already implement this approach.
Salesforce typically rotates the certificates that we provide at least 45 days before they expire, though a certificate can be rotated by the platform sooner.
Salesforce Features That Use Certificates
In Salesforce, certificates are used for encryption in transit and encryption at rest, for Certificate-Based Authentication, and for some Single Sign-On options. You can also use a certificate that you own to serve a custom domain. If you use these features, prepare to update the related certificates according to the new cadence, as your certificate vendor is also bound by the CA/Browser Forum rules.
If you use a certificate stored in Salesforce to serve your custom domain, consider updating your custom domain to use the Salesforce CDN or a third-party CDN or service that manages certificates. The Salesforce CDN is available only for custom domains that serve an Experience Cloud site. Both configuration options reduce your effort to manage certificates with shorter lifespans.
TLS Certificate Cryptography
All certificates that Salesforce uses for TLS have these properties.
- Key parameter: RSA 2048 bit, RSA 3072 bit, RSA 4096 bit, ECDSA P-256 curve, ECDSA P-384 curve, or ECDSA P-521 curve
- Signature algorithm: SHA256, SHA384, or SHA512
Create the Required Root Certificate Truststore
The certificates Salesforce issues are intended for use with TLS. Salesforce guarantees that our issued certificates chain to a root certificate authority (CA) on the Mozilla Server Authentication (SSL/TLS) Root Certificates List. To support TLS in Salesforce, create a truststore that contains all those root CAs.
Don't Pin Other Certificates
Certificate pinning is the practice of selecting a single certificate or set of certificates to trust that aren’t root CAs. Pinning is an outdated security practice that adds operational complexity, can cause outages when the pinned certificate expires, and can cause outages when you use a new certificate that's not part of the pinset. Outage risks increase as the maximum lifespan for a TLS certificate decreases.
In line with OWASP’s guidance on Certificate and Public Key Pinning, Salesforce strongly recommends against certificate pinning.
Certificate pinning isn’t supported in Hyperforce or for Marketing Cloud Engagement customers. And if you pin the authentication certificate for the Salesforce mobile app, users can’t log in after a certificate is rotated until you update the app or the user reinstalls the app.
If you pin certificates, we encourage you to stop that practice as soon as possible.
Although Salesforce strongly advises against certificate pinning, we recognize that some customers pin certificates for orgs in first-party (1P) data centers. For those customers, Salesforce announces upcoming certificate changes only for production orgs in 1P data centers until July 6, 2026. If your org isn’t on Hyperforce yet, you can receive those notifications via the Certificate Changes Trailblazer Community group.
Automate Certificate Rotation
To create and update self-signed and Certificate Authority (CA)-signed certificates in Salesforce, use the Metadata API type.
Global Trust Store vs. Certificate Trust Store
The Salesforce global trust store compares to the Certificate Trust Store as follows:
| Salesforce Global Trust Store | Certificate Trust Store |
|---|---|
| A single, shared trust store maintained by Salesforce across all tenants. | Each Salesforce org gets its own isolated trust store. |
| Contains a standard set of trusted root/intermediate CAs. | Supports private/internal CAs that wouldn't be in a global store (e.g., your org's internal PKI). |
| Tenants have no control over what's in it — it's one-size-fits-all. | Changes in one org's trust store have no impact on other orgs. |
| If Salesforce adds or removes a CA, it affects every org simultaneously. | Changes in one org's trust store have no impact on other orgs. |
| Works fine for standard public CAs (DigiCert, Comodo, etc.), but doesn't accommodate custom or private CAs. | Enables compliance with strict security policies that require controlling exactly which CAs are trusted. |
