Salesforce is making three changes to how TLS certificates are issued, renewed, and trusted across its platform. These changes primarily affect customers whose systems call the Salesforce API directly, such as custom ERP, PLM, EDI, or middleware integrations that connect straight to your Specright org on Salesforce. The Specright API is not impacted, and no Specright Platform functionality, data, or org configuration is changing as a result.
Does this apply to you?
You are not affected if you use Specright only through:
• The Specright web application
• Single sign-on (SSO)
• The Specright API
• Integrations built and managed by Specright
You may be affected if any of your systems connect directly to a Salesforce URL, meaning hostnames containing salesforce.com, force.com, or my.salesforce.com. Ask your IT or integration team to search integration and middleware configurations for these hostnames.
For each integration that does connect directly, ask three questions:
1. Does it use mutual TLS (a client certificate) to authenticate? If yes, see item 1.
2. Does it pin Salesforce's certificate or public key? If yes, see item 2.
3. Does it use a custom trust store rather than the system default? Common places to check are SAP STRUST, Java keystores (cacerts), and corporate proxies or firewalls that inspect TLS. If yes, see item 3.
If the answer to all three is no, no action is needed.
1. Dual-Use Certificates Are Being Retired — Action required if you use mTLS
The industry is ending support for dual-use certificates (a single public certificate used for both server and client authentication). Integrations that authenticate to Salesforce with mutual TLS (mTLS) using a dual-use certificate will be disrupted once the change takes effect. Browser vendors have adjusted their timelines, but Salesforce's guidance is to act now rather than wait.
What to do: Issue a separate, dedicated client certificate for each mTLS integration from a Salesforce-supported Certificate Authority, and confirm your mTLS configuration is compliant.
2. Shorter Certificate Lifespans — Reducing from 200 days to 47 days by March 2029
Salesforce is shortening the maximum lifespan of its TLS server certificates in step with industry security standards. Salesforce manages and rotates these certificates itself, so they will change more often than before.
What to do: No action is needed unless your integration pins Salesforce's certificate. If it does, remove the pinning so your integration keeps working as Salesforce rotates its certificates.
3. Root Certificates and Trust Stores
Salesforce may change Root Certificate Authority providers, or use several providers at once, for services your systems connect to over one-way inbound TLS.
What to do: Configure your trust stores to trust the full Mozilla Root CA set rather than a single root or intermediate certificate.
Not affected: Self-signed certificates and certificates signed by a custom (private) CA are unaffected. Single sign-on (SSO) is also not affected: Specright SSO uses self-signed certificates, which fall outside these changes, so no updates to your identity provider (Okta, Azure AD/Entra ID, etc.) are required. MuleSoft users should review the MuleSoft Help article for platform-specific guidance.
Salesforce webinars: Salesforce is hosting informational sessions for engineering and security teams on October 15, 2026. Register for the session that works best for your team:
• 09:00 UTC
• 15:00 UTC
• 23:00 UTC
Already completed these updates? No further action is required. For questions, help identifying whether any of your integrations call the Salesforce API directly, or support with certificate changes, please contact your Specright Customer Success contact or Specright Support. Full technical guidance is available in Salesforce's Certificates in Salesforce help article.