[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[jetty-users] No subject alternative names matching IP address x.x.x.x found, but should use hostname
|
Hi folks,
I’m having trouble upgrading one of our apps from 9.4.10 to the latest jetty; it’s started rejecting the client certificate with the message "No subject alternative names matching IP address 172.18.0.7 found"
The testing setup is that I have two java apps in docker mutually authenticating with certificates. I need the certificates to use hostnames, not ip addresses, however something about the connection made using jetty 9.4.15 means that it is using the ip address to validate the client cert rather than the domain name.
Is this likely to be a bug? Is there something I can do to avoid the issue? I’m not really sure how Jetty determines the remote peer, but it seems to have changed since 9.4.10.v20180503
TIA
Server:
Open JDK 1.8
Jetty 9.4.15.v20190215
Client
`curl -vE cert.pem:password -k https://swipe-backend:8181/swipe-api` (for testing)
TLSv1.2 according to debug output
Also fails with java client
Example exception
FINE: EXCEPTION: java.security.cert.CertificateException: No subject alternative names matching IP address 172.18.0.7 found
FINE: EXCEPTION: sun.security.util.HostnameChecker.matchIP(HostnameChecker.java:168)
FINE: EXCEPTION: sun.security.util.HostnameChecker.match(HostnameChecker.java:94)
FINE: EXCEPTION: sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:455)
FINE: EXCEPTION: sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:436)
FINE: EXCEPTION: sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:252)
FINE: EXCEPTION: sun.security.ssl.X509TrustManagerImpl.checkClientTrusted(X509TrustManagerImpl.java:130)
FINE: EXCEPTION: sun.security.ssl.ServerHandshaker.clientCertificate(ServerHandshaker.java:1986)
FINE: EXCEPTION: sun.security.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:237)
FINE: EXCEPTION: sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052)
FINE: EXCEPTION: sun.security.ssl.Handshaker$1.run(Handshaker.java:992)
FINE: EXCEPTION: sun.security.ssl.Handshaker$1.run(Handshaker.java:989)
FINE: EXCEPTION: java.security.AccessController.doPrivileged(Native Method)
FINE: EXCEPTION: sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1467)
FINE: EXCEPTION: org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.fill(SslConnection.java:527)
FINE: EXCEPTION: org.eclipse.jetty.server.HttpConnection.fillRequestBuffer(HttpConnection.java:340)
FINE: EXCEPTION: org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:250)
FINE: EXCEPTION: org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
FINE: EXCEPTION: org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
FINE: EXCEPTION: org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:427)
FINE: EXCEPTION: org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:321)
FINE: EXCEPTION: org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159)
FINE: EXCEPTION: org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
FINE: EXCEPTION: org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
FINE: EXCEPTION: org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)
— David
