Certificate Error in Outbound Messaging Delivery Status
In our Outbound Messaging Delivery Status we are receiving an error message "javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated"
But, we have a valid cert as distinguished here:
https://www.sslshopper.com/ssl-checker.html#hostname=admin.clearcareonline.com
This shows that we have a valid cert chain.
https://developer.salesforce.com/page/Outbound_Messaging_SSL_CA_Certificates
starfieldclass2ca is listed and is in the chain
openssl s_client -connect admin.clearcareonline.com:443 |egrep -i starfield
s:/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority
And, both the certs on Salesforce and our Site have a matching SHA1.
What needs to happen to ensure that Salesforce accepts our cert?
Hi, Got the end point URL from the description and found this error :
got Exception : javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
Remote server's SSL/TLS configuration has one or more errors or warnings
Error: Could not successfully communicate with the endpoint: javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair
There are known issues with java and long DH keys. What do you accept for length of DH Keys? Since the discovery of the SSL bug "Logjam" we are using 2048 DH Keys.
We have done some searching and none of the SSL certificate provider we've contacted will sell a 1024-bit key.
If SSL certificate providers aren't supporting 1024-bit keys I would think Salesforce shouldn't be either. Are there plans to remove this security flaw in the Salesforce system?
What are our options at this point?
Please also understand that this is negatively affecting our reputation and our ability to do business with many of our clients who expect a working integration with Salesforce.
Here are just a few articles about this issue:
The Java Bug -
http://stackoverflow.com/questions/6851461/java-why-does-ssl-handshake-give-could-not-generate-dh-keypair-exception
Providers phase out 1024-bit keys last year -
https://blog.comodo.com/e-commerce/time-to-upgrade-say-goodbye-to-1024-bit-ssl/
https://support.godaddy.com/help/article/5619/why-do-you-require-a-2048-bit-key-for-my-csr
Hi, I am escalating this to the internal team to see how we can workaround this issue. I have created case#12072248 where I will be including the investigation done so far and escalate to tier3 - will be updating you via the case.
We are trying to make an outbound call to an endpoint on our webserver (https://atlasnetwork.org/academy/api?key=89BBC7846D5E157765356BA3C1D17&type=course) however we are getting an error "javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated" in Salesforce outbound messaging. I've done research, and can't find the cause of the problem. Our SSL certs fingerprint matches to one on record in the Salesforce keystore and the command "openssl s_client -connect www.atlasnetwork.org:443 -showcerts -CApath /etc/ssl/certs" shows no issues with the configuration. We are running apache 2.4. The endpoint/API works over HTTP without issue. Any thoughts?
@Jeremy, I checked your endpoint and got the same error as being faced by @Clearcare:
got Exception : javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
Remote server's SSL/TLS configuration has one or more errors or warnings
Error: Could not successfully communicate with the endpoint: javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair
As mentioned in the thread before, Salesforce presently runs on JDK7(which is why you are seeing this issue) and will gradually be upgraded to JDK8 through a series of patches, hopefully by Summer '15 #safeharbor.
Suggested workarounds:
If its possible, do not enable DH cipher suites when a Salesforce IP address is seen in a connection.
De-preference DH ciphers on you server side or instead of adjusting the DH keys to be 1024-bit, opt to either prioritize AES256-SHA above EC ciphersuites for compatibility right away or, if waiting for summer release is an option (or if you are already on 196), enabling Elliptic Curve (EC) DH ciphersuites is the best option.
ECDH/ECDHE ciphersuites are generally stronger than regular DH, and Java 7 already supports strong ECDH/ECDHE keys.
@sonam, I see in a previous comment that we can expect the fix to be pushed in a series of releases occurring this summer. Is there any chance you could give us a timeline on these releases? Thanks for your continued support in resolving this matter.
Hi, I've recieved an update from R&D stating that we presently have JDK8 deployed to almost all sandbox instances, and work is being done this week to complete the rollout to the remaining sandbox instances.
The deployment to the remaining production instances is planned to occur during the month of August (#safeharbor).
Is there are chance you could test your integration in sandbox and confirm if things are fixed for you after this JDK1.8 rollout?
I've reached out to R&D for latest uodate, I haven't seen a response from you regarding testing this on your sandbox..did you try testing it out there? Kindly update in case you have faced any issues.
We were getting javax.net.ssl.SSLPeerUnverifiedException: SSL Peer shut down incorrectly >>
The issue was though we had shared Certificate (self-signed) as well as WSDL from the outbound message with the third party Integration systems/applications. while outbound messages were getting triggered from SFDC the request was going to third-party system without the SSL certificate in the request XML, for this - we had to go to Certificate and Key Management> API Client Certificate -- select the certificate name
got Exception : javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
Remote server's SSL/TLS configuration has one or more errors or warnings
Error: Could not successfully communicate with the endpoint: javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair
There are known issues with java and long DH keys. What do you accept for length of DH Keys? Since the discovery of the SSL bug "Logjam" we are using 2048 DH Keys.
Is that the issue you are seeing?
This seems to be the issue with your server using 2048 DH Keys, which JDK7 does not support. It needs a 1024-bit DH key.
This is very concerning.
We have done some searching and none of the SSL certificate provider we've contacted will sell a 1024-bit key.
If SSL certificate providers aren't supporting 1024-bit keys I would think Salesforce shouldn't be either. Are there plans to remove this security flaw in the Salesforce system?
What are our options at this point?
Please also understand that this is negatively affecting our reputation and our ability to do business with many of our clients who expect a working integration with Salesforce.
Here are just a few articles about this issue:
The Java Bug -
http://stackoverflow.com/questions/6851461/java-why-does-ssl-handshake-give-could-not-generate-dh-keypair-exception
Providers phase out 1024-bit keys last year -
https://blog.comodo.com/e-commerce/time-to-upgrade-say-goodbye-to-1024-bit-ssl/
https://support.godaddy.com/help/article/5619/why-do-you-require-a-2048-bit-key-for-my-csr
Can someone help me trouble shoot it?
or give me directions on how I can get this resolved?
thank you
I think we figured it out
Our certificate in our test environment is not publicly certified it is self signed
thank you
got Exception : javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
Remote server's SSL/TLS configuration has one or more errors or warnings
Error: Could not successfully communicate with the endpoint: javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair
As mentioned in the thread before, Salesforce presently runs on JDK7(which is why you are seeing this issue) and will gradually be upgraded to JDK8 through a series of patches, hopefully by Summer '15 #safeharbor.
Suggested workarounds:
If its possible, do not enable DH cipher suites when a Salesforce IP address is seen in a connection.
De-preference DH ciphers on you server side or instead of adjusting the DH keys to be 1024-bit, opt to either prioritize AES256-SHA above EC ciphersuites for compatibility right away or, if waiting for summer release is an option (or if you are already on 196), enabling Elliptic Curve (EC) DH ciphersuites is the best option.
ECDH/ECDHE ciphersuites are generally stronger than regular DH, and Java 7 already supports strong ECDH/ECDHE keys.
Has a date been published? I would like to narrow down this window as much as possible.
Thanks.
Any update?
The deployment to the remaining production instances is planned to occur during the month of August (#safeharbor).
Is there are chance you could test your integration in sandbox and confirm if things are fixed for you after this JDK1.8 rollout?
Has this been deployed to production?
Thanks -
JDK1.8 has been rolled out on all instances now, could you please check and confirm if the issue is fixed for you?
We were getting javax.net.ssl.SSLPeerUnverifiedException: SSL Peer shut down incorrectly >>
The issue was though we had shared Certificate (self-signed) as well as WSDL from the outbound message with the third party Integration systems/applications. while outbound messages were getting triggered from SFDC the request was going to third-party system without the SSL certificate in the request XML, for this - we had to go to Certificate and Key Management> API Client Certificate -- select the certificate name