"No subject alternative names matching IP address" error with 1.64

Hello,
I'm using the Bouncy Castle JSSE provider on Java 7 to send client requests
to a remote server running TLS 1.2. Client certificate authentication is in
use.
I was using BC 1.56 until today, but starting from last Friday a certificate
change on the server started to cause connection failures on my side. This
is the error I was getting:

(just reporting the root cause):

Caused by: java.io.IOException: Internal TLS error, this could be an attack
	at org.bouncycastle.tls.TlsProtocol.failWithError(Unknown Source)
	at org.bouncycastle.tls.TlsProtocol.safeReadRecord(Unknown Source)
	at org.bouncycastle.tls.TlsProtocol.blockForHandshake(Unknown Source)
	at org.bouncycastle.tls.TlsClientProtocol.connect(Unknown Source)
	at
org.bouncycastle.jsse.provider.ProvSSLSocketDirect.startHandshake(Unknown
Source)
	at
sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
	at
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
	at
sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1139)
	at
sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:250)
	at
org.springframework.ws.transport.http.HttpUrlConnection.getRequestOutputStream(HttpUrlConnection.java:89)
	at
org.springframework.ws.transport.AbstractSenderConnection$RequestTransportOutputStream.createOutputStream(AbstractSenderConnection.java:87)
	at
org.springframework.ws.transport.TransportOutputStream.getOutputStream(TransportOutputStream.java:41)
	at
org.springframework.ws.transport.TransportOutputStream.write(TransportOutputStream.java:69)
	at
com.sun.xml.internal.messaging.saaj.packaging.mime.util.OutputUtil.writeAsAscii(OutputUtil.java:63)
	at
com.sun.xml.internal.messaging.saaj.packaging.mime.util.OutputUtil.writeln(OutputUtil.java:53)
	at
com.sun.xml.internal.messaging.saaj.packaging.mime.internet.MimeMultipart.writeTo(MimeMultipart.java:276)
	at
com.sun.xml.internal.messaging.saaj.soap.MessageImpl.writeTo(MessageImpl.java:1320)
	... 59 more

Searching on the Internet I found a Stack Overflow question where another
guy solved this by upgrading to BC 1.59 (he was using 1.57). After some
hours of investigation, I indeed confirm that with BC 1.59 all works fine
again. However, I spent a lot of time because I was cheated by the fact that
with BC 1.64 a more meaningful error is given. So, I was thinking that my
original problem was the one reported by BC 1.64, although with 1.56 it was
reported with an incomprehensible exception message. However, given the
behaviour of 1.59, it must not be the case. Moreover, after a lot of
investigation, I can't explain the error given by BC 1.64. In practice, this
is what BC 1.64 says:

[INFO ] 2019/11/11 14:20:42 - <system> - outgoingSdiFileExecutor-1 -
org.bouncycastle.jsse.provider.ProvTlsClient - Client raised fatal(2)
certificate_unknown(46) alert: Failed to read record
org.bouncycastle.tls.TlsFatalAlert: certificate_unknown(46)
        at
org.bouncycastle.jsse.provider.ProvSSLSocketDirect.checkServerTrusted(Unknown
Source) ~[bctls-jdk15to18-1.64.jar:1.64.00.0]
        at
org.bouncycastle.jsse.provider.ProvTlsClient$1.notifyServerCertificate(Unknown
Source) ~[bctls-jdk15to18-1.64.jar:1.64.00.0]
        at org.bouncycastle.tls.TlsUtils.processServerCertificate(Unknown
Source) ~[bctls-jdk15to18-1.64.jar:1.64.00.0]
        at
org.bouncycastle.tls.TlsClientProtocol.handleServerCertificate(Unknown
Source) ~[bctls-jdk15to18-1.64.jar:1.64.00.0]
        at
org.bouncycastle.tls.TlsClientProtocol.handleHandshakeMessage(Unknown
Source) ~[bctls-jdk15to18-1.64.jar:1.64.00.0]
        at org.bouncycastle.tls.TlsProtocol.processHandshakeQueue(Unknown
Source) [bctls-jdk15to18-1.64.jar:1.64.00.0]
        at org.bouncycastle.tls.TlsProtocol.processRecord(Unknown Source)
[bctls-jdk15to18-1.64.jar:1.64.00.0]
        at org.bouncycastle.tls.RecordStream.readRecord(Unknown Source)
~[bctls-jdk15to18-1.64.jar:1.64.00.0]
        at org.bouncycastle.tls.TlsProtocol.safeReadRecord(Unknown Source)
[bctls-jdk15to18-1.64.jar:1.64.00.0]
        at org.bouncycastle.tls.TlsProtocol.blockForHandshake(Unknown
Source) [bctls-jdk15to18-1.64.jar:1.64.00.0]
        at org.bouncycastle.tls.TlsClientProtocol.connect(Unknown Source)
[bctls-jdk15to18-1.64.jar:1.64.00.0]
        at
org.bouncycastle.jsse.provider.ProvSSLSocketDirect.startHandshake(Unknown
Source) [bctls-jdk15to18-1.64.jar:1.64.00.0]
        at
org.bouncycastle.jsse.provider.ProvSSLSocketDirect.startHandshake(Unknown
Source) [bctls-jdk15to18-1.64.jar:1.64.00.0]
        at
sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
[?:1.7.0_201]
        at
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
[?:1.7.0_201]
        at
sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1157)
[?:1.7.0_201]
        at
sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:259)
[?:1.7.0_201]
        at
org.springframework.ws.transport.http.HttpUrlConnection.getRequestOutputStream(HttpUrlConnection.java:89)
[spring-ws-core-2.3.0.RELEASE.jar:2.3.0.RELEASE]
        at
org.springframework.ws.transport.AbstractSenderConnection$RequestTransportOutputStream.createOutputStream(AbstractSenderConnection.java:87)
[spring-ws-core-2.3.0.RELEASE.jar:2.3.0.RELEASE]
        at
org.springframework.ws.transport.TransportOutputStream.getOutputStream(TransportOutputStream.java:41)
[spring-ws-core-2.3.0.RELEASE.jar:2.3.0.RELEASE]
        at
org.springframework.ws.transport.TransportOutputStream.write(TransportOutputStream.java:69)
[spring-ws-core-2.3.0.RELEASE.jar:2.3.0.RELEASE]
        at
com.sun.xml.internal.messaging.saaj.packaging.mime.util.OutputUtil.writeAsAscii(OutputUtil.java:63)
[?:1.7.0_201]
        at
com.sun.xml.internal.messaging.saaj.packaging.mime.util.OutputUtil.writeln(OutputUtil.java:53)
[?:1.7.0_201]
[... cut ...]
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



--
Sent from: http://bouncy-castle.1462172.n4.nabble.com/Bouncy-Castle-Dev-f1462173.html