Certificate and Key Management
Certificate and Key Management is the Salesforce Setup page where administrators create, import, and manage X.509 certificates and cryptographic keys used by the org for SAML signing, OAuth JWT bea…
Definition
Certificate and Key Management is the Salesforce Setup page where administrators create, import, and manage X.509 certificates and cryptographic keys used by the org for SAML signing, OAuth JWT bearer authentication, mutual TLS callouts, encrypted callouts, and platform encryption key wrapping. Each certificate has a label, a unique name, a key size (1024 or 2048 bit RSA, plus ECC options in newer versions), an expiration date, and a usage context (Self-Signed for SAML SP, CA-Signed for production, Connected App JWT, mutual TLS). The page is the central inventory of cryptographic identity material the org uses to prove itself to other systems.
Certificate and Key Management is one of the lower-traffic Setup pages but holds material that directly affects authentication, integration, and compliance. An expired certificate breaks the integration that depends on it; a leaked private key requires re-issuing and re-distributing certificates everywhere they are used. Most production orgs hold a dozen or more certificates accumulated over years; treating the page as a registry with active inventory management is the difference between predictable rotation and 3 AM emergency outage calls.
Why certificate expirations are the most reliable production-incident trigger
Where Certificate and Key Management lives and what it shows
Setup, Security, Certificate and Key Management. The page lists every certificate in the org with label, type, key size, expiration date, and usage. The Create Self-Signed Certificate button generates a new Salesforce-managed certificate; the Create CA-Signed Certificate button generates a Certificate Signing Request the customer submits to their CA (DigiCert, Sectigo, internal PKI). Imported certificates (from external systems) appear with their original metadata. Click into a certificate to download the public key, view the certificate chain, or schedule it for replacement.
Self-signed vs CA-signed and the trust question
Self-signed certificates are generated by Salesforce and trusted only by systems that explicitly load the public key. Useful for SAML SP signing (the IdP loads the SP cert manually anyway), OAuth JWT (Connected Apps load the cert directly), internal mutual TLS. CA-signed certificates are signed by a trusted Certificate Authority and trusted by any system that trusts the CA. Required for any callout to systems that verify the certificate chain (production-grade mutual TLS, some external APIs that require trusted client certs). Most orgs run a mix; self-signed for SAML and JWT, CA-signed for production mutual TLS.
Key sizes and the algorithm choice
Salesforce supports RSA 2048-bit (the modern default), RSA 1024-bit (deprecated; some legacy integrations still require it), and ECC P-256 and P-384 (the newer elliptic curve options, supported in recent platform versions). RSA 2048 is the safe default for almost every use case. RSA 1024 should be phased out; it is increasingly weak by modern crypto standards. ECC is more efficient for performance-critical scenarios but less broadly compatible with older external systems. Pick RSA 2048 unless an integration explicitly requires otherwise.
Expiration and the rotation cadence
Every certificate has an expiration date (typically 1, 2, or 3 years from issue). When the certificate expires, every integration depending on it breaks. Salesforce does not auto-rotate; the admin must generate a new certificate, distribute it to consuming systems, switch the configuration to use the new certificate, then deactivate the old. The rotation timeline is significant; for SAML and OAuth, plan 4 to 8 weeks of overlap so consuming systems can switch on their schedule. The most common production incident pattern in this category: certificate expired, no one noticed, integration broke at midnight, oncall scrambled at 3 AM.
Use cases: SAML, JWT, mutual TLS, encrypted callouts
SAML uses the certificate as the SP (Service Provider) signing certificate; the IdP verifies SAML assertions against the SP public key. OAuth JWT bearer flow uses the certificate for Connected App authentication; the external system loads the SP public key and verifies signed JWTs. Mutual TLS uses the certificate as the client certificate Salesforce presents on outbound callouts; the receiving system verifies the cert chain. Encrypted callouts use the certificate to sign the request payload. Each use case binds the certificate to a specific configuration (SAML SSO Setup, Connected App, Named Credential); the binding determines which integrations break when the cert is rotated.
The rotation playbook
Rotating a certificate is a coordinated multi-step process. Generate the new certificate in Salesforce. Download the new public key. Distribute to every consuming system (IdP for SAML, external API owner for JWT, partner for mutual TLS). Schedule a cutover date with each consumer. Switch the Salesforce configuration to use the new certificate on the cutover date. Verify integrations work with the new certificate. Deactivate the old certificate after a safety period (1 to 2 weeks). The playbook is the same for every rotation; documenting it once and following it every time is the difference between clean rotation and incidents.
Inventory management and the registry discipline
The Certificate and Key Management page is the inventory; maintaining the registry around it is the operational discipline. For each certificate: label, expiration date, usage (which SAML config, which Connected App, which Named Credential), owner (which team is responsible for the rotation), next review date. Most orgs do this poorly; certificates accumulate without ownership, expirations surprise the team. A spreadsheet that mirrors the page with owner and review date is sufficient; the format matters less than the discipline.
How to manage Certificate and Key Management without 3 AM outages
The successful pattern: inventory all certificates with ownership and review dates, alert on expirations 30 to 60 days out, follow a documented rotation playbook every time. The failed pattern: discover certificate expirations from integration failures and improvise the rotation under time pressure.
- Inventory every certificate in the org
Setup, Certificate and Key Management. Document each: label, usage, expiration date, owner team. Save the inventory in a shared spreadsheet or ticketing system.
- Build alerts for expirations 30 to 60 days out
Schedule a Report that queries Certificate metadata (or a periodic Flow that queries Certificate) and posts to Slack or email when expirations approach.
- Document the rotation playbook
Generate new cert, download public key, distribute to consumers, schedule cutover, switch Salesforce config, verify, deactivate old. The same playbook works for every rotation.
- Plan 4 to 8 weeks lead time per rotation
External consumers (IdP, partner APIs) need lead time to switch on their schedule. Skipping the lead time forces rushed cutovers that fail.
- Test the rotation in sandbox first
Generate a sandbox certificate, switch the sandbox SAML or Connected App config, verify the integration works. The sandbox dress rehearsal catches issues before production.
- Execute the production rotation per the playbook
Follow the same steps in production. Communicate the cutover to all consumers. Verify each integration post-cutover.
- Deactivate the old certificate after the safety period
1 to 2 weeks after the new cert is in use, deactivate the old. Deactivation prevents the old cert from being accidentally re-used; do not delete (audit trail preservation).
Self-Signed (Salesforce-generated) or CA-Signed (signed by an external CA). Drives trust scope.
RSA 2048 (modern default), RSA 1024 (legacy), or ECC P-256/P-384 (modern efficient). Pick RSA 2048 unless required otherwise.
1, 2, or 3 years typically. Longer reduces rotation frequency; shorter improves security posture.
SAML SP, Connected App JWT, mutual TLS, encrypted callouts. Drives which integrations depend on the certificate.
The team responsible for rotation. Required for the inventory registry; without it, certificates become orphaned.
- Salesforce does not auto-rotate certificates. Expirations break integrations; the admin must rotate manually with lead time.
- External consumers need 4 to 8 weeks lead time to switch on their schedule. Skipping the lead time forces rushed cutovers that fail.
- RSA 1024 is deprecated. Legacy integrations may still require it but phase out as the integration partners support stronger crypto.
- Deleting a certificate removes the audit trail. Deactivate instead of delete; keep the historical record for compliance.
- Self-signed certs are trusted only by systems that load the public key. CA-signed certs are trusted by any system that trusts the CA. Pick the right type for the consumer.
Trust & references
Cross-checked against the following references.
- Certificate and Key Management referenceSalesforce
- Salesforce security overviewSalesforce
Straight from the source - Salesforce's reference material on Certificate and Key Management.
- Certificate and Key ManagementSalesforce Help
- Create Self-Signed CertificatesSalesforce Help
- Create CA-Signed CertificatesSalesforce Help
Hands-on resources to go deeper on Certificate and Key Management.
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. In which area of Salesforce would you typically find Certificate and Key Management?
Q2. Why is understanding Certificate and Key Management important for Salesforce admins?
Q3. Can a Salesforce admin configure Certificate and Key Management without writing code?
Discussion
Loading discussion…