CODEWITHSUNDEEP
sslhttpsjetty
Garros JP
Garros JP

Reputation: 63

How to check that Jetty ssl configuration is working

I read the different answer to set an SSL and https connection with jetty. I follow all the steps and when I launch jetty I have in the logs :

jetty9[31330]: 2023-06-13 16:45:40.260:INFO:oejs.AbstractConnector:main: Started ServerConnector@7668d560{SSL,[ssl, alpn, h2, http/1.1]}{0.0.0.0:8443}

So it's seems ok. But if I try a GET request with insmonia in https I got an SSL_ERROR in the log I see :

16:47:38.179:qtp1715998167-27 OPENED ALPNServerConnection@b2904c::DecryptedEndPoint@3499d391{:54855<->:8443,OPEN,fill=-,flush=-,to=1/30000} 16:47:38.212:qtp1715998167-15 CLOSED ALPNServerConnection@b2904c::DecryptedEndPoint@3499d391{:54855<->:8443,CLOSED,fill=-,flush=-,to=31/30000} 16:47:38.212:qtp1715998167-15 CLOSED SslConnection@d0b4ffc::SocketChannelEndPoint@297abdf1{/:54855<->:8443,CLOSED,fill=-,flush=-,to=0/30000}{io=1/1,kio=-1,kro=-1}->SslConnection@d0b4ffc{NOT_HANDSHAKING,eio=-1/-1,di=-1,fill=IDLE,flush=IDLE}~>DecryptedEndPoint@3499d391{/:54855<->:8443,CLOSED,fill=-,flush=-,to=31/30000}=>ALPNServerConnection@b2904c

And if I launch the command keytool -printcert -sslserver 0.0.0.0:8443 -v I have :

java.lang.Exception: No certificate from the SSL server at java.base/sun.security.tools.keytool.Main.doPrintCert(Main.java:2736) at java.base/sun.security.tools.keytool.Main.doCommands(Main.java:1238) at java.base/sun.security.tools.keytool.Main.run(Main.java:397) at java.base/sun.security.tools.keytool.Main.main(Main.java:390) Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131) at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:307) at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:285) at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:180) at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) at java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:567) at java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:168) at java.base/sun.security.provider.certpath.ssl.SSLServerCertStore.engineGetCertificates(SSLServerCertStore.java:109) at java.base/java.security.cert.CertStore.getCertificates(CertStore.java:152) at java.base/sun.security.tools.keytool.Main.doPrintCert(Main.java:2725)

But certificates seems installed as the command sudo keytool -list -v -keystore etc/keystore as I have one entry that matches my ssl certificate.

If any one has an idea of what I missed ?

Upvotes: 0

Views: 278

Answers (1)

Joakim Erdfelt
Joakim Erdfelt

Reputation: 49545

Use the Jetty Server Dump features to see your running configuration.

Double check that your keystore is sane, valid for your version of Java, and is seen by Jetty.

Don't forget, make sure your keystore is valid for the version of Java you are using (not Jetty).
The wrong certificate type, or size, can impact your ability to use that certificate from Java's point of view.

The keytool that ships with your version of Java will produce notices and warnings telling you if your keystore is valid for that version of java. (fix any notices or warnings before attempting to use it with Jetty)

For specific on what's supported on what version of Java, see https://www.java.com/en/jre-jdk-cryptoroadmap.html

Lastly, make sure your SSL configuration on Jetty (includes/excludes of cipher suites, protocols) match what is available on your version of Java.

Of Special Note: IBM JVMs are known to have issues, as they don't follow RFC spec naming nor the OpenJDK standard naming for cipher suites. Putting an extraordinary burden on you to be ultra specific in your include/exclude configuration for it to work properly (and exposing you to many vulnerable cipher suites)

Upvotes: 0

Related Questions