Salesforce Certificate and Key Pair
A Salesforce Certificate and Key Pair is a cryptographic credential made up of a public certificate and a matching private key, both created and stored inside your org under Setup, in Certificate and Key Management.
Definition
A Salesforce Certificate and Key Pair is a cryptographic credential made up of a public certificate and a matching private key, both created and stored inside your org under Setup, in Certificate and Key Management. The certificate proves that a message, a SAML assertion, or a TLS connection genuinely came from your Salesforce org, while the private key stays protected so no one else can forge that proof.
You use these credentials to sign single sign-on assertions, to authenticate outbound API callouts over mutual TLS, and to validate inbound API clients. Salesforce can generate a self-signed certificate for you, or you can upload one signed by a certificate authority. Either way, the private key never has to leave the platform unless you explicitly mark it as exportable.
How certificates and keys hold your integrations together
Self-signed versus CA-signed certificates
Salesforce gives you two ways to obtain a certificate. A self-signed certificate is generated by your org and signed by Salesforce itself. It is enough to show that traffic claiming to come from your org really does, and it works well for internal trust between systems you control. You create one from the Certificate and Key Management page in a few clicks, with no external party involved. A certificate-authority-signed certificate is more authoritative because a trusted third party vouches for it. You start by generating a certificate in Salesforce, download the certificate signing request, hand it to your CA, then import the signed file back into the same record. External partners that require a recognized chain of trust usually expect this kind of certificate. The trade-off is cost and a renewal process that depends on the CA. Pick the type that matches who needs to trust the connection and how strict their validation is.
Key size and certificate lifetime
When you generate a certificate, you choose a key size, and that choice is permanent. After you save a certificate, you cannot change its type or its key size, so the decision deserves a moment of thought. The size controls both how strong the key is and how long the certificate stays valid. Certificates with 2048-bit and 3072-bit keys are valid for one year and run faster during the TLS handshake. Certificates with 4096-bit keys are valid for two years and trade a little speed for a longer life and stronger protection. Shield Platform Encryption Bring Your Own Key setups require a 4096-bit RSA certificate, so that path has no choice to make. For everyday signing and callouts, a 2048-bit or 3072-bit key is usually fine. If you want fewer renewals and stronger keys, the 4096-bit option is reasonable. Whatever you pick, write down the expiration date, because a lapsed certificate silently breaks every integration that depends on it.
Signing SAML assertions and acting as an identity provider
When your org acts as a SAML identity provider for single sign-on, it signs each assertion it sends to service providers. That signature is created with the private key of a certificate you select in the identity provider settings. The service provider holds the matching public certificate and uses it to confirm the assertion was not tampered with and really came from your org. This is where certificate hygiene becomes visible to end users. If the signing certificate expires or you swap it without updating the service provider, logins start failing for everyone who relies on that SSO connection. Salesforce lets you keep more than one certificate on hand, so you can stage a replacement, share the new public certificate with the service provider, and cut over with little disruption. The same signing model applies when you configure SAML for inbound single sign-on and need a certificate to validate signed requests from your identity provider.
Mutual authentication for inbound API clients
Standard TLS proves the server identity to the client. Mutual authentication, also called two-way TLS or mTLS, makes the client prove itself too. Salesforce supports this on inbound API connections to block impersonation, and it is meant for API traffic, not browser sessions. To set it up, you upload your client certificate on the Certificate and Key Management page, and that certificate must include the Client Authentication extended key usage. Your API client then connects to the org endpoint on port 8443, which requests a client certificate during the handshake. Enforcement is tied to a user permission. You assign Enforce SSL/TLS Mutual Authentication to an API-only user through a profile or permission set. When that user connects, Salesforce matches the presented client certificate against the uploaded one. A match grants access, and anything else is denied. This gives integration accounts a strong second factor at the transport layer.
Outbound callouts, named credentials, and exportable keys
Certificates also work in the outbound direction. When your org calls an external system that demands a client certificate, you reference a Salesforce certificate as the client identity for that callout. Named credentials are the cleanest place to wire this up, because they hold the endpoint and the certificate together and keep the secret out of your code. Apex callouts and external services can then connect over mutual TLS without anyone managing keys by hand. The Exportable Private Key option, chosen at creation time, controls whether you can ever take the private key out of Salesforce. Leave it off and the key stays locked inside the platform, which is the safer default. Turn it on only when an external server genuinely needs the same key in its own keystore. You can export certificates and keys into a Java KeyStore file in JKS format, and on import the name of each private key entry becomes the developer name you reference from Apex or the Metadata API.
Managing certificates over their whole life
Certificates are not set-and-forget. Every one has an expiration date, and the failure mode is an outage that arrives without warning when a key quietly expires. Mature orgs treat certificate management as an ongoing task. They keep a list of which certificate backs which integration, track each expiration date, and schedule renewals well ahead of the deadline. Salesforce helps with this through expiration notifications, which you can route to the right people so a renewal never sneaks up on you. Because the platform lets you store several certificates at once, you can create the replacement early, distribute its public half to partners, and switch over on your own schedule rather than during an emergency. Treat the private key like any other production secret. Restrict who can manage these records, avoid exportable keys unless you truly need them, and document the rotation steps so the next person can repeat them calmly instead of scrambling when something breaks.
Create a self-signed certificate and key pair
Generate a self-signed certificate and key pair in your org so you can sign assertions or authenticate callouts. From Setup, open Certificate and Key Management, then choose Create Self-Signed Certificate.
- Open Certificate and Key Management
In Setup, type Certificate and Key Management in Quick Find and open the page. Click Create Self-Signed Certificate to start a new certificate record.
- Name the certificate
Enter a Label that humans will recognize. The Unique Name fills in automatically and becomes the API name that Apex, named credentials, and the Metadata API use to reference this certificate.
- Choose the key size
Pick 2048 or 3072 bit for a one-year certificate, or 4096 bit for a two-year certificate. Remember that you cannot change the key size after you save.
- Decide on key export
Leave Exportable Private Key unchecked to keep the key locked inside Salesforce. Check it only if an external system must hold the same private key in its own keystore.
- Save and put it to work
Save the record. Salesforce generates the pair and you can now select this certificate in SAML settings, identity provider config, named credentials, or callout setup, and download the public certificate to share.
A readable display name for the certificate shown across Setup.
The API name, auto-derived from the label, used to reference the certificate in code and metadata.
The strength of the key, either 2048, 3072, or 4096 bit, fixed once the record is saved.
A checkbox that decides whether the private key can ever be exported from the org.
- You cannot change a certificate type or key size after saving, so a wrong choice means creating a new certificate and reconfiguring everything that referenced the old one.
- A 2048-bit or 3072-bit certificate expires after one year and a 4096-bit certificate after two years; an expired certificate breaks every integration that uses it.
- Enabling Exportable Private Key weakens your security posture, because the secret can then leave the platform; leave it off unless an external keystore truly needs the key.
- Shield Platform Encryption Bring Your Own Key requires a 4096-bit RSA certificate, so a smaller key will not work for that use case.
Trust & references
Cross-checked against the following references.
- Certificates and KeysSalesforce
- Generate a Self-Signed CertificateSalesforce
Straight from the source - Salesforce's reference material on Salesforce Certificate and Key Pair.
- Certificates and KeysSalesforce
- Certificate, Metadata API Developer GuideSalesforce
Hands-on resources to go deeper on Salesforce Certificate and Key Pair.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is a Salesforce Certificate and Key Pair?
Q2. What scenarios use certificates?
Q3. What's a critical management task?
Discussion
Loading discussion…