Salesforce

HTTPS Requester throws "No name matching xxxx found" (java.security.cert.CertificateException)

Printable View
« Go Back

Information

 
Content

SYMPTOM

An application containing SSL certificates fails at startup with the following root cause exception:
HTTPS Requester throws "No name matching xxxx found" (java.security.cert.CertificateException)
these are some example error messages that could be presented 
No name matching xxxx found (java.security.cert.CertificateException)
  sun.security.util.HostnameChecker:-1 (null)

 General SSLEngine problem (javax.net.ssl.SSLHandshakeException)
  sun.security.ssl.Alerts:-1 (http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/net/ssl/SSLHandshakeException.html)

General SSLEngine problem (javax.net.ssl.SSLHandshakeException)
  sun.security.ssl.Handshaker:-1 (http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/net/ssl/SSLHandshakeException.html)

javax.net.ssl.SSLHandshakeException: General SSLEngine problem (java.util.concurrent.ExecutionException)
  org.glassfish.grizzly.impl.SafeFutureImpl$Sync:349 (null)

java.util.concurrent.ExecutionException: javax.net.ssl.SSLHandshakeException: General SSLEngine problem (java.io.IOException)
  org.mule.module.http.internal.request.grizzly.GrizzlyHttpClient:245 (null)

Error sending HTTP request. Message payload is of type: String (org.mule.api.MessagingException)
  org.mule.module.http.internal.request.DefaultHttpRequester:287 (http://www.mulesoft.org/docs/site/current3/apidocs/org/mule/api/MessagingException.html)

CAUSE

This error is caused by the fact that in 3.7 the SSL hostname verification is enforced due to an upgrade in the library async-http-client. You can find this library update in the releases notes: https://docs.mulesoft.com/release-notes/mule-esb-3.7.0-release-notes#updated-libraries 
 

SOLUTION

You can disable this validation by adding this system property in one of this two ways: 

  1. Using this parameter when the JVM starts: -Dcom.ning.http.client.AsyncHttpClientConfig.acceptAnyCertificate=true 

  2. Adding this line to your wrapper.conf: 
    wrapper.java.additional.<n>=-M-Dcom.ning.http.client.AsyncHttpClientConfig.acceptAnyCertificate=true 

Though it is intended to disable all sorts of certificate validation (just like curl's -k option), given Mule configuration it will only disable hostname verification. This happens because we always add a default TlsContext if none is provided, which means a default TrustManager as well. In AHC, the flag is used to disable all validations: it creates a LooseTrustManager that's ok with any certificate being presented and prevents setting the algorithm to HTTPS to avoid Java's HostnameChecker. In Mule, it only causes the latter since we always add our own SslContext, so that a LooseTrustManager is never created.

The hostname verification is a new security feature. This configuration will apply to all the applications, not limited to just one. 

WARNING: note that disabling that verification could result in a security vulnerability for any application using HTTPS protocol deployed in that runtime and should be avoided for PRODUCTION deployments

As being able to disable certificate validation is a usual request for testing, since Mule 3.8, it is possible to disable per the TLS context using the insecure attribute of the <tls:trust-store> element. Please see the documentation for details.
 
We by no means recommended that you take advantage of that vulnerability yourself. Disabling certificate validation defeats the intent of securing communications. We strongly advise modifying your certificates to be correct.

 
Attachments
Powered by