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

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

mauromol
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

Reply | Threaded
Open this post in threaded view
|

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

Eckenfels. Bernd
If you supply your own ConnectionFactory maybe this one does incorrectly construct the SSLSocket and uses the resolved address instead of the hostname. This will influence the SNI Signalling and the HostnameVerifier.

Gruss
Bernd
--
http://www.seeburger.com
________________________________________
From: mauromol [[hidden email]]
Sent: Monday, November 11, 2019 15:15
To: [hidden email]
Subject: [dev-crypto] "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









SEEBURGER AG            Vorstand/SEEBURGER Executive Board:
Sitz der Gesellschaft/Registered Office:                Axel Haas, Michael Kleeberg, Axel Otto, Dr. Martin Kuntz, Matthias Feßenbecker
Edisonstr. 1
D-75015 Bretten         Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:
Tel.: 07252 / 96 - 0            Prof. Dr. Simone Zeuchner
Fax: 07252 / 96 - 2222
Internet: http://www.seeburger.de               Registergericht/Commercial Register:
e-mail: [hidden email]               HRB 240708 Mannheim


Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.


This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.

Reply | Threaded
Open this post in threaded view
|

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

mauromol
Hi Bernd,
I'm using this within a Spring Integration flow. What I see that is performed is this:
  • connection = url.openConnection()
  • this connection is a HttpsUrlConnection on which I set my custom SSLSocketFactory with javax.net.ssl.HttpsURLConnection.setSSLSocketFactory(SSLSocketFactory)
  • then, the following properties are set on the connection before use:
    connection.setRequestMethod(HttpTransportConstants.METHOD_POST);
    connection.setUseCaches(false);
    connection.setDoInput(true);
    connection.setDoOutput(true);
    if (isAcceptGzipEncoding()) {
         connection.setRequestProperty(HttpTransportConstants.HEADER_ACCEPT_ENCODING,
             HttpTransportConstants.CONTENT_ENCODING_GZIP);
    }
    connection.setConnectTimeout(myConnectTimeout);
    connection.setReadTimeout(myReadTimeout);
I use a custom SSLSocketFactory in order to be able to supply a client certificate. This SSLSocketFactory is built by this method:

public static SSLSocketFactory createClientCertificateSslSocketFactory(
        final InputStream clientCertificateArchiveInputStream,
        final char[] clientCertificateArchivePassword,
        final Provider provider) throws IOException, CertificateException,
        UnrecoverableKeyException {
    final KeyManagerFactory keyManagerFactory;
    try {
        keyManagerFactory = KeyManagerFactory.getInstance("SunX509");
        final KeyStore keyStore;
        try {
            keyStore = KeyStore.getInstance("PKCS12");
        } catch (KeyStoreException e) {
            // no PKCS12 provider - should never happen
            throw new RuntimeException(e);
        }
        keyStore.load(clientCertificateArchiveInputStream,
                clientCertificateArchivePassword);
        try {
            keyManagerFactory.init(keyStore,
                    clientCertificateArchivePassword);
        } catch (KeyStoreException e) {
            // we do not expect this to happen
            throw new RuntimeException(e);
        }
        final SSLContext context = provider != null
                ? SSLContext.getInstance("TLS", provider)
                : SSLContext.getInstance("TLS");
        try {
            context.init(keyManagerFactory.getKeyManagers(), null,
                    new SecureRandom());
        } catch (KeyManagementException e) {
            // another unexpected failures
            throw new RuntimeException(e);
        }
        return context.getSocketFactory();
    } catch (final NoSuchAlgorithmException e) {
        // missing or problematic SunX509 provider - should never happen
        throw new RuntimeException(e);
    }
}

The supplied provider, in my case, is a: new BouncyCastleJsseProvider()

So, apart from supplying the BC provider and the key managers to the SSLContext from which the SSL socket factory is retrieved, I don't do anything else.

Mauro

Il 11/11/2019 17:49, Eckenfels. Bernd ha scritto:
If you supply your own ConnectionFactory maybe this one does incorrectly construct the SSLSocket and uses the resolved address instead of the hostname. This will influence the SNI Signalling and the HostnameVerifier.

Gruss
Bernd
--
http://www.seeburger.com

Reply | Threaded
Open this post in threaded view
|

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

Peter Dettman-3
In reply to this post by mauromol
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