Re: "No subject alternative names matching IP address" error with 1.64
Peter Dettman <[email protected]> Tue, 12 Nov 2019 05:13:50 +1030
| Newsgroups | gmane.comp.encryption.bouncy-castle.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi Mauro, Please refer to this comment: https://github.com/bcgit/bc-java/issues/460#issuecomment-461085449 In particular: "when using HttpsURLConnection SunJSSE uses some magic (reflection and/or internal API) to tell the socket about the "original hostname" used for the connection" We recommend you set the server name explicitly in a custom SSLSocketFactory as shown there. I would also suggest to use the "PKIX" TrustManagerFactory (and KeyManagerFactory) from BCJSSE provider. Regards, Pete Dettman On 12/11/19 12:45 am, mauromol wrote: > Caused by: java.security.cert.CertificateException: No subject alternative > names matching IP address AAA.BBB.CCC.DDD found > at > sun.security.util.HostnameChecker.matchIP(HostnameChecker.java:174) > ~[?:1.7.0_201] > at sun.security.util.HostnameChecker.match(HostnameChecker.java:100) > ~[?:1.7.0_201] > at > sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:347) > ~[?:1.7.0_201] > at > sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:203) > ~[?:1.7.0_201] > at > sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:126) > ~[?:1.7.0_201] > at > org.bouncycastle.jsse.provider.ImportX509TrustManager_7.checkServerTrusted(Unknown > Source) ~[bctls-jdk15to18-1.64.jar:1.64.00.0] > ... 84 more > > where AAA.BBB.CCC.DDD is an IP address. What I can't understand is why this > message is given, because: > - I connect to the remote server using its DNS name (e.g.: > https://www.example.com/etc.) > - the DNS resolution of www.example.com is exactly AAA.BBB.CCC.DDD > - the remote server certificate has a right CN (CN=www.example.com) > - the remote server certificate also has a DNS SAN of www.example.com > So all looks good to me with the remote certificate. > > I'm using client certificate authentication, so this complicates the picture > a bit. However, looking at the stack trace, it seems like the problem > actually relies on the remote server certificate verification, not on my > client one (which shouldn't be the case anyway). > > Do you have any idea on what is going on? > > Mauro