#Security109 debatiendo

Can anyone provide more details on exactly how and where the new Certificate Trust Store is used? 

The release notes suggest the Trust Store is intended to support adding additional root certificates to allow Named Credential callouts to endpoints signed by a private or internal CA not already in the global Salesforce-managed trust store. 

However, the help documentation indicates that the Trust Store is used for "for validating inbound TLS connections" (???), and also states "The Certificate Trust Store supports Named Credentials integrations only." 

The help text within a Winter 27 sandbox states it is used for "API calls and SSO": 

1) Where exactly is the new "Certificate Trust Store" used?  Is it Named Credentials only?  Is it with outbound TLS connections or inbound, too? 

2) It is also unclear if the new "Certificate Trust Store" replaces the global Salesforce-managed trust store, or if the Trust Store provides a means to add additional certificates.  In other words, customers should never need to upload public root certificates that are already present in the global Salesforce-managed trust store, customers only need to upload root certificates from a private or internal CA, right? 

Thanks! 

#Security

Today I have facing an issue, In my project we have some developer sandboxes. After sandbox refresh action completed, Currently we are unable to verify the email for the non admin users (users whom are not mentioned in the public group which can mentioned during sandbox refresh process). Means, Once sandbox refresh done, We unfreeze the active user and update his original email and that user have received the verification email with verification link. But during clicking the verification link, it's required login to confirm the email address. 

But you know, That user doesn't able to login into salesforce because the sandbox just refreshed and user doesn't have the access for the org, We actually ask the user to confirm the email for perform the "password reset" action for that user to enable the access for the org. 

So how to by pass this "Login required" behaviour and verify the email link as like previous from the email directly? 

Even I have disabled the Permission "

But still the behaviour is same, So anyone know how to fix/bypass this? 

Any help appriciated. 

Thanks, 

Mohanraj S 

Hey Community. 

I have what I thought was quite a simple requirement for a user permission.    

I have user a who is assigned a profile which provides read and view all for opportunities.  I have then assigned them to a permission set which provides all those profile users the ability to edit only 5 fields but on all record types.   

I then have a second permission set assigned only to this specific user which allows them to create and edit funding and legacy record type opportunities with full edit permission on all fields on those records types.   

However, they are still able to create opportunities of any record type and have full edit which we do not want.   

I have been researching this and the conclusion is that SF combines those permissions, taking the 'create and full edit' from one and 'all record types' from the other.  This does not make sense to me and I cannot believe that this is not achievable through permission sets. I feel as though I am missing something obvious. 

Does anyone have any suggestions on how to achieve this OOB.  

Many thanks 

Natalie Gorman 

We make outbound Apex callouts from a named credential to a vendor API. The vendor has moved that API onto a private cloud network, and our callouts now fail at the network layer before auth is ever evaluated. 

The only working solution we've found is for the vendor to allowlist Salesforce's published Hyperforce outbound ranges from https://ip-ranges.salesforce.com/ip-ranges.json (per KB 003876184, which explicitly recommends an IP allowlist for outbound Apex callouts since Salesforce outbound IPs may not resolve under *.salesforce.com). 

That works, but it has two drawbacks we'd like to avoid: the ranges are shared across all Salesforce tenants on that infrastructure, so it's a weak control rather than a real identity boundary and Salesforce advises allowlisting the entire file, which is a broad and evolving surface for the vendor's security team to accept. 

What I'm hoping someone has solved before-- 

1. Salesforce's stated preferred alternatives are mTLS and domain allowlisting, but both assume the far side is filtering at the application layer. When the block is network-level, a client certificate doesn't get you through the firewall. Has anyone actually used mTLS to solve a reachability problem rather than an auth one, or am I right that it's the wrong tool here?
2. Private Connect / Outbound Network Connection appears to be AWS PrivateLink only. Can anyone confirm whether Azure-hosted targets are supported, now or on the roadmap?
3. Is there any other mechanism to give an external endpoint a stable or narrower egress identity for Apex callouts?
4. For those who've hit this: did you end up putting a relay/gateway in front of the private service and pointing Salesforce at that instead? Would you recommend it?

Any experience appreciated, we have a go-live this week, so we're proceeding with the allowlist for now and looking for something more durable after. 

Articles that I have already read - 

1. https://help.salesforce.com/s/articleView?id=003876184&type=1

2. https://help.salesforce.com/s/articleView?id=000384438&type=1

#Salesforce Developer  #Architects  #Solution Architects  #TrailblazerCommunity  #Security  #Integration