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
On Mon, 17 Dec 2018 at 22:17, Silvio Bierman
<[email protected] <mailto:[email protected]>> wrote:
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
[email protected] <mailto:[email protected]>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
--
Greg Wilkins <[email protected] <mailto:[email protected]>> CTO
http://webtide.com
_______________________________________________
jetty-users mailing list
[email protected]
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
[email protected]
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
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
