Salesforce Certificate Trust Store: Your Own Root CAs, for Named Credentials Only

TL;DR

• Winter '27 adds a Certificate Trust Store in Setup. You can list, upload, download and delete your own root certificates from one page.
• Up to 50 non-expired certificates per org, and Salesforce emails admins 60, 30 and 10 days before any of them expires.
• The scope is the headline, and it is narrow. The trust store supports Named Credentials integrations only. Every other external connection still relies on the global, Salesforce-managed trust store.
• Alongside it, named credentials can now reach servers whose certificates are signed by a private or internal CA. Those callouts previously failed outright.
• Requires the Manage Certificates permission, which is worth deciding deliberately, because whoever holds it decides what your org trusts.

What You'll Learn

• Why a private CA certificate broke a named credential before this release, and where in the request it broke
• What the Named-Credentials-only scope does and does not cover
• How the expiry notifications change who needs to care about certificate lifecycles
• What to do about the 50 certificate ceiling before you hit it

The Problem

If your organisation runs its own certificate authority, Salesforce has been an awkward place to integrate with your own systems.

Plenty of enterprises do run one. Finance, payments, health and anything with a compliance regime attached frequently operate an internal PKI and sign server certificates with a private CA. Those certificates are valid, they are trusted across the internal network, and every other system in the estate accepts them without comment.

Salesforce did not. A named credential calling an endpoint whose certificate chained to a private root got a failure, because Salesforce only trusted the roots in its own global store. The workaround was usually a public certificate obtained specifically so Salesforce would talk to a system that already had a perfectly good certificate, which is a purchase order to solve a trust problem.

The detail that made this hard to diagnose is where it broke. The TLS handshake happens before any application-level authentication, so the failure landed before the named credential's own configuration was ever exercised. Nothing about the credential was wrong, which is exactly why people spent time checking it.

Common questions this article answers:

• Why did my named credential fail against a server with a valid internal certificate?
• Does the trust store cover all my callouts, or only some of them?
• Who should hold the Manage Certificates permission?

Quick Answer

Winter '27 adds a Certificate Trust Store, reachable from Setup by searching for Certificate Trust Store, where an org can list, upload, download and delete its own root certificates. The limit is 50 non-expired certificates, and Salesforce emails admins 60, 30 and 10 days before any certificate expires. Managing the store requires the Manage Certificates user permission. The scope is the part that decides whether this helps you: the Certificate Trust Store supports Named Credentials integrations only, and all other external connections continue to use the global Salesforce-managed trust store, so this is not a general-purpose trust configuration for the org. The companion change is that named credentials can now establish connections to servers whose certificates are signed by a private or internal CA. Previously those callouts failed at the TLS handshake, before any application-level authentication ran, which is why the failure never pointed at the certificate chain.

Where the failure actually happened

The ordering here explains why this was such a time sink.

A named credential callout has two distinct stages that people tend to collapse into one. First the transport is established: TLS negotiates, the server presents its certificate, and the client decides whether that certificate chains to a root it trusts. Only then does anything application-level happen, including whatever authentication the named credential is configured for.

A private CA certificate failed at the first stage. The named credential never got as far as presenting a token or a client certificate or a username, because there was no trusted transport to present them over. So the symptom was a connection failure with nothing in it about authentication, on a credential whose authentication configuration was entirely correct.

That ordering is why the usual debugging path went nowhere. Checking the credential, rotating the secret, and confirming the endpoint were all reasonable steps that could not have found it.

The scope, which is the thing to read twice

Salesforce is explicit: the Certificate Trust Store supports Named Credentials integrations only. All other external connections rely on root certificates in the global, Salesforce-managed trust store.

That sentence rules out more than it might appear to. It is not an org-wide trust configuration. If you have callouts that do not go through a named credential, they are unaffected by anything you upload here. The same is true of other outbound connections the platform makes on your behalf.

This is a reasonable design choice and a limitation worth planning around. Named credentials are the sanctioned way to make an authenticated callout, so scoping a trust change to them keeps the blast radius of a bad certificate small. But if your estate still has callouts built before named credentials became the default pattern, this release gives you a second reason to migrate them, on top of the reasons in Migrating legacy Named Credentials.

Fifty certificates, and expiry emails

Two operational details that will shape how you use this.

The ceiling is 50 non-expired certificates. For most orgs that is generous, since a root CA count in single digits is normal. It becomes a real constraint if you are tempted to upload intermediates or leaf certificates alongside roots, so keep the store to roots and let the chain do its job.

Expiry notification at 60, 30 and 10 days is more useful than it sounds. Certificate expiry is one of the classic causes of an integration failing at three in the morning with no deployment to blame. Getting three warnings by email moves that from an incident into a task. It also quietly changes who needs to know: the emails go to admins, so your Salesforce administrators now hold a piece of the certificate lifecycle that previously lived entirely with whoever runs the PKI. Decide who acts on those emails before the first one arrives.

Who gets Manage Certificates

Uploading a root certificate is a trust decision. Anyone who can add a root to the store can cause the org to accept a certificate chain it would otherwise reject, so the permission deserves the same care as any other permission that changes what the platform believes.

Salesforce requires the Manage Certificates user permission to upload and manage root certificates. Grant it through a permission set assigned to named people, keep it off profiles, and treat an addition to the trust store as a reviewable change in whatever system of record you use for security configuration.

The audit question worth answering now, before the store has anything in it, is who would notice if a certificate appeared there.

Frequently Asked Questions

Q: Does this mean Salesforce now trusts anything I upload?

A: For named credential callouts, yes, and that is the point. Uploading a root means your org accepts server certificates that chain to it. That is why the permission matters and why the store deserves review. For everything else, the global Salesforce-managed store still applies and your uploads have no effect.

Q: We do not run our own CA. Is there anything here for us?

A: The expiry notifications are still worth knowing about if you ever upload anything, but if all your endpoints use publicly trusted certificates then the global store already covers you and this release changes nothing for your integrations. Filing it as read is a reasonable outcome.

Q: Will this fix a callout that is failing today?

A: Only if it is failing because of the certificate chain, which is narrower than most connection failures. The signature is a transport-level failure against an endpoint whose certificate is signed by an internal or private CA, with a named credential whose own configuration checks out. If the failure mentions authentication, authorisation or an HTTP status code, the handshake succeeded and this is not your problem.

Q: Can we use this for mutual TLS client certificates?

A: That is a different mechanism. This store holds root certificates so the org can validate what the server presents. Client certificates that Salesforce presents to a server are configured separately, and nothing here changes that side of the exchange.

Q: Is this available in every edition?

A: The Certificate Trust Store is documented for Lightning Experience in Enterprise, Performance, Unlimited and Developer editions. The named credential support for custom CA certificates is documented for Lightning Experience and Salesforce Classic across the same editions, with a note that it is not available in all orgs, so confirm in your own Setup before planning around it.

Key Takeaways

• The Certificate Trust Store holds your own root certificates, managed from one Setup page, up to 50 non-expired.
• Named Credentials only. Every other external connection still uses the global Salesforce-managed store, so this is not org-wide trust configuration.
• Private CA callouts now work, where previously they failed at the TLS handshake before any authentication ran.
• That handshake ordering is why the old failure was hard to diagnose, and it is the fastest way to recognise the symptom.
• Expiry emails at 60, 30 and 10 days hand your Salesforce admins a piece of the certificate lifecycle. Decide who owns that before the first email.

What's Next?

If you have integrations that were given a public certificate purely so Salesforce would accept them, those are now candidates for going back to your internal PKI, which is one fewer external dependency and one fewer renewal to pay for.

Decide who holds Manage Certificates before anyone needs it, because the alternative is deciding it under pressure when a handshake is failing.

If your estate still has legacy named credentials, this release adds to the case for moving them, covered in Migrating legacy Named Credentials. For everything else Winter '27 carries, including the changes that are enforced rather than optional, see Salesforce Winter '27 Security Readiness.

Resources & References

• Salesforce Winter '27 Release Notes, Security, Identity, and Privacy section, in Salesforce Help.
• Setup, then Certificate Trust Store, for the store itself once your org is on Winter '27.
• Migrating legacy Named Credentials for moving older callout configuration onto the current model.
• Salesforce Winter '27 Security Readiness for the release as a whole.