0

I'm using the HttpsURLConnection class to open a secure connection to an IIS web host. It requires an SNI extension to be in all the SSL connections.

I'm also using an X509TrustManager (much like in this answer). It either has the option of trusting all certificates (i.e. performing no checks/verification on the trust chain, like in the above answer) or performing really basic checks on the trust chain (that all certificates aren't expired and that each is signed by the previous one by calling the X509Certificate.verify(PublicKey) function, using the previous certificate's public key).

The checking seemed to work fine for a bit - it did all the checks and all the verifies worked, and it returned from the checkServerTrusted method without an exception.

However, it throws an error outside of that (in what must be the super class of TrustManager since it has there's a checkServerTrusted in the stacktrace - and it's the same class as when I throw an exception from my TrustManager). It throws a java.security.cert.CertificateException: No name matching host.com found. It does, however, work fine for my server (i.e. this exception doesn't get thrown).

This seems to be a somewhat common problem that setting a default HostnameVerifier solves (I had it just returning true all the time).

This, though, introduced a new problem: it removed the SNI extension from the SSL connections, which my server needs for me to connect. This causes a SocketException: Connection reset (stacktrace here)), before the verification even happens. In my network trace, I can see a Client Hello message (with no SNI extension). There is no response from the server (I guess, because it doesn't even respond if there's no SNI extension).

Is this something that should be happening? Is there any way to stop it removing SNI, or something I have to do in the verification stuff that sets it?

It's also really weird, because I have the verify method of my HostnameVerifier printing out a bunch of stuff, but, as far as I can tell, it never gets called.

EDIT:

Added some stack traces and corrected/added some details.

This question seems pretty similar, but it doesn't really have a definitive answer, from what I can tell.

Community
  • 1
  • 1
dram
  • 97
  • 1
  • 8
  • Stack trace please. `X509Certificate.verify()` doesn't give a hoot about the hostname. It doesn't even know that the `subjectDN` *is* a hostname. – user207421 Jan 20 '17 at 00:38
  • Hmm, I've just had another look, and I think I was wrong about that :/ I'll update my question with details. Thanks :) – dram Jan 20 '17 at 00:53
  • 1
    This issue is due to a JDK bug. You can find affected versions in the details of this answer: http://stackoverflow.com/a/41740819/6371459 I have tested and posted the workaround proposed in the top voted answer of the question you linked – pedrofb Jan 20 '17 at 13:38

0 Answers0