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