Assume Every Certificate Expires
Module 7 of 7 in the shared chapter Keys, Certificates and Trust, chapter 3 of Securing Salesforce: Identity and Access and chapter 12 of Integration Architect. Each module stands on its own.
The question this module answers: Every certificate in this chapter has an end date. Why, what does replacing one mean, how does Salesforce issue and store certificates, and what breaks when one runs out?
Not before, not after
Section titled “Not before, not after”Go to any website you trust, click the padlock in the address bar, and open the certificate. You’ll see who it was issued to, who issued it, the public key, and two dates. Not before, and not after. That’s how long this certificate is good for.
Every certificate has those two dates. Steve’s Plumbing’s certificate has them. Salesforce’s has them. The certificate authority’s own certificate has them too, just much further apart. So here’s the rule I give every class: assume all certificates expire. That’s key hygiene. Don’t treat a certificate as something you install once. Treat it as something you’ll replace, on a date you already know.
Why a certificate has an end date
Section titled “Why a certificate has an end date”It seems like extra work. Why not issue a certificate that lasts forever? Three reasons.
A stolen key stops working by itself. If someone copies a private key, every day the certificate is still valid is a day they can pretend to be you. An end date puts a limit on that, even if nobody ever notices the theft.
Algorithms retire. You saw it in module 1 with DES, and in module 3 with SHA-1. Key sizes that were strong ten years ago aren’t today. A certificate that ends forces everyone to pick up today’s algorithms and today’s key sizes when they replace it.
Taking a certificate back is hard. A certificate authority can revoke a certificate before its end date, and publish that it did. But every browser and every server then has to check, every time, and the checks have always been slow and unreliable. In 2025, Let’s Encrypt, one of the largest certificate authorities, stopped running its online revocation check altogether, “primarily because it represents a considerable risk to privacy.” The industry’s answer is simpler: make certificates short-lived, so a bad one doesn’t live long.
Replacing one: reissuing
Section titled “Replacing one: reissuing”When a certificate is near its end, you don’t extend it. You reissue it: a new certificate, usually with a new key pair, signed again.
You already know how that’s done safely, from module 6. Whoever holds the certificate makes a new key pair and keeps the new private key. It sends a signing request, its name and its new public key, to the certificate authority. The authority signs it and sends back the new certificate. The private key never travels.
Then comes the part people forget. The new certificate has to go everywhere the old one was. Every server that presents it. Every partner that installed it in their keystore. Every identity provider that checks a signature with it. Miss one, and that one stops working on the old certificate’s “not after” date.
The public lifetimes are shrinking
Section titled “The public lifetimes are shrinking”For years, a public website certificate could last up to 398 days, about thirteen months. Renew it once a year and you were fine. That’s changing.
The browser makers and the certificate authorities set the rules for public certificates together, in a group called the CA/Browser Forum. In April 2025, they voted to cut the maximum lifetime in steps. The certificate authorities voted 25 in favour, none against, with 5 abstaining; all four browser makers, Apple, Google, Microsoft and Mozilla, voted in favour. Here’s the schedule, from the Forum’s Baseline Requirements, version 2.3.1:
| Certificate issued | Maximum lifetime | Renewals a year, roughly |
|---|---|---|
| Before 2026-03-15 | 398 days | 1 |
| 2026-03-15 to 2027-03-14 | 200 days | 2 |
| 2027-03-15 to 2029-03-14 | 100 days | 4 |
| From 2029-03-15 | 47 days | 8 |
Salesforce gives its own example. A certificate created on 1 June 2025 could last until 4 July 2026. One created on 1 June 2026 lasts only until 18 December 2026.
Look at the last column. Once a year, a person can remember. Eight times a year, for every certificate you own, a person will forget. That’s the real message of the schedule: renewing certificates is becoming machine work. Know where every certificate is, and automate the renewals wherever you can.
How Salesforce issues and stores certificates
Section titled “How Salesforce issues and stores certificates”In Salesforce, certificates live in Setup, in Certificate and Key Management. There are two kinds you create there.
A self-signed certificate. Salesforce makes the key pair and signs the certificate itself, “to show that communications purporting to come from your organization are really coming from there.” No outside authority is involved, so it’s free, and it’s what you share with a partner who installs it on purpose, as in module 6 when Salesforce calls out. It lasts one year with a 2048- or 3072-bit key, or two years with a 4096-bit key. Because no public authority signs it, the shrinking public lifetimes don’t apply to it. An org can hold up to 50 certificates; Salesforce Support can raise that.
A CA-signed certificate. Salesforce makes the key pair and a signing request. You send the request to a certificate authority, it signs it, and you upload the signed certificate back into Salesforce. The private key stays in Salesforce the whole time. Use this when the other side needs a public authority to vouch for you. It lasts as long as the authority allows, so it follows the public lifetimes in the table.
The same page holds a few more things you’ll meet in this course:
- Mutual authentication certificates: the client certificates that systems calling in with two-way TLS must present (module 6).
- Keystore import and export: to move certificates and their keys between orgs, for example from a sandbox to production.
- The Certificate Trust Store: your org’s own list of root certificates, including private ones, for checking TLS connections coming in. In Salesforce’s words, it’s for “inbound TLS connections (not inbound mTLS)”: as module 6 showed, two-way TLS into Salesforce accepts public roots only.
Who hears about it
Section titled “Who hears about it”Salesforce sends warning emails before a certificate in your org expires. If nobody has the Receive Certificate Expiration Notifications permission, every user with System Administrator or Modify All Data gets every warning. Once you give it to at least one admin, those admins get the emails 60, 30 and 10 days before, and everyone else hears only the day before, and on the day itself. So give that permission, on purpose, to the people who will actually do the renewal. A warning the day before is a warning that comes too late.
Salesforce’s own certificates, the ones its login pages and APIs present, are Salesforce’s job. Salesforce says it “typically rotates” them “at least 45 days before they expire.” Your job is not to get in the way. Salesforce “strongly recommends against certificate pinning”, which means hard-coding one particular certificate into a client instead of trusting the root it chains to. A pinned client breaks the day Salesforce replaces its certificate. Trust the root, as module 4 taught, and the replacement is invisible.
What breaks when one runs out
Section titled “What breaks when one runs out”When a certificate passes its “not after” date, nothing slows down gently. The check fails, and the connection or the sign-in stops. Here’s where that bites in this course:
- Single sign-on. The identity provider signs every login with its certificate, and Salesforce checks it (the Identity and Access course, chapter 6). An expired one, or a reissued one Salesforce was never given, and nobody signs in. Salesforce has retired its old
proxy.salesforce.comdefault certificate, “due to its expiration and for security best practices”, and tells orgs still using it for single sign-on to “act now to prevent a possible interruption of service.” - The JWT bearer flow. An integration signs its request with a private key, and Salesforce checks it with the certificate on the External Client App (the Identity and Access course, chapter 11, and the Integration Architect course, chapter 13). Replace the key without updating the app, and the integration stops.
- Two-way TLS. The client certificate is checked in every handshake (module 6). Expired means no handshake.
- Callouts. When Salesforce calls another system with its own certificate, and the other system has the old one in its keystore, the calls fail on the date.
Every one of those failures shows up as an outage, not a warning. That’s why the date belongs on a calendar, with an owner, before it arrives.
The end of the chapter
Section titled “The end of the chapter”Look back at the road we’ve travelled. A shared key that has to be carried (module 1). A key pair, silver and gold, where only one ever leaves home (module 2). A hash, and a signature that seals it (module 3). A certificate, and the authority that vouches for it (module 4). A handshake that builds a safe road between strangers (module 5), and proof in both directions when the road is private (module 6). And now the end date that every one of those certificates carries.
Every identity mechanism in the rest of this course rests on these pieces. When you set up single sign-on, OAuth or two-way TLS, you’ll be asked for a certificate, again and again. As I tell every class: as soon as you say the word trust, think digital certificate. And assume it expires.
What an architect decides here
Section titled “What an architect decides here”- Every certificate has an owner and a date. Keep an inventory: what it’s for, where it’s installed, who renews it, when.
- Automate renewals for public certificates. At 200, then 100, then 47 days, people will miss one.
- Self-signed or CA-signed, by job. Self-signed for partners who install it on purpose; CA-signed when a public authority must vouch, and for two-way TLS into Salesforce.
- Give the expiry warnings to the people who renew. Assign Receive Certificate Expiration Notifications on purpose.
- Never pin. Trust the root, so Salesforce’s own replacements never break you.
Exercise. Open your org’s login page in a browser and read its certificate: who issued it, the chain above it, and its “not before” and “not after” dates. Then open Certificate and Key Management in a sandbox and list every certificate there, with its end date and what uses it. Which one expires first, and who will replace it?
Explore
Section titled “Explore”- Certificates in Salesforce (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)
- Certificates and Keys (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)
- Generate a Self-Signed Certificate (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)
- Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (opens in a new tab), section 6.3.2 (CA/Browser Forum, version 2.3.1, 2026-10-04; checked 2026-10-31)
- Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods (opens in a new tab) (CA/Browser Forum, 2025-04-11; checked 2026-10-31)
- Ending OCSP Support in 2025 (opens in a new tab) (Let’s Encrypt, 2024-12-05; checked 2026-10-31)