2

We are moving a service from JDK 10.0.1 to JDK 11. This service communicates using a TLS connection, where the server has a self-signed certificate.

The CA of this certificate has been added to the cacerts of both JVM's.

Using JDK 10, this was enough to be able to use the HttpBuilder API and communicate with this service. When running the same code (with just the changes to move from jdk.incubator.http to java.net.http) to JDK 11, I hit the notorious “java.security.cert.CertificateException: No subject alternative names present” error?

I understand this is easily fixed by creating an HostNameVerifier with a custom implementation, which is then used with HttpsUrlConnection.

But I'd rather stick with the HttpBuilder API if that's possible.

Naman
  • 27,789
  • 26
  • 218
  • 353
Jürgen De Commer
  • 61
  • 1
  • 5
  • 1
    It was a deliberate decision to not add a hostname verifier API to the Java 11 HTTP Client. Strict hostname verification is enabled by default ( and may be disabled globally in some environments, like testing for example ). Can I ask what is the use-case for connecting to a "secure" server that does not identify itself in its certificate. Maybe you have an example of such a server / service? – chegar999 Oct 31 '18 at 14:57
  • @chegar999 we have a setup where machines talk to each other in a private network and use mutual ssl to secure access to the services. All internal certificates are generated using the same (own) CA. (We use proper certs for the publicly exposed endpoints, no worries). In this case, there is a new Java client that needs to connect to one of these services on the loopback interface. And it was surprising to suddenly have this change of behaviour when going from JDK 10 to 11. Towards the future, we'll look into modifying our cert creation and add the necessary info to avoid setting the flag. – Jürgen De Commer Nov 08 '18 at 09:08

1 Answers1

3

There is system property aptly named "jdk.internal.httpclient.disableHostnameVerification" that can be used to disable the check: http://hg.openjdk.java.net/jdk/jdk/file/4254bed3c09d/src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java#l110

My issue is resolved when I start my service as such:

java -Djdk.internal.httpclient.disableHostnameVerification -jar FancyService.jar
Jürgen De Commer
  • 61
  • 1
  • 5