Loading

Salesforce requires Public CA-signed certificates for mutual authentication (mTLS) and how the platform validates these certificates.

Data pubblicazione: Sep 8, 2026
Descrizione

Why Salesforce Requires Public CA-Signed Certificates for mTLS

Salesforce uses Port 8443 specifically for mutual TLS (mTLS) handshakes. To maintain a high security posture and ensure seamless connectivity, Salesforce's infrastructure is pre-configured to trust only Public Certificate Authorities (CAs), such as GoDaddy or DigiCert.

If a client attempts to connect using a certificate signed by a Private or Internal CA, the Salesforce gateway does not recognize the signature. This results in the connection being terminated before it reaches user-level security settings.

Does Salesforce Support Private CA-Signed Certificates for mTLS?

No. Salesforce does not support the use of Private CA-signed client certificates for mTLS or certificate-based user authentication.

  • Security Best Practices: Per Salesforce PKI (Public Key Infrastructure) policy, trusting private CAs or custom CA bundles outside of the Salesforce-managed trust store is considered high risk.
  • Platform Policy: mTLS client authentication relies exclusively on Salesforce-managed or publicly trusted Certificate Authorities. There is currently no supported mechanism to trust arbitrary private CAs.

Why Does Any Public CA-Signed Certificate Seem to Work During Initial Testing?

This behavior is by design. Salesforce's mTLS implementation follows these steps during the handshake:

  1. Handshake Requirement: The gateway requires a client certificate to be presented.
  2. Chain Validation: It validates that the certificate is signed by a trusted public CA.
  3. Identity Binding: Salesforce does not use the certificate thumbprint as a primary security control or identity binder during the initial TLS handshake. The thumbprint is treated as structural metadata.

Can We Enable Selective Thumbprint Validation for Our Production Org?

No. Selective thumbprint checking cannot be enabled or disabled at the Org, User, or Environment level.

  • One-to-One Association: In Salesforce, a certificate is associated with exactly one account (whether an API integration user or a human user).
  • Enforcement: Enforcement is based on this unique one-to-one mapping rather than dynamic thumbprint validation during the handshake.

How to Set Up Mutual Authentication

To successfully implement mTLS, follow these required steps:

  1. Enable the Feature: Contact Salesforce Support to have Mutual Authentication enabled for your organization.
  2. Obtain a Public Certificate: Ensure your client certificate is signed by a Salesforce-trusted root CA.
  3. Upload the Certificate:
    • Navigate to Setup | Security | Certificate and Key Management.
    • Upload the signed certificate to the Mutual Authentication Certificates table.
  4. Assign Permissions:
    • Enable the "Enforce SSL/TLS Mutual Authentication" user permission for the target user.
    • This can be applied via a Profile or a Permission Set.
    • Note: This permission forces the user/client to use port 8443 for all secure connections.
Risoluzione

This article answers common questions about why Salesforce requires Public CA-signed certificates for mutual authentication (mTLS), and how the platform validates client certificates during the TLS handshake.

Summary

Salesforce does not support Private CA-signed certificates for mTLS, and thumbprint validation cannot be selectively enabled per org, user, or environment - each certificate maps to exactly one account, and validation happens against Salesforce's trusted public CA list during the handshake itself, not through custom trust configuration.

Numero articolo Knowledge

005314235

 
Caricamento
Salesforce Help | Article