Hi all,
One addition: this morning I replaced the keystore file on one of
the servers because some almost-expired certificates had been
updated and subsequently triggered a SslContextFactory.reload
through the application. Within 15 minutes the logging showed about
two dozen failed requests. Then it silently went away. May be a
coincidence of course.
Silvio
On 16-01-19 12:30, Silvio Bierman
wrote:
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
_______________________________________________
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
|
