Salesforce Dictionary - Free Salesforce GlossarySalesforce Dictionary
Full Certificate and Key Management entry
How-to guide

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.

By Dipojjal Chakrabarti · Founder & Editor, Salesforce DictionaryLast updated May 18, 2026

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. Execute the production rotation per the playbook

    Follow the same steps in production. Communicate the cutover to all consumers. Verify each integration post-cutover.

  7. 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).

Certificate typeremember

Self-Signed (Salesforce-generated) or CA-Signed (signed by an external CA). Drives trust scope.

Key algorithm and sizeremember

RSA 2048 (modern default), RSA 1024 (legacy), or ECC P-256/P-384 (modern efficient). Pick RSA 2048 unless required otherwise.

Expiration durationremember

1, 2, or 3 years typically. Longer reduces rotation frequency; shorter improves security posture.

Usage contextremember

SAML SP, Connected App JWT, mutual TLS, encrypted callouts. Drives which integrations depend on the certificate.

Owner teamremember

The team responsible for rotation. Required for the inventory registry; without it, certificates become orphaned.

Gotchas
  • 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.

See the full Certificate and Key Management entry

Certificate and Key Management includes the definition, worked example, deep dive, related terms, and a quiz.