Apex Code Development You need to sign in to do that
Don't have an account?
ClearCare Integration 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?
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?
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