Hi,
We've hit the same issue using the maven jetty plugin after upgrading from Jetty v9.2.10 to v9.4.2 due to a new "jetty-ssl-context.xml" file which the ssl module now loads when using start.ini, and which was missing from the list of JettyXml files we configure the jetty plugin with. This meant that the jetty-https.xml wasn't able to get an sslContextFactory, and failed on each HTTPS request, I suppose because it had no identity to present to the client. We found that out with the jetty dump tool (https://www.eclipse.org/jetty/documentation/current/jetty-dump-tool.html), which showed that our SslContextFactory had both keystore and truststore to null where they previously appeared with their full path (shortened to keystore_path and truststore_path in the example below) : ....snip.... += ServerConnector@1c5a1142{SSL-http/1.1}{0.0.0.0:8443} - STARTED | +~ org.eclipse.jetty.maven.plugin.JettyServer@69fa24d7 - STARTED | +~ qtp1491807845{STARTED,10<=10<=200,i=4,q=0} - STARTED | +~ org.eclipse.jetty.util.thread.ScheduledExecutorScheduler@8a246a7 - STARTED | +- org.eclipse.jetty.io.ArrayByteBufferPool@7f89606d | += SslConnectionFactory@1e3622e1{SSL-http/1.1} - STARTED | | += SslContextFactory@7f2494bb(keystore_path,truststore_path) - STARTED | += HttpConnectionFactory@75a8e29f{HTTP/1.1} - STARTED | | +- HttpConfiguration@41967e4f{32768/8192,8192/8192,https://:8443,[SecureRequestCustomizer@6e987db6]} ....snip.... We later hit another issue related to the lack of default value for the new jetty.sslContext.trustStoreType property in the jetty-ssl-context.xml file, which lead to NPEs when the truststore was being loaded. Now that we've added the jetty-ssl-context.xml file and set the jetty.sslContext.trustStoreType to JKS it's working just fine, so I'd suggest looking into how your keystore and truststore are configured when you add the HTTPS connector to your server. Xavier BRUGGHEMAN ________________________________ De : [email protected] <[email protected]> de la part de Simone Bordet <[email protected]> Envoyé : dimanche 26 février 2017 15:06:34 À : JETTY user mailing list Objet : Re: [jetty-users] ERR_SSL_VERSION_OR_CIPHER_MISMATCH Hi, On Sat, Feb 25, 2017 at 1:56 PM, Lou DeGenaro <[email protected]> wrote: > It probably should help, but didn't. > > I've now switched to IBM JDK, for reasons of availability of security > policies. > > bash-4.1$ /users/degenaro/install/ibm-java-x86_64-80/bin/java -version > java version "1.8.0" > Java(TM) SE Runtime Environment (build pxa6480sr4fp1-20170215_01(SR4 FP1)) > IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References > 20170209_336038 (JIT enabled, AOT enabled) > J9VM - R28_20170209_0201_B336038 > JIT - tr.r14.java.green_20170125_131456 > GC - R28_20170209_0201_B336038_CMPRSS > J9CL - 20170209_336038) > JCL - 20170215_01 based on Oracle jdk8u121-b13 > > In /users/degenaro/install/ibm-java-x86_64-80/jre/lib/security I installed > local_policy.jar and US_export_policy.jar comprising: > > bash-4.1$ cat default_local.policy > // Country-specific policy file for countries with no limits on crypto > strength. > grant é > // There is no restriction to any algorithms. > permission javax.crypto.CryptoAllPermission; > è; > > bash-4.1$ cat default_US_export.policy > // Manufacturing policy file. > grant é > // There is no restriction to any algorithms. > permission javax.crypto.CryptoAllPermission; > è; > > I launch the Jetty sever: > > /users/degenaro/install/ibm-java-x86_64-80/bin/java -jar > /users/degenaro/jetty/start.jar -Djavax.net.debug=all > > I visit via https + 8443 using Chromium, and on the Jetty console I see: > > 2017-02-25 07:34:18.345:INFO:oejsh.ContextHandler:main: Started > o.e.j.w.WebAppContextà-494073ddé/test,file:///users1/degenaro/install/sandbox/webapps/test/,AVAILABLEèé/testè > 2017-02-25 07:34:18.375:INFO:oejs.AbstractConnector:main: Started > ServerConnectorà4a3b91daéHTTP/1.1,°http/1.1§èé0.0.0.0:8080è > 2017-02-25 07:34:18.407:INFO:oejus.SslContextFactory:main: > x509=X509àdfac8979(jetty,h=°§,w=°§) for > SslContextFactoryàfc940f90(file:///users1/degenaro/install/sandbox/etc/keystore,file:///users1/degenaro/install/sandbox/etc/keystore) > adding as trusted cert: > <cert info> > Algorithm: RSA; Serial number: 0x7866 > Valid from Thu Feb 18 00:00:00 EST 2016 until Sat Feb 16 23:59:59 EST 2019 > > Installed Providers = > IBMJSSE2 > IBMJCE > IBMJGSSProvider > IBMCertPath > IBMSASL > IBMXMLCRYPTO > IBMXMLEnc > IBMSPNEGO > SUN > SSLContextImpl: Using X509ExtendedKeyManager com.ibm.jsse2.aw > SSLContextImpl: Using X509TrustManager com.ibm.jsse2.aA > JsseJCE: Using SecureRandom IBMSecureRandom from provider IBMJCE version > 1.8 > trigger seeding of SecureRandom > done seeding SecureRandom > IBMJSSE2 will enable CBC protection > JsseJCE: Using SecureRandom IBMSecureRandom from provider IBMJCE version > 1.8 > JsseJCE: Using KeyAgreement ECDH from provider IBMJCE version 1.8 > JsseJCE: Using signature SHA1withECDSA from provider TBD via init > JsseJCE: Using signature NONEwithECDSA from provider TBD via init > JsseJCE: Using KeyFactory EC from provider IBMJCE version 1.8 > JsseJCE: Using KeyPairGenerator EC from provider TBD via init > JsseJce: EC is available > JsseJCE: Using cipher AES/GCM/NoPadding from provider TBD via init > CipherBox: Using cipher AES/GCM/NoPadding from provider from init IBMJCE > version 1.8 > JsseJCE: Using cipher AES/CBC/NoPadding from provider TBD via init > CipherBox: Using cipher AES/CBC/NoPadding from provider from init IBMJCE > version 1.8 > jdk.tls.client.protocols is defined as null > SSLv3 protocol was requested but was not enabled > SSLv3 protocol was requested but was not enabled > SUPPORTED: °TLSv1, TLSv1.1, TLSv1.2§ > SERVER_DEFAULT: °TLSv1, TLSv1.1, TLSv1.2§ > CLIENT_DEFAULT: °TLSv1, TLSv1.1, TLSv1.2§ > IBMJSSE2 will enable CBC protection > Using SSLEngineImpl. > 2017-02-25 07:34:19.273:INFO:oejs.AbstractConnector:main: Started > ServerConnectorà4dcc4f21éSSL,°ssl, http/1.1§èé0.0.0.0:8443è > 2017-02-25 07:34:19.276:INFO:oejs.Server:main: Started à3044ms > Finalizer thread, called close() > Finalizer thread, called closeInternal(true) > Using SSLEngineImpl. > Finalizer thread, called closeSocket(true) > Using SSLEngineImpl. > IBMJSSE2 will allow RFC 5746 renegotiation per com.ibm.jsse2.renegotiate set > to none or default > IBMJSSE2 will not require renegotiation indicator during initial handshake > per com.ibm.jsse2.renegotiation.indicator set to OPTIONAL or default taken > IBMJSSE2 will not perform identity checking against the peer cert check > during renegotiation per com.ibm.jsse2.renegotiation.peer.cert.check set to > OFF or default > IBMJSSE2 will allow client initiated renegotiation per > jdk.tls.rejectClientInitiatedRenegotiation set to FALSE or default > > Is initial handshake: true > Ignoring unsupported cipher suite: SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 > Ignoring unsupported cipher suite: SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA384 > Ignoring unsupported cipher suite: SSL_RSA_WITH_AES_256_CBC_SHA256 > Ignoring unsupported cipher suite: SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 > Ignoring unsupported cipher suite: SSL_ECDH_RSA_WITH_AES_256_CBC_SHA384 > Ignoring unsupported cipher suite: SSL_DHE_RSA_WITH_AES_256_CBC_SHA256 > Ignoring unsupported cipher suite: SSL_DHE_DSS_WITH_AES_256_CBC_SHA256 > Ignoring unsupported cipher suite: SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 > Ignoring unsupported cipher suite: SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA256 > Ignoring unsupported cipher suite: SSL_RSA_WITH_AES_128_CBC_SHA256 > Ignoring unsupported cipher suite: SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 > Ignoring unsupported cipher suite: SSL_ECDH_RSA_WITH_AES_128_CBC_SHA256 > Ignoring unsupported cipher suite: SSL_DHE_RSA_WITH_AES_128_CBC_SHA256 > Ignoring unsupported cipher suite: SSL_DHE_DSS_WITH_AES_128_CBC_SHA256 > Ignoring unsupported cipher suite: SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 > Ignoring unsupported cipher suite: SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 > Ignoring unsupported cipher suite: SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384 > Ignoring unsupported cipher suite: SSL_RSA_WITH_AES_256_GCM_SHA384 > Ignoring unsupported cipher suite: SSL_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 > Ignoring unsupported cipher suite: SSL_ECDH_RSA_WITH_AES_256_GCM_SHA384 > Ignoring unsupported cipher suite: SSL_DHE_DSS_WITH_AES_256_GCM_SHA384 > Ignoring unsupported cipher suite: SSL_DHE_RSA_WITH_AES_256_GCM_SHA384 > Ignoring unsupported cipher suite: SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > Ignoring unsupported cipher suite: SSL_RSA_WITH_AES_128_GCM_SHA256 > Ignoring unsupported cipher suite: SSL_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 > Ignoring unsupported cipher suite: SSL_ECDH_RSA_WITH_AES_128_GCM_SHA256 > Ignoring unsupported cipher suite: SSL_DHE_RSA_WITH_AES_128_GCM_SHA256 > Ignoring unsupported cipher suite: SSL_DHE_DSS_WITH_AES_128_GCM_SHA256 > °Raw read§: length = 5 > 0000: 16 03 01 00 bc ..... > > °Raw read§: length = 188 > ... So. A) you have weird logs of "> JsseJCE: Using signature SHA1withECDSA from provider TBD via init" The provider "TBD" looks weird, "To Be Defined" ? B) the logs in the form of > Ignoring unsupported cipher suite: SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 mean that you don't have those ciphers available. In fact, that is a non-standard name because it starts with "SSL_", while it should start with "TLS_" (https://www.ietf.org/rfc/rfc5289.txt). You should ask IBM about those 2. It's a JVM configuration problem more than a Jetty one. -- Simone Bordet ---- http://cometd.org http://webtide.com Developer advice, training, services and support from the Jetty & CometD experts. _______________________________________________ jetty-users mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users IPC ranks #33 in IDC's Top 100 FinTech DISCLAIMER: This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unintended recipients are prohibited from taking action on the basis of information in this e-mail. E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. If you are not comfortable with the risks associated with e-mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the right, to the extent and under circumstances permitted by applicable law, to retain, monitor and intercept e-mail messages to and from its systems.
_______________________________________________ jetty-users mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
