From Manual to Automated: A Taxonomy to Secure Your Salesforce Environment in the Short-Lived Certificate Era

Digital (X.509) certificates are a fundamental component of properly secured, trusted infrastructure. An industry-wide shift to shorter certificate lifetimes increases their importance within your Salesforce environment.

The 365-day vacation of managing digital (X.509) certificates is over. The industry-wide security shift to shorter certificate lifetimes demands closer attention, preferably automation, to avoid disruption from expired certificates. For the last decade, managing certificates in Salesforce has been a relatively calm ritual. Many certificates have been supplied and kept up-to-date by Salesforce. Some have been customer supplied. With certificate lifespans stretching to 365 days or longer, a system administrator uploads a certificate and waits for an annual email reminder that it was expiring. It was a manual task, but it was manageable. That era of “set it and forget it” created a massive security and availability vacuum and is rapidly coming to a close.

This blog post explains why it is essential to automate certificate management and provides a taxonomy of certificate use cases to help you identify certificates you need to manage. 

Why the Change? 

Salesforce CTO of Security, Taher Elgamal, often called the “Father of SSL,” views the shortening of certificate lifespans not just as a technical requirement, but as a necessary shift toward automated security and stricter enforcement. Over the decades, he has observed that the manual process of renewing certificates is a primary reason for security and availability issues. The solution is not simply to remember to renew more often, but to implement systems where certificate updates are seamless; automation is key.

Certificates provide essential server authentication and session encryption, underpinning secure HTTP (HTTPS) and other protocols. A stolen key can be used to impersonate legitimate websites, decrypt intercepted traffic, or perform sophisticated data manipulation. With shorter lifespans, if a certificate is compromised, the window of opportunity for an attacker is drastically smaller. But for the teams managing these connections, this shift transforms a yearly maintenance chore into a constant operational burden.

To mitigate the risks posed by compromised keys, there is an industry-wide move to reduce the lifespan of public TLS certificates. The industry is shifting to lower certificate validity periods, as low as 45 or 47 days. This can realistically only be supported with automation.

Consider the math: If you manage 50 distinct integrations and certificate lifespans drop to 45 days, your team isn’t doing 50 updates a year anymore. They are doing 400.

If you rely on manual spreadsheets and email alerts, you are statistically guaranteed to miss one. And when a certificate expires, business stops. An API integration fails silently, an automated process crashes, or users cannot access critical services because their browsers block access to your web site with an expired certificate.

When it comes to Root Certificate Management, Salesforce guidance is to make sure you trust the Mozilla Rootset of which multiple CA vendors are a part of. Trusting this list will ensure you will be able to maintain one way inbound TLS connections to Salesforce.

Understanding Certificates in Salesforce

In Salesforce, certificates are used for two general purposes: Identity and Transport Protection. Identity authentication proves who you are. Transport Protection functions as the handshake and encryption between systems. Whether it’s an inbound user or outbound Apex, these ensure the pipe is secure.

Each way of using a certificate has context that makes it special. There are no generic answers to, generic “will my Salesforce work”, types of questions. A question must target a use case, so that the underlying dependencies can be clearly understood. Some use cases use the certificates for TLS/SSL and some use them in application layer signing and verification. In certain cases, such as Inbound One-Way TLS, Salesforce handles the heavy lifting of rotating certificates for you. In other cases, particularly Mutual TLS (mTLS), you manage certificates. For example, in Outbound Apex mTLS, your code explicitly calls a specific client certificate. Salesforce does not rotate these for you. If this certificate expires every 45 days in the future, and you don’t have a plan, your Apex callouts will fail.

A crucial consideration for customers is the restriction of Enhanced Key Usage (EKU) by removal of “Client Authentication” from public TLS/SSL certificates, restricting them strictly to “Server Authentication” to enhance security. Therefore, customers must update their client certificates or update authentication systems to support server-only certificates.

The table below provides an overview of what Salesforce manages, and what you are responsible for. 

	Salesforce Managed	Customer Managed
Transport Protection
Inbound One-Way TLS	Salesforce handles certificate rotation, unless you are using Bring Your Own Certificate.	If you are using Bring Your Own Certificate (BYOC).
Outbound Apex One-Way TLS		Salesforce does not rotate the 3rd party server certificate. There are no client authentication EKU issues here.
Identity (Authentication)
Inbound User mTLS	Salesforce handles the server certificate rotation, unless you are using BYOC.	You must rotate the client certificate. The customer will need to verify the ongoing availability of the client authentication EKU.
Inbound API mTLS	Salesforce handles the server certificate rotation, unless you are using BYOC.	You must rotate the client certificate. The customer will need to verify the ongoing availability of the client authentication EKU.
Outbound Apex mTLS	Salesforce maintains a valid list of trusted root CAs. The server you call must chain to one of these.	Salesforce does not rotate either certificate. The customer must verify the ongoing availability of the client authentication EKU.
Inbound/Outbound SSO		Salesforce does not rotate this certificate for the customer.

Technicalities and Taxonomy

There are two key concepts that are always worth understanding and differentiating.

First, the prover presents a digital certificate or uses a private key to sign data to prove their identity or verify that they performed a specific action. Second, the verifier trusts the 

certificate to validate the assertion made by the prover. Often the thing trusted is NOT the certificate implicitly, but an authoritative parent, called a Certificate Authority (CA), or a grandparent, CA (root CA), that issues and digitally signs certificates. 

For TLS/SSL the parent model, using what is called a chain of CAs, is the most common. For SSO technologies, like SAML and OIDC/JWT, the certificates are most often explicitly trusted and no CA or chain is involved. 

Practitioner Tip: For SAML and OIDC/JWT, to avoid disruption due to frequent certificate updates, a self-signed certificate with a long lifetime is commonly used (see OWASP Cheat Sheet). Trust is established via direct metadata exchange between the prover and verifier rather than a Certificate Authority (CA).

All directions in the use cases are relative to Salesforce, so inbound is from the customer to Salesforce. 

Transport Protection

• Inbound One-Way TLS: This is your most standard type of TLS call, like getting the page www.salesforce.com. The security association is one direction. The caller is trusting Salesforce, but Salesforce knows nothing meaningful about the caller. Salesforce will offer up a Public WebPKI certificate per this support document. The caller must trust the right root CA certificate per the document. PCs and mobiles have a trust store that contains root CAs, like G2. Unless your InfoSec team curates this, which is not common, your systems will already trust G2, which has been commonly used for many years. For other connections, like APIs, it is more common to curate that store, so checking here is a MUST. That root must be trusted. Nonetheless, we strongly recommend you do NOT trust only the G2 root, but instead trust the entire Mozilla TLS Server trust store, per this article.

Additional context: The call may include application layer authentication data, but that has nothing to do with the TLS certificate involved.

• Outbound Apex One-Way TLS: The customer’s application may make calls out from Salesforce to some 3rd party server, usually to call APIs to get or set data. In the case of one way outbound TLS, the server that is called must be trusted by Salesforce and send the servers chain. It must chain to one of the root CAs listed in the cacerts.jsp page. This page can vary per instance and is at the same relative path on each instance, e.g. https://gus.my.salesforce.com/cacerts.jsp

Additional context: Due to the shared nature of SaaS, Salesforce can’t trust private PKI.

Identity (Authentication)

• Inbound User mTLS: In this case, the user must validate the Salesforce server and certificate just like in the Inbound One-Way TLS use case. In addition, the user offers up a client certificate that is used to authenticate the user to Salesforce. This uses mutual TLS (mTLS). mTLS, if successful, passes the certificate to the application layer to complete application level authentication. It is possible for a certificate to satisfy mTLS, but not authorize any user, blocking application layer access. After satisfying the server authentication portion of TLS, the user must complete the client half. To satisfy the client half of mTLS, the first step of the user’s authentication, the user must offer up a client certificate that:
  • has the Client Authentication EKU
  • chains to one of the root CAs listed in the cacerts.jsp page. This page can vary per instance and is at the same relative path on each instance, e.g. https://gus.my.salesforce.com/cacerts.jsp
  • sends the chain, not just the client certificate
  • is mapped to the user account

Additional context: This is user based authentication to the UI only, not used for API access. Help articles are available here. The client certificate is mapped to the user’s account.

• Inbound API mTLS: In this case, the calling application must validate the Salesforce server and certificate just like in the Inbound One-Way TLS use case. In addition, the application offers up a client certificate that is used to authenticate the user to Salesforce. This uses mutual TLS (mTLS). mTLS, if successful, passes the certificate to the application layer to complete application level authentication. It is possible for a certificate to satisfy mTLS, but not authorize the calling application, blocking application layer access. After satisfying the server authentication portion of TLS, the application must complete the client half. To satisfy the client half of mTLS, the first step of the application’s authentication, the application must offer up a client certificate that:
  • has the Client Authentication EKU
  • chains to one of the root CAs listed in the cacerts.jsp page. This page can vary per instance and is at the same relative path on each instance, e.g. https://gus.my.salesforce.com/cacerts.jsp 
  • sends the chain, not just the client certificate
  • is set in the Mutual Authentication page 

Additional context: This is API/application based authentication to the API layer only. Documentation can be found here. The application’s client certificate is pinned to the Mutual Authentication list.

• Outbound Apex mTLS: The customer’s code makes calls out from Salesforce to some 3rd party server, usually to call APIs to get or set data. In this case, the 3rd party server requires mutual authentication (mTLS). The same rules as in Outbound Apex One-Way TLS, apply to the call validating the 3rd party server certificate. Then the Apex code must present the client certificate to the 3rd party server. This can be pragmatic to understand and troubleshoot, as Salesforce has no way of knowing what the server requires from the client certificate. Only the 3rd party server operator can verify this. However, Salesforce can use certificates from private PKI for this outbound connection, as it is limited to the customer only. The server may or may not require the chain be sent, but if the customer includes the chain with their certificate in Certificate and Key Management, then it will be sent. 

Additional Context: The Apex code explicitly calls the certificate by name in code, like this. The Salesforce app or org must have the client certificate and private key.

• Outbound SSO: For both SAML and OIDC/JWT based SSO or login flows, a system that is authoritative for the identity that is logging-in signs a piece of data that contains information about the identity. These are often called identity claims of assertions. When certificates are involved, the private key is used to sign the data. This means that in Salesforce, to allow your org to authenticate its users to some other org or system, you need a certificate and private key. 

Additional Context: This is application layer data that is signed, XML in the case of SAML and JSON in the case of OIDC/JWT. The application layer data is passed over TLS, but the certificates for that are not discussed here are just one way TLS communications. This help article is for making your organization a SAML IdP.

• Inbound SSO: For both SAML and OIDC/JWT based SSO or login flows, inbound, where your system trusts an identity provider (IdP), (See Outbound SSO), your system is set to explicitly trust their certificate. This means you don’t need the private key. Only the IdP has that. On the inbound side, the signatures are verified against an explicitly trusted certificate, so no chain is involved. Assume the signed data is correct, login works. 

Additional Context: This is application layer data that is signed, XML in the case of SAML and JSON in the case of OID/JWT. The application layer data is passed over TLS, but the certificates for that are not discussed here are just one way TLS communications.

Call to Action

To navigate this transition without disruption, use the above taxonomy to help identify your owned certificates and verify connectivity. To identify certificates you manage, first check all systems that connect to your Salesforce instance via Inbound One-Way TLS. Second, check all Inbound API mTLS and Outbound Apex mTLS integrations. For each instance, confirm that The Mozilla Rootset is in the trust store of the calling system. 

To verify connectivity, first address the Client Authentication EKU restriction by using mTLS client certificates sourced from a private PKI/CA. If using a public CA, update the system to support a server-only certificate or to use an alternative authentication method. Then complete the certificate rotation and update process in a Sandbox environment, testing all user logins and Apex execution.

Finally, move away from manual certificate management. Explore Bring Your Own Certificate (BYOC) features or API-based rotation to handle shorter lifecycles without human intervention.