Hi all,
Sorry for spamming but I have another observation after further log
file analysis: the problem only seems to happen with hostnames that
are covered by wildcard certificates. I noticed some comments about
a change to Jetty regarding SNI behavior and wildcard certs shortly
before the release of 9.4.14. I know I am grasping at straws here
but this all started for us after switching to 9.4.14 (and JDK11 at
almost the same time...) but to narrow things down I will:
- run one server on JDK9 and Jetty 9.4.14
- run another with JDK11 and Jetty 9.4.13
and see for a while if either of those does not cause problems. If
so I will post the results here.
For now I have disabled client side certificate validation for all
requests that are sent to the application itself. This definitely
suppresses the issue, which is not surprising of course. For now
this is probably harmless.
Cheers,
Silvio
On 16-01-19 12:53, Silvio Bierman
wrote:
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
_______________________________________________
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
|
