function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
MattAustinMattAustin 

Outbound message error, peer not authenticated

Hello, I am trying to setup outbound messaging from Salesforce to our webservice.  I have created a webservice per the wsdl that I downloaded from Salesforce.  The webservice works fine when I test it using a SOAP client, but I get the following error when Salesforce invokes it.   I am using HTTPS, but not client certificates to authenticate Salesforce.  Our server certificate is valid and current.  What could be the cause of this error?  (our webservice is built using .NET 2.0 framework, could there be a JAVA / .NET interop problem???)
 
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
SuperfellSuperfell
The server can't verify the certificate, is your cert signed by one of the expected certificate authorities (there's a list on the wiki somewhere).
MattAustinMattAustin
My certificate is issued by VeriSign Class 3 Secure Server CA.  There are several verisign entries in the wiki (http://wiki.apexdevnet.com/index.php/Outbound_Messaging_SSL_CA_Certificates).  How do I tell if one of those entries matches the issuer of my certificate?
SuperfellSuperfell
You match up the fingerprints.
MattAustinMattAustin
I have verified that the fingerprint (thumbprint) of the root certificate is in the list in the wiki.  (74:2c:31:92:e6:07:e4:24:eb:45:49:54:2b:e1:bb:c5:3e:61:74:e2 which is entry verisignclass3ca).  This makes me think that our CA is Salesforce approved.     What else could be the possible causes of the "peer not authenticated" error?
SuperfellSuperfell
Does the common name in the cert match your host name?

Are you sure your server is not trying to request the client cert (and rejecting the one we send) ?
MattAustinMattAustin
I confirmed with our web admin that we are not expecting client certificates.  We are, however, running the requests through a reverse proxy server.  The reverse proxy has the Verisign certificate, but the web server is using an internally issued certificate.  Does Salesforce work differerntly when communicating with a reverse proxy?
prbprb
Did you ever resolve this?  I'm getting the same error.  I'm proxying traffic from apache 2.X to tomcat 5.5 using AJP.  I have installed the cert into my keystore and I've verified that our cert is accepted by Salesforce (1D:35:54:04:85:78:B0:3F:42:42:4D:BF:20:73:0A:3F).
I don't see anything coming through on my apache access logs so I suspect the message is not being sent because the handshake fails?  I'm at as loss here.  Can someone please give me some tips on how to move forward?
Thanx!
SuperfellSuperfell
Wouldn't you need to install the cert into the apache config to do this ?
prbprb
Is the SSL request submnitted via HTTP form post?
SuperfellSuperfell
its a HTTP POST, but forms don't come into it, its SOAP 1.1
prbprb
I have installed the cert on apache and added it to the JDK keystore for Tomcat.  My application works when I use http on port 8080 so the problem is isolated to just SSL.  I can access the Web Service URL from the browser using SSL without warnings. 
Is there something I'm missing?  Is there something I need to install from salesforce?

Here is the Web.XML for my service:

<web-app version="2.4" mlns="http://java.sun.com/xml/ns/j2ee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
    <description>authenticate</description>
    <display-name>authenticate</display-name>
    <listener>
        <listener-class>com.sun.xml.ws.transport.http.servlet.WSServletContextListener</listener-class>
    </listener>
    <servlet>
        <description>SSO Authentication</description>
        <display-name>Authenticate</display-name>
        <servlet-name>AuthenticationPortType</servlet-name>
        <servlet-class>com.sun.xml.ws.transport.http.servlet.WSServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>AuthenticationPortType</servlet-name>
        <url-pattern>/authenticate</url-pattern>
    </servlet-mapping>
    <session-config>
        <session-timeout>60</session-timeout>
    </session-config>
</web-app>
prbprb
Also Here's the deployment descriptor:

    <endpoint
        name="authenticate"
        interface="sso.server.AuthenticationPortType"
        implementation="sso.server.AuthenticationImpl"
        wsdl="WEB-INF/wsdl/AuthenticationService.wsdl"
        service="{urn:authentication.soap.sforce.com}SforceAuthenticationService"
        port="{urn:authentication.soap.sforce.com}AuthenticationService"
        url-pattern="/authenticate" />
SuperfellSuperfell
What's the URL of your endpoint ?
prbprb
I think my problem might be that I have a chain file that contains references to root certs that salesfroce doesn't recognize? 
I followed these instructions:  http://customersupport.networksolutions.com/article.php?id=722
I have these files in my chain:
A) AddTrustExternalCARoot.crt
B) UTNAddTrustServer_CA.crt
C) NetworkSolutions_CA.crt
D) com.mydomain.crt
prbprb
The URL of my endpoint is: 
https://www.rocketrack.com/sso/authenticate
https://www.rocketrack.com/sso/authenticate?wsdl
SuperfellSuperfell
I would say you still have  a problem with the certificate chain.

Code:
grooverider:~ simon$ curl -v https://www.rocketrack.com/sso/authenticate
* About to connect() to www.rocketrack.com port 443
*   Trying 137.134.240.68... * connected
* Connected to www.rocketrack.com (137.134.240.68) port 443
* successfully set certificate verify locations:
*   CAfile: /usr/share/curl/curl-ca-bundle.crt
  CApath: none
* SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
* Closing connection #0
curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). The default
 bundle is named curl-ca-bundle.crt; you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.

 
prbprb
If I add the 'Network Solutions' and 'AddTrust External CA' certs to my CURL chain cert:
/usr/share/curl/curl-ca-bundle.crt.  I can execute a curl on my site.  I think the problem here is that Salesforce.com doesn't respect the Network Solutions CA file.  So do I have to buy a new certificate or is ther e a process to get this added to the list of verified SSL authorities?
prbprb
How do I go about getting Netowrk Solutions added as a trusted cert authority?  Or do I need to buy a new one?
SuperfellSuperfell
I thought your root cert was one of the supported ones ? if that's the case you need your webserver to be able to provide all the certs in the chain from a one that we support to your actual server's cert.
prbprb
Hmm. I'm not sure I understand this solution.  If I hack my certificate chain so that Salesforce understands it, won't it break the SSL cert through people's browsers?  I know that if I don't have the full certificate chain configured in apache people's browsers scream in opera, safari, and windows vista.
If there's a way to do this I need a little more info here.  Which CA files would I use in my new hacked certificate chain file?
SuperfellSuperfell
I'm not talking about hacking anything.

if the cert chain is
root -> inter 1 -> inter 2 -> your server.

and root is the only cert trusted by salesforce.com, then your webserver when asked will need to provide the certs for inter1 / inter2 and your server, not just your server (which is what it sounds like its doing). The is standard SSL stuff. If you're on apache, then see this example of setting up the cert chain.
http://www.securebusinessservices.com/help/install-certificate/apache-ssl.asp
prbprb
When I view the chain I can see the whole trail going back to the root, just as you described.  Salesforce still doesn't recognize it.
prbprb
OK I guess I will open a customer support incident about this since I'm getting nowhere.
SuperfellSuperfell
Not sure what's going on, using openssl, it complains as well, but the cert chain does appear to be there. I've asked one of our SSL folks to take a look.

FWIW, the output from running the openssl client is

OpenSSL> s_client -host www.rocketrack.com -port 443 -showcerts
CONNECTED(00000003)
depth=3 /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
0 s:/C=US/postalCode=02466/ST=MA/L=Newton/streetAddress=Suite 1-300/streetAddress=275 Grove St/O=Rocket Software, Inc./OU=IT/OU=Secure Link SSL Pro/CN=www.rocketrack.com
i:/C=US/O=Network Solutions L.L.C./CN=Network Solutions Certificate Authority
-----BEGIN CERTIFICATE-----
MIIFBjCCA+6gAwIBAgIQdR2u/ito9RJ4gK2j4HfX0TANBgkqhkiG9w0BAQUFADBi
MQswCQYDVQQGEwJVUzEhMB8GA1UEChMYTmV0d29yayBTb2x1dGlvbnMgTC5MLkMu
MTAwLgYDVQQDEydOZXR3b3JrIFNvbHV0aW9ucyBDZXJ0aWZpY2F0ZSBBdXRob3Jp
dHkwHhcNMDcwODAzMDAwMDAwWhcNMTEwODIxMjM1OTU5WjCB0DELMAkGA1UEBhMC
VVMxDjAMBgNVBBETBTAyNDY2MQswCQYDVQQIEwJNQTEPMA0GA1UEBxMGTmV3dG9u
MRQwEgYDVQQJEwtTdWl0ZSAxLTMwMDEVMBMGA1UECRMMMjc1IEdyb3ZlIFN0MR4w
HAYDVQQKExVSb2NrZXQgU29mdHdhcmUsIEluYy4xCzAJBgNVBAsTAklUMRwwGgYD
VQQLExNTZWN1cmUgTGluayBTU0wgUHJvMRswGQYDVQQDExJ3d3cucm9ja2V0cmFj
ay5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAO+dYV6kiBqupHu6YF47
zG1EGiFp4PP0VxMEs1yQymwudxlWfxZfeMEcUhGfQDepOW+AlLGZjnB/42ymigl4
pXAzkiIqFgn9GwfmL2aazEDSDQWQkTUVtduotZ2bOfsayoblGbj+b6idSO9OpOwt
lhEfsdCdy0eZrQRwf2g9fxEfAgMBAAGjggHLMIIBxzAfBgNVHSMEGDAWgBQ8QeKP
CAipTCWJjW3FOND8hYxiFzAdBgNVHQ4EFgQUcE08f8UU0m6M6e29G2MQzitSm1Mw
DgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUH
AwEGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIGwDBrBgNVHSAEZDBiMGAGDCsG
AQQBhg4BAgEDATBQME4GCCsGAQUFBwIBFkJodHRwOi8vd3d3Lm5ldHdvcmtzb2x1
dGlvbnMuY29tL2xlZ2FsL1NTTC1sZWdhbC1yZXBvc2l0b3J5LWNwcy5qc3AwegYD
VR0fBHMwcTA2oDSgMoYwaHR0cDovL2NybC5uZXRzb2xzc2wuY29tL05ldHdvcmtT
b2x1dGlvbnNfQ0EuY3JsMDegNaAzhjFodHRwOi8vY3JsMi5uZXRzb2xzc2wuY29t
L05ldHdvcmtTb2x1dGlvbnNfQ0EuY3JsMEwGCCsGAQUFBwEBBEAwPjA8BggrBgEF
BQcwAoYwaHR0cDovL3d3dy5uZXRzb2xzc2wuY29tL05ldHdvcmtTb2x1dGlvbnNf
Q0EuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQBOfWa40GWXkiGMqaXWDeBuL6a8wETL
0iRgov85AMCnrL8OB2/GmlfbsmN91OHxcmuDN9LMFFWzKLl+uHqraIfqXf+2uNpT
oD1tYUhYQGPHfZzfZWgzXCn2yDVAeGH6ZI6qp/CTGsm2rTs4EaA/KiHSHKQdcwQk
3DnaH/gVe1NTDugrVcWw4aoUc9JwgONbJOyWiHds91KOpfMkLslInEp7N66uwPUX
GWz72tPJ29Q9scoN136wIN1pb4EbzGHoOYZcjIT63TfbJCN5LGCu5snfXeTgE6oq
UnXNWhH4Cj7QlJnkATFTPPdljNVrDY+N8mBpkVIchOf17DYGSekKuKcN
-----END CERTIFICATE-----
1 s:/C=US/O=Network Solutions L.L.C./CN=Network Solutions Certificate Authority
i:/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware
-----BEGIN CERTIFICATE-----
MIIEpjCCA46gAwIBAgIQEOd26KZabjd+BQMG1Dwl6jANBgkqhkiG9w0BAQUFADCB
lzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2Ug
Q2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExho
dHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xHzAdBgNVBAMTFlVUTi1VU0VSRmlyc3Qt
SGFyZHdhcmUwHhcNMDYwNDEwMDAwMDAwWhcNMjAwNTMwMTA0ODM4WjBiMQswCQYD
VQQGEwJVUzEhMB8GA1UEChMYTmV0d29yayBTb2x1dGlvbnMgTC5MLkMuMTAwLgYD
VQQDEydOZXR3b3JrIFNvbHV0aW9ucyBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD3TbMg8MYVbCW2RMl0yaGSDi7
Fn/xnyn2/QPx7U0mmlbwtRoazebMhVVApLXQDcoi7z0jxn5szLyh6XxQRuC9FK1l
EsILEWlSCgeSH3NvwbrXYvDOAC40pcjmLw/sDepEYXVo5eTcgDZP2nhdUyWUlPVP
Ljpgbwym2bP2Ki4DEtUmQgdRsmRXcdwhHInHaaPm+8J7bu8Mh/tQZOhOS+/ncZuD
Y2HJMo2M7BSn5ImtPysmZOSFQvKJUOE6vhXjRSXiWsuMP+AzHjUJWoTqfl2h9ZGA
CigGt8sxQSVhiwHpVqL2Pl8v88RD9hmUdYNMoYJCOsa6xAkwpuF1AlG5XmSLAgMB
AAGjggEgMIIBHDAfBgNVHSMEGDAWgBShcl8mGyiYQ5VdBzfVhZadS9LDRTAdBgNV
HQ4EFgQUPEHijwgIqUwliY1txTjQ/IWMYhcwDgYDVR0PAQH/BAQDAgEGMBIGA1Ud
EwEB/wQIMAYBAf8CAQAwGQYDVR0gBBIwEDAOBgwrBgEEAYYOAQIBAwEwRAYDVR0f
BD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VUTi1VU0VSRmly
c3QtSGFyZHdhcmUuY3JsMFUGCCsGAQUFBwEBBEkwRzBFBggrBgEFBQcwAoY5aHR0
cDovL3d3dy51c2VydHJ1c3QuY29tL2NhY2VydHMvVVROQWRkVHJ1c3RTZXJ2ZXJf
Q0EuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQBoq/zvgGsYsrCzo0WJy1PFouavCKn9
/w9JrP/kn9dBfKPFouiq4FchLcOqfAxMKAt59O5MMq15Dn6iXjQYT99U8b1ofOPT
10ZebWTC922IgnMM75mF6qnvMkrwg59zkQykPisxUaZijxWE+aY6EjA/2m74zMcZ
kg9c9P4X8ZUIR1IsUI/om6XurnAziZGC/jCqdnZZ12wY0ysSWx0oHXhx9s02oukH
SEQ751duggqtxYrd6FO0ca8T0gadN21TP4o1CPr+ohbmuW9cVjnWxqrvGWfOE8W4
lQX7CkTJn6lAJUsyEa8H/gjVQnHp4VOLFR/dKgeVcCRvZF7Tt5AuiyHY
-----END CERTIFICATE-----
2 s:/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
-----BEGIN CERTIFICATE-----
MIIEPDCCAySgAwIBAgIQSEus8arH1xND0aJ0NUmXJTANBgkqhkiG9w0BAQUFADBv
MQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFk
ZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBF
eHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoXDTIwMDUzMDEwNDgzOFow
gZcxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtl
IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMY
aHR0cDovL3d3dy51c2VydHJ1c3QuY29tMR8wHQYDVQQDExZVVE4tVVNFUkZpcnN0
LUhhcmR3YXJlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsffDOD+0
qH/POYJRZ9Btn9L/WPPnnyvsDYlUmbk4mRb34CF5SMK7YXQSlh08anLVPBBnOjnt
KxPNZuuVCTOkbJex6MbswXV5nEZejavQav25KlUXEFSzGfCa9vGxXbanbfvgcRdr
ooj7AN/+GjF3DJoBerEy4ysBBzhuw6VeI7xFm3tQwckwj9vlK3rTW/szQB6g1ZgX
vIuHw4nTXaCOsqqq9o5piAbF+okh8widaS4JM5spDUYPjMxJNLBpUb35Bs1orWZM
vD6sYb0KiA7I3z3ufARMnQpea5HW7sftKI2rTYeJc9BupNAeFosU4XZEA39jrOTN
SZzFkvSrMqFIWwIDAQABo4GqMIGnMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8D
veAky1QaMB0GA1UdDgQWBBShcl8mGyiYQ5VdBzfVhZadS9LDRTAOBgNVHQ8BAf8E
BAMCAQYwDwYDVR0TAQH/BAUwAwEB/zBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8v
Y3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwDQYJ
KoZIhvcNAQEFBQADggEBADzse+Cuow6WbTDXhcbSaFtFWoKmNA+wyZIjXhFtCBGy
dAkjOjUlc1heyrl8KPpH7PmgA1hQtlPvjNs55Gfp2MooRtSn4PU4dfjny1y/HRE8
akCbLURW0/f/BSgyDBXIZEWT6CEkjy3aeoR7T8/NsiV8dxDTlNEEkaglHAkiD31E
NREU768A/l7qX46w2ZJZuvwTlqAYAVbO2vYoC7Gv3VxPXLLzj1pxz+0YrWOIHY6V
9+qV5x+tkLiECEeFfyIvGh1IMNZMCNg3GWcyK+tc0LL8blefBDVekAB+EcfeEyrN
pG1FJseIVqDwavfY5/wnfmcI0L36tsNhAgFlubgvz1o=
-----END CERTIFICATE-----
3 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
-----BEGIN CERTIFICATE-----
MIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU
MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFs
IFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
MB4XDTAwMDUzMDEwNDgzOFoXDTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0Ux
FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h
bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9v
dDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTngTlvt
H7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9
uMq/NzgtHj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzX
mk6vBbOmcZSccbNQYArHE504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LX
a0Tkx63ubUFfclpxCDezeWWkWaCUN/cALw3CknLa0Dhy2xSoRcRdKn23tNbE7qzN
E0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3CitlttNCbxWyuHv77+ldU9U0
WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTLVBowCwYD
VR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0
Jvf6xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRU
cnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsx
IjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcN
AQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5gdkeWxQHIzZlj7DYd7usQWxH
YINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKWt9x+Tu5w/Rw5
6wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC
Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEX
c4g/VhsxOBi0cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5a
mnkPIAou1Z5jJh5VkpTYghdae9C8x49OhgQ=
-----END CERTIFICATE-----
---
Server certificate
subject=/C=US/postalCode=02466/ST=MA/L=Newton/streetAddress=Suite 1-300/streetAddress=275 Grove St/O=Rocket Software, Inc./OU=IT/OU=Secure Link SSL Pro/CN=www.rocketrack.com
issuer=/C=US/O=Network Solutions L.L.C./CN=Network Solutions Certificate Authority
---
No client certificate CA names sent
---
SSL handshake has read 5227 bytes and written 316 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: A89FDD97DF3946B1B95DEB7633BEBBC93E00844A3EC0009E7B3EB1C381F17632
Session-ID-ctx:
Master-Key: 169FE780227A4767A12237A1968E3D2EE90CB01F51119692EBD358116401594AB419BF23B1627C681F609C2020984BAE
Key-Arg : None
Start Time: 1188512563
Timeout : 300 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
SuperfellSuperfell
One suggestion i got is that you're including the root cert in the set of sent certificates, and it probably shouldn't be there.
prbprb
This thread seems to be whacked because of the way the stylsheet is handling the stack trace of the certificate chain.  Anyways I just wanted to say that I added that root cert to our chain because it was the only cert I had that was on the list of approved certs and I thought you were trying to tell me that I needed a recognized  cert at the root.  I guess I misunderstood you, so I removed it and bounced apache.
Please let me know what advice your colleagues might have.
Thanks
prbprb
Since I may never get this resolved can you please recommend a certificate provider that other users have used successfully.
prbprb
Is this a dead end?  I can't figure this out.  I called Network Solutions and they just tell me that everything is set up correctly so I don't know what else to do.
SuperfellSuperfell
Did you log a case ?
prbprb
Customer support told me SSO is not supported so I'm at a dead end.
Do you think it would be worthwhile to purchase a different cert?  Or is the config problem I have likely to be true for any cert that I purchase?   Are there any certs that work out-of-the-box w/salesforce?  It's not a problem for us to buy another one if that will fix the problem.
SuperfellSuperfell
Support is wrong. did they even give you a case # ? (if you have a case #, i can get it re-opened and escallated to the right people).

My only concern with getting a different cert is that you're just going to end up in the same spot. The cert you have should work as far as i can see so far, I need to get confirmation that the CA root you're using really is in the list of ones we support.
prbprb
All I have is the case number for the activation of the SSO module (01404514) that my boss made for me.  When I tried to ask our customer support contact for help she said she couldn't support this feature of Salesforce.
From her email:
"Prior to activating this functionality, there are some details I need you to be aware of. The functionality does require some advanced setup to function correctly. During both the initial implementation and the actual use of the functionality, we cannot provide direct support for this aspect.  If you have any additional questions or concerns, please let me know. Please let me know if you would like to continue with the activation of this functionality for your organization. "

The fingerprint of the cert I thought was valid is:
Issuer: C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, CN=AddTrust External CA Root
1D:35:54:04:85:78:B0:3F:42:42:4D:BF:20:73:0A:3F

This came in the zip file from network solutions but was not part of the chain file they gave us to install.  I added this myself to see if it would help but it did nothing.

I think the problem is that the intermediate certs that are part of the chain are not recognized.  I can send you all the certs we have if that would help?

I created a new case for this under my SF account:
01415659

If you can escalate this please escalate 01415659.

Cheers
SuperfellSuperfell
I've asked the relevant folks to take a look, using a simple java test client, i get a cert chain problem, still not sure if this is an actual problem with the certs for the cert chain, or that the wiki eronously lists the ultimate root as being supported.

Code:
Exception in thread "main" javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors
        at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:150)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1518)
        at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:174)
        at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:168)
        at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:848)
        at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:106)
        at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:495)
        at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:433)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:818)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1030)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1057)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1041)
        at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:402)
        at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:170)
        at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:916)
        at java.net.URLConnection.getContent(URLConnection.java:682)
        at sun.net.www.protocol.https.HttpsURLConnectionImpl.getContent(HttpsURLConnectionImpl.java:406)
        at httpsTest.main(httpsTest.java:11)
Caused by: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors
        at sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:187)
        at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:130)
        at sun.security.validator.Validator.validate(Validator.java:203)
        at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:172)
        at com.sun.net.ssl.internal.ssl.JsseX509TrustManager.checkServerTrusted(SSLContextImpl.java:320)
        at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:841)
        ... 13 more
Caused by: java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors
        at sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:195)
        at java.security.cert.CertPathValidator.validate(CertPathValidator.java:206)
        at sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:182)

 
prbprb
This error only means that none of the certs are installed on your JKS keychain.  Import them into your JKS keystore with keytool -import and this message goes away.
Same thing goes for curl and openssl. If you don't tell them where to find the public certs it doesn't know where to look.  It only has a select few built in.
SuperfellSuperfell
Surely the standard root certs are in my default keystore.
SuperfellSuperfell
Pointing the same code at https://www.salesforce.com works fine. the system provided set of CA certs is loaded by default, so i think this is something to do with the way your server is sending the certs for the cert chain.
prbprb
I don't have the root cert in the default keychain for java (1.5.7) or curl (gentoo, debain, redhat, or cygwin).
prbprb
OK well I guess I will try a dumbed down cert from somewhere like godaddy b/c the intermediate certs obviously break the SOAP client for salesforce.com.
I also noticed that salesforce does not have any internediary certs in it's chain so this must be the way to do it.
SuperfellSuperfell
Having the server send the right set of intermediate certs will work, i know other people have gotten that to work.
prbprb
Is there someone I can contact for an example?  I don't know what else to do.
Cheers
prbprb
I think my SSL cert is installed correctly but salesforce.com still throws me the now infamous 'javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated' error.
I can run a simple SOAP client that has only the root certificate installed int the local keychain.
I can 'curl -v'  my SOAP listener and get valid feedback
I can openssl s_client -connect -showcerts and see the entire chain.

The only explanation I have is that the cert is not installed on the machine that is making the call to my server.
This is the root cert is here:
http://wiki.apexdevnet.com/index.php/Outbound_Messaging_SSL_CA_Certificates#Entry:_addtrustexternalca

Please let me know what else I can do to troubleshoot this very frustrating problem.
SuperfellSuperfell
Yes, it turns out that the list of certs on the wiki was generated from a different VM version to the one we actually run in production, and the AddTrust root cert is not there. We're working on getting the servers updated with the set of certs to match the docs. Sorry for how long its taken to work this one out.
Steven LawranceSteven Lawrance
As a follow-up, if you are experiencing general SSL or TLS connection issues with outbound messages, delegated authentication, or Apex callouts, please see my post at http://community.salesforce.com/sforce/board/message?board.id=general_development&message.id=19589#M19589 and see if that describes (and hopefully fixes) your issue. Thanks!
Tom BaeyensTom Baeyens
Hi, 

I just ran into that issue, that SF OM throws an Exception. It looks like SF doesn't trust our certificate, even though multiple certs and the root cert are trusted according to the SF dev wiki. We got our certificate from RapidSSL, which is signed by GeoTrust Global CA which is signed by Equifax Secure CA. 

It should be trusted automaticly. Any Ideas what can cause the problem here?

Thanks.
Tom BaeyensTom Baeyens
Ok, I managed to solve it. One of the intermediate certificates wasn't installed on the server.
Sheila AvilesSheila Aviles
Hi

We are getting the same error message when sending an outbound message to our SOA Webservice.  Our Certificate is issued by Entrust (2048)
CN = Entrust Certification Authority - L1C
OU = (c) 2009 Entrust, Inc.
OU = www.entrust.net/rpa is incorporated by reference
O = Entrust, Inc.
C = US 
SHA1

Can you help us with this issue?

thank you