Salesforce certificate expiry: find and renew before it breaks

What breaks

Salesforce uses org certificates for single sign-on (the request signing and assertion decryption certificates), for its own Identity Provider, for mutual TLS, for connected apps that sign with a certificate, and for two-way SSL Apex callouts. Salesforce's own wording: processes “can stop working when a certificate expires, which can lead to outages”. Ordinary callouts that are not two-way SSL do not use org certificates.

The Identity Provider is easy to forget. It was switched on by default in many orgs and created a self-signed certificate for itself, so an org can have a live SSO dependency nobody set up on purpose.

Find them

1. In Setup, search Quick Find for Certificate and Key Management. Each certificate shows its expiration date.
2. Click a certificate's name to see it. If Delete is greyed out, it is in use; hover over Delete to see where.
3. For Apex two-way SSL callouts, retrieve your Apex and search it for the certificate's unique name.

To list them with dates through the Tooling API (version 37.0 or later):

SELECT DeveloperName, MasterLabel, ExpirationDate, KeySize, OptionsIsCaSigned
FROM Certificate
ORDER BY ExpirationDate

With the Salesforce CLI, run it as sf data query --use-tooling-api -q "...".

Renew

Self-signed

1. Certificate and Key Management, Create Self-Signed Certificate.
2. Enter a label, a unique name and a key size. Type and key size cannot be changed after saving.
3. Save, and download the .crt if the other side needs it (an identity provider, an API gateway).

CA-signed

1. Create CA-Signed Certificate, fill in the fields and save.
2. Download the certificate signing request (.csr) and send it to your certificate authority.
3. Upload Signed Certificate. It must be issued from this org's request, or the upload fails. Uploading again updates the expiration date.

Then switch everything over

Point every consumer at the new certificate: SSO settings, Setup > Identity Provider, connected apps and Apex. Only delete the old certificate once its Delete link is active. If the Identity Provider lists service providers, replace its certificate rather than disabling it; deleting an Identity Provider certificate stops single sign-on and users must log in with org credentials.

Lifetimes and limits

• Self-signed: 2048-bit and 3072-bit keys last one year; 4096-bit keys last two years.
• CA-signed: the certificate authority sets the lifetime. Public certificates are capped at 200 days now, 100 days from 15 March 2027 and 47 days from 15 March 2029. Self-signed certificates are exempt.
• An org can hold 50 certificates. Salesforce Support can raise the limit.
• Custom domains served through the Salesforce CDN are renewed automatically.

What Salesforce tells you, and the gaps

Give one or more admins the Receive Certificate Expiration Notifications permission and they get emails 60, 30 and 10 days before expiry. Everyone else with System Administrator or Modify All Data hears only the day before and the day of expiry. If nobody holds the permission, all of those admins get every email.

The emails cover certificates stored in your org, not Salesforce's own TLS certificates, and they go to individual inboxes, which stop being read when people leave. An identity provider certificate uploaded into SSO settings is not a Certificate record, so it is not covered; see the SAML certificate guide.

Common mistakes

1. Deleting an “unused” certificate that the Identity Provider still uses.
2. Creating the new certificate but never switching the SSO setting, connected app or Apex to it.
3. Uploading a CA-signed certificate that was not issued from this org's request.
4. Planning yearly renewals for CA certificates when public lifetimes are dropping to 100 and then 47 days.