function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

The client cert chain of API version 25.0 can't be validate successfully when using Outbound message


With latest API version 25.0 of, the downloaded client cert can't be validated successfully. After downloading the client cert, i generated the intermediate cert and root cert. The certs chain is something like:
Subject: CN =;
Issuer: CN = VeriSign Class 3 International Server CA - G3

Subject: CN = VeriSign Class 3 International Server CA - G3
Issuer: CN = VeriSign Class 3 Public Primary Certification Authority - G5

Subject: CN = VeriSign Class 3 Public Primary Certification Authority - G5
Issuer: CN = VeriSign Class 3 Public Primary Certification Authority - G5
Totally there are three certs. Then i put these three certs in a folder and set this folder as trusted certs location. In my outbound server, I use these certificates to verify the outbound client, that's at this time(two way SSL). Now the problem is, the certs sent doesn't math this cert chain. Could you tell me what kind of certs are sent by when the outbound server requires client authentication? Why the certs doesn't match?

Besides, my outbound server ran well with two way SSL when using API 22.0 and prior versions. I compared the client cert downloaded from Salesforce. The root and intermediate certs of 22 are different from version 25(I didn't tried with version 23 and 24, so i don't know is there any difference too). Is the change of this client cert temporary or decided?



Anyone can help ?


Hi zgcharley_09,


Can provide the URL of your endpoint in a private message? or email it to me? I work at Salesforce and can try to figure out where the point of failure maybe.




Hi Danny,


The trace log from my side shows:

------------------SSL handshake log-----------------


CertificateVerifier  --- looking in datastore for certificate with DN cn=VeriSign Class 3 Public Primary Certification Authority - G5,ou=(c) 2006 VeriSign, Inc. - For authorized use only,ou=VeriSign Trust Network,o=VeriSign, Inc.,c=US

CertificateVerifier  --- CA certificate with correct DN, but fingerprint '705E 6DBB 8824 1175 38BA F69F 6A2A 3606' found. Continuing search.
CertificateVerifier  --- No match found



It seems this certificate "cn=VeriSign Class 3 Public Primary Certification Authority - G5"  sent from has different fingerprint with the one present in my local. 


So currently, my question is how can I get the correct intermediate certificate "cn=VeriSign Class 3 Public Primary Certification Authority - G5" ? Shall I ask you( for the intermediate certificates of this client cert?






It seems like it's a different serial number, which is perfectly fine. It seems that your certificate verifier may be a bit too strict in this regard.

We should send the intermediate certificates when we send the client certificate, so if you can modify your certificate verifier code to save the intermediate certificates that we send to you in the callout to a file. These certificates can likely also be obtained from VeriSign's web site. As long as our intermediate chain validate againsts a mutually trusted VeriSign root, things are good from a trust perspective. There is no need to match the fingerprint or serial number.


Is that how you were doing it in previous versions?


Yes, the verification is strict in our side.  We do this cert verification since Salesforce Web Service API 10.0. There's no any problems for version 22.0 and its previous versions(We didn't have tests with 23 and 24, so we don't know is the change happened from that version). 


We can download the intermediate certs from Versign's web site. Can also provide a location for us to download the intermediate certs? Another question is, you know the client cert you provide will be expired in some time. Can you announce customer if the intermediate certs will be changed when renewing the client cert? I remembered that the intermediate certs of version 22.0 is different from current version(25.0).







The new certificate will be made available and communicated to customers in advance later this year. The new certificate will have a long-term expiration to minimize the number of times that customers go through the switchover process.

In the future, the platform may allow customers' managed certificates to be used for workflow outbound messaging and delegated authentication instead of using only our client certificate. No promises though... we are working to streamline this process.



Jia HuJia Hu
Sorry, but I don't understand why and how you generate the client cert into intermediate cert and root cert.

Would you kindly explain it with more details? Thanks ahead.