Hi Greg,
I have done some extensive testing, logging etc. to try and figure
out what is going wrong here. I managed to get quite some stack
traces but only to find out that the error occurs on the client
side, which is in all cases a Java11 process using the standard
HttpURLConnection to evaluate a URL that targets a Jetty 9.4.14
server that is embedded inside again a Java11 process. In many cases
they are the same process, ie. the client code runs as part of a
web-application that sometimes communicates with itself. But in also
quite some cases they are separate processes running on different
servers. Since the error does not show up on the server side I have
no stack traces that contain anything familiar to you, so I will
fully understand if you can not help me here.
Invariably this is what it looks like:
javax.net.ssl.SSLHandshakeException: No subject alternative DNS name
matching xxx.yyy.com found.
at
java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)
at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:321)
at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264)
at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:259)
at
java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.checkServerCerts(CertificateMessage.java:1329)
at
java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.onConsumeCertificate(CertificateMessage.java:1204)
at
java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.consume(CertificateMessage.java:1151)
at
java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
...
Caused by: java.security.cert.CertificateException: No subject
alternative DNS name matching tangram.jambo-mobile.com found.
at
java.base/sun.security.util.HostnameChecker.matchDNS(HostnameChecker.java:207)
at
java.base/sun.security.util.HostnameChecker.match(HostnameChecker.java:98)
at
java.base/sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:459)
at
java.base/sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:434)
at
java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:233)
at
java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:129)
at
java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.checkServerCerts(CertificateMessage.java:1313)
... 100 more
I am a grateful user of Jetty SNI support with about 300
certificates (not counting intermediates) in my keystore, which is
currently still in JKS format.
What dazzles me is that everything works flawlessly most of the
time. But then something triggers this on one of our servers and for
a period of time it will keep reoccurring for one of the domain
names. During that period people are using the web-application
through their browser without any issues unless they try to do
something that depends on a self-served request (like having the
system send out an email which lets JavaMail evaluate a URL that
lands in the same application) which then fails as subscribed. This
makes me suspect my server goes into some kind of state that makes
it hand out the wrong certificates, incomplete chains or even no
certificate at all. But then again, I am just guessing here. Perhaps
a have some rotten certificate in my store that messes up the SNI
process.
Jetty version: jetty-distribution-9.4.14.v20181114, Java version:
OpenJDK 64-Bit Server VM (build 11.0.1+13-Ubuntu-2ubuntu1, mixed
mode, sharing), OS: Ubuntu 18.10 server (for both client and server
processes).
If anyone can give me a pointer I would be very grateful.
Kind regards,
Silvio
On 17-12-18 21:48, Greg Wilkins wrote:
Silvio,
no bell ringing.
Any chance of a stack trace... it may be obvious, but as
a guide to walk through the code it may make us see
something.
Of course if you could run with -Djavax.net.debug=ssl (or
a filtered version of that) would be even more helpful.
regards
Hello all,
I am using Jetty 9.4.14 on multiple servers. On one of my
servers I get
heaps of SSLHandshakeException errors. They occur with
different domain
names for which I do have valid certificates in my keystore. I
am using
Jetty SNI and have dozens of certificates in my keystore. I
use the same
keystore (JKS format) on all my servers but only one server
shows this
behaviour. Strangely enough, these errors only occur with
requests that
are sent from Java applications, either from the server
process itself
or from one of my other servers.
This started occurring about a week ago, long after I upgraded
to Jetty
9.4.14. The only thing that changed in the meantime is the
SSL-keystore
that has grown.
Does this ring any bells? Has anyone experienced similar
problems? I
have tried restarting the process, server etc. but that only
helps for a
short while.
Any pointers would be welcome.
Kind regards,
Silvio
_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
--
_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
|