+ Start a Discussion
Manish GManish G 

Outbound messaging error - javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated

Hi All,
We are implementing Outbound messaging to one of our endpoint. The workflow is giving the following error :
 javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated.
What kind of Server certificates are supported by Outbound messaging. Can we import our certs in trusted store ?.
Any help is appreciated.
Steven LawranceSteven Lawrance
Hi Manish,

This exception unfortunately does not presently contain much information on how to troubleshoot it, but fortunately, I happen to know how to troubleshoot this. This exception message might be improved in the future, but I cannot make any guarantees.

Typical causes of this exception are one or more of the following:
  • The intermediate certificate chain is missing in your server's configuration
  • The certificate on your server is not signed by a publicly trusted certificate authority
  • The server certificate or an intermediate certificate on your server is expired
    • If you are load balancing in a pool of back-end servers, please ensure that these certificates are not expired on all back-end servers behind the load balancer
  • The certificate chain returned from your server is in an incorrect order
    • The order must be:
      1. Server certificate
      2. Intermediate certificate that signed the server certificate, assuming that your server's certificate was not signed directly by a root certificate
      3. Intermediate certificate that signed the intermediate certificate above, if applicable (some certificates have several levels of intermediate certificates)
      4. Repeat step 3 for any remaining intermediate certificates. Do not include the root certificate authority certificate
    • Note that the root certificate is not supposed to be sent by your server. Salesforce.com already has its own list of trusted certificates on file, and a certificate in the chain must be signed by one of those root certificate authority certificates. Typically, the last certificate in the chain is the one that was signed by one of the trusted root certificate authority certificates
Other things can go wrong, but the above are the typical things that happen. Note that web browsers typically include popular intermediate certificates, such as VeriSign's intermediate certificates, so your web site might work in a web browser but fail in Salesforce.com. Salesforce.com trusts only the root certificates and does not directly trust any intermediate certificates. Thus, for a server certificate that was signed by an intermediate certificate to be trusted by Salesforce.com, your server must include all intermediate certificates in its returned certificate chain, and one of those intermediate certificates -- preferably, the last one in the chain -- must be trusted by one of the root certificate authority certificates that Salesforce.com trusts.

OpenSSL is an invaluable tool to help diagnose SSL/TLS server issues. To use it, run OpenSSL's s_client tool to connect to your server and show the complete certificate chain. The issuer of at least one of the certificates presented in the chain -- typically, the last one -- must be one of the trusted certificate authority certificates listed on http://wiki.apexdevnet.com/index.php/Outbound_Messaging_SSL_CA_Certificates. If you see only one certificate, then your server is not sending its certificate chain (almost all certificate authorities have at least one intermediate certificate, so the case where only one certificate listed is correct is very rare. If you use VeriSign or GoDaddy, you must have intermediate certificates in your certificate chain for it to work with Salesforce.com).

openssl s_client -connect your.outbound.messaging.endpoint.server.com:443 -showcerts

Please feel free to compare your server's OpenSSL results with www.salesforce.com:

openssl s_client -connect www.salesforce.com:443 -showcerts

If you have a directory that contains trusted certificate authority certificates, then you can get more complete results from OpenSSL by adding the -CApath command line parameter and the path to that directory. With CApath specified, you should not see any errors at the top of the OpenSSL output. The "Verify return code" line at the bottom of the output should say "Verify return code: 0 (ok)"

openssl s_client -connect www.salesforce.com:443 -showcerts -CApath /etc/ssl/certs

Hopefully, this helps!

Steven Lawrance

Message Edited by Steven Lawrance on 06-19-2008 10:11 AM
Manish GManish G

Thanks Steve..really appreciate your response. I wish this information was posted by Salesforce.com themselves. I had to go through the SFDC Support to identify this solution.



Hi Folks,
Thanks for the informative post.  I am getting this error still and am at a loss as to why. I figured I'd keep this thread going. Here are some aspects of my configuration:
1) I am using a wildcard certificate. Does SF support these?
2) I have the server running under apache2  Does SF need any special settings?
3) A very similar apache configuration file successfully works with other SSL-based web services (QuickBooks Web Connector)

Does anyone have any ideas?

Steven LawranceSteven Lawrance
Hi Joe,

Sorry for the late response. I wrote answers to your questions below:

1) I am using a wildcard certificate. Does SF support these?

Salesforce.com supports wildcard certificates on the first level. Names such as *.hello.salesforce.com will permit hi.hello.salesforce.com, but not subdomains such as hey.hi.hello.salesforce.com.

2) I have the server running under apache2  Does SF need any special settings?

Apache2 will need to trust the root certificate that has the following subject DN: "C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority". Almost everything trusts this, but it's possible that SSLCACertificatePath or SSLCACertificateFile in your configuration does not include that certificate. Please ensure that it is included. If you are using SSLCACertificatePath, then you should have a symbolic link or file named 7651b327.0 that points to or contains the file with the "C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority" certificate. I included this certificate below for convenience, but it's best to export this certificate from another program that you have that already includes this certificate:


Does this help?

3) A very similar apache configuration file successfully works with other SSL-based web services (QuickBooks Web Connector)

It's possible that the configuration that doesn't work doesn't trust "C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority". It's also possible that the configuration that doesn't work has a SSLVerifyDepth directive with the count set to a number less than 2. If this must be set to 1, then you will need to trust the intermediate certificate directly instead of just the root. If you have SSLRequire conditions set that exclude proxy.salesforce.com's certificate, then that could be another reason why it wouldn't work.

If you want to lock down the client certificate as much as you can, then the following should work with the path modified to where you placed the downloaded proxy.salesforce.com certificate:

<Location /your-endpoint>
  SSLVerifyClient require
  SSLVerifyDepth 2
  SSLOptions +StrictRequire
  SSLRequire %{SSL_CLIENT_CERT} eq file("/etc/ssl/servers/proxy.salesforce.com.crt") \
             and %{SSL_CLIENT_I_DN} eq "/O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign"

Other possibilities exist, too.

As a side note, if you are a Microsoft IIS user, then you might need to trust the intermediate signing certificate of proxy.salesforce.com. Microsoft IIS appears to require that the signing certificate is trusted even though Salesforce.com is sending the certificate chain with its client certificate. Unfortunately, Microsoft ships Windows 2003 and below with an expired VeriSign intermediate certificate. You will need to delete it and replace it with an updated intermediate for that subject DN, such as the one at http://www.verisign.com/support/verisign-intermediate-ca/secure-site-pro-intermediate/index.html . MMC's certificate's snap-in for the computer account can be used for this.


Hi All,


I read this post, it is very helpful.


But what happend on my side is that: the outbound message can be received by my server if common SSL is enabled. It fails and caught the 'javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated' error messsage in the Salesforce outbound message monitor if Client Authentication is enable on the server side if the client-cert provided by the Salesforce is used.


I also did another test, that is extract 2 certs from the JAVA cacerts file which are the issuer in the chain of the client cert and use these two cert to configure the server for doing Client Authenticate, and it passed. In this test, I found this a little weired, because it seems that the client-cert did not take part in the client authentication process.


What I expected is that the client authentication shall works fine if I use the Salesforce client cert. Could anyone give an explain for this? Thanks in advance!

Steven LawranceSteven Lawrance

Hi TesterInSky,


By saying that the Salesforce.com client cerficiate is being used, are you saying that your server requires that Salesforce.com send it, or are you saying that you are using the Salesforce.com client certificate as the server's certificate?


The server will need to trust at least one of the signers of a certificate sent in the chain, and trusting the root VeriSign certificate that trusts the top of the chain that Salesforce.com sends as the client certificate is sufficient for this trust. The chain itself does not need to be explicitly trusted unless if you are using Tibco's software, which does require an explicit trust of each certificate in the chain except for the server certificate.


When you configured your server, did it always use its own server certificate? I'm guessing that it did, but I wanted to ask just to be sure. It should not use the Salesforce.com client certificate as the server's certificate, and that wouldn't work anyway because no one outside of Salesforce.com has its private key, and the common name (CN) on it is proxy.salesforce.com, which would fail the hostname check even if you had the private key.


Is there a way to configure your server to request (instead of require) a client certificate and then log whatever certificate is sent by the client? It should equal Salesforce.com's client certificate when requests from Salesforce.com come in.


Hopefully, this helps.


Steven Lawrance




Thanks for the great post. I have a few questions regarding receiving SFDC outbound messages in Tibco BW. I am able to recieve messages from Salesforce if i use a http connection. However i am getting the Outbound messaging error - javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated error when i set up a https connection using SSL.


1. What all certificates are needed to be hosted by the server (Tibco). Are 3 chain certificates and 2 verisign trusted certificates enough. Where can i get any other server certificates that salesforce will trust.


2. My tibco implementation needs an identity which needs a keystore. How do I create the key pair for it. Is there a public key that needs to be used for the same.


Thanks in Advance.

Steven LawranceSteven Lawrance

Hi Janita,


Tibco can be tricky as it appears to require the entire certificate chain to be trusted in advance, rather than only the root. Hopefully, Tibco can eventually be updated to require trust only at the root level, which is how almost all other servers work.


The entire certificate chain of the proxy.salesforce.com certificate will need to be trusted in Tibco. It's possible that trusting only the first intermediate is sufficient, though I haven't had the opportunity to test this within Tibco. If that doesn't work, then trusting the entire certificate chain is required. The certificates in the chain for proxy.salesforce.com are the following. Note that this is subject to change on or before December 7, 2013, which is that certificate's expiration date.


C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)10, CN=VeriSign Class 3 International Server CA - G3



C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2006 VeriSign, Inc. - For authorized use only, CN=VeriSign Class 3 Public Primary Certification Authority - G5



C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority



I verified that these certs are correct for the current proxy.salesforce.com certificate by using the "openssl verify" command with those three certificates existing in the CApath folder along with their hash symlinks.



For the identity keystore, is that for your server's https server certificate? It almost sounds like it might be for a client certificate, but a client certificate is not required on your server when interacting with Salesforce.com. Your server will need a server certificate that is signed by a certificate authority path that leads to at least one of the certificates listed on http://wiki.developerforce.com/page/Outbound_Messaging_SSL_CA_Certificates . Certificate authorities have instructions for generating keypairs and certificate signing requests. After you get a signed certificate back from a CA, it should be possible to package it with your private key into a pkcs12 file using the tool that generated the keypair and certificate signing request. As an example, the certificate manager in mmc.exe (built into Windows) can be used for this purpose. In Linux, I typically use XCA from http://xca.sourceforge.net/



As an amendment to an earlier post that I made, some popular VeriSign intermediate certificates are now trusted by default by Salesforce.com. This eases the configuration of a server somewhat, though it's always best to send the intermediate certificates in your server for maximum compatibility with Salesforce.com and other services. Those intermediate certificates are also listed on http://wiki.developerforce.com/page/Outbound_Messaging_SSL_CA_Certificates . That page changes periodically, though it's almost always to add new CAs and not to remove active (non-expired) CA certificates. Note that Salesforce.com does reserve the right to remove a CA certificate from its trust list if that CA certificate has been compromised.



I was having a problem with my Network Solutions wildcard SSL certificate and an Outbound Message. My webserver is Apache 2 on Debian Linux.


This thread and a few others helped me out a lot.  The most important troubleshooting command was:


openssl s_client -host your.endpoint.hostname -port 443 -showcerts -CApath /etc/ssl/certs/


I have seen this command in other posts, but without the -CApath option it will always say something about a self-signed certificate in your chain. FYI, the /etc/ssl/certs path is platform-dependant (in my case, Debian/Ubuntu).


The above command helped me determine that my intermediate certificates weren't setup correctly. Using the ZIP file provided by Network Solutions, I created a SSLCertificateChainFile by simply concatenating the three intermediate certificates from Network Solutions (AddTrustExternalCARoot.crt  NetworkSolutions_CA.crt UTNAddTrustServer_CA.crt) into a new file called NetworkSolutions_Intermediate_CA.crt.


With my new intermediate cert, I setup my SSL apache config as follows:


<IfModule mod_ssl.c>
        SSLEngine on

        SSLCertificateKeyFile   /path/to/private.key
        SSLCertificateFile      /path/to/wildcard.crt
        SSLCertificateChainFile /path/to/NetworkSolutions_Intermediate_CA.crt

        <FilesMatch "\.(cgi|shtml|phtml|php)$">
                SSLOptions +StdEnvVars

        BrowserMatch "MSIE [2-6]" \
                nokeepalive ssl-unclean-shutdown \
                downgrade-1.0 force-response-1.0
        # MSIE 7 and newer should be able to use keepalive
        BrowserMatch "MSIE [7-9]" ssl-unclean-shutdown


Hari KrishnanHari Krishnan

Those who look for some fundamentals on making the web service callouts, I have made a five part series in my blog which might be helpful for you.



Hari Krishnan.

Brian D.ax1579Brian D.ax1579

Your Information has been very helpful.


Has anyone gotten Salesforce.com to work with F5 LTM?

Hi Steven,

I am getting this error. Could you please suggest me on how to resolve this error:

java.security.cert.CertificateException: No name matching moodledemo.paradisosolutions.com found
Justin ClarkeJustin Clarke
This was very helpful for us, thanks. For us the issue was that we didn't have the certificate chain installed (or installed properly) on the server.

The OpenSSL tool was helpful in identifying this.