Re: [jetty-users] Keystore Problems
Thanks, Scott.
Using Scott's example command, but modified with our specifics, generates the
PKCS12 keystore, but Jetty throws the same exception on startup:
2020-05-26 13:56:29,793 - INFO [org.eclipse.jetty.server.AbstractConnector:331]
- Started ServerConnector@1fdf8aa4{HTTP/1.1, (http/1.1)}{127.0.0.1:8080}
2020-05-26 13:56:29,794 - WARN [org.eclipse.jetty.xml.XmlConfiguration:1938] -
java.security.PrivilegedActionException: null
at java.base/java.security.AccessController.doPrivileged(Native Method)
at
org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1878)
Caused by: java.security.UnrecoverableKeyException: Get Key failed: Given final
block not properly padded. Such issues can arise if a bad key is used during
decryption.
at
java.base/sun.security.pkcs12.PKCS12KeyStore.engineGetKey(PKCS12KeyStore.java:462)
keytool seems okay with the keystore. Omitting all the details, but it shows
the new SSL certificate, followed by the intermediate/CA certificates in the
correct order:
/tmp:> keytool -list -keystore xyz.p12 -v
Enter keystore password:
Keystore type: PKCS12
Keystore provider: SUN
Your keystore contains 1 entry
Alias name: 1
Creation date: May 26, 2020
Entry type: PrivateKeyEntry
Certificate chain length: 4
Certificate[1]:
David Fuhs
Information Security Office
California State University, Chico
df...@csuchico.edu
530-898-4852
From: jetty-users-boun...@eclipse.org on
behalf of Cantor, Scott
Sent: Tuesday, May 26, 2020 1:40 PM
To: JETTY user mailing list
Subject: Re: [jetty-users] Keystore Problems
On 5/26/20, 4:34 PM, "jetty-users-boun...@eclipse.org on behalf of David C
Fuhs" wrote:
> What I really want is quite simple: a series of commands that will take as
> input a private key, a new SSL certificate, and a
> series of intermediate/CA certificates and create a PKCS12 keystore that
> Jetty can use.
openssl pkcs12 -export -out file.p12 -inkey private.key -in public.crt
-certfile chain.crt
There are lot of varied ways to feed the certs in, but I've used a model where
-in is just the EE cert and -certfile has the concat'd chain of the rest.
-- Scott
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Keystore Problems
On 5/26/20, 4:34 PM, "jetty-users-boun...@eclipse.org on behalf of David C Fuhs" wrote: > What I really want is quite simple: a series of commands that will take as > input a private key, a new SSL certificate, and a > series of intermediate/CA certificates and create a PKCS12 keystore that > Jetty can use. openssl pkcs12 -export -out file.p12 -inkey private.key -in public.crt -certfile chain.crt There are lot of varied ways to feed the certs in, but I've used a model where -in is just the EE cert and -certfile has the concat'd chain of the rest. -- Scott ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Keystore Problems
Thanks Simone, I will give Keystore Explorer and try and report back. What I really want is quite simple: a series of commands that will take as input a private key, a new SSL certificate, and a series of intermediate/CA certificates and create a PKCS12 keystore that Jetty can use. All permutations, combinations, and attempts thus far over several days results in a keystore that throws the UnrecoverableKeyException. Those attempts include: starting with a key that has/does not have a password, including/not including the key at the beginning of the file containing the SSL certificate and intermediate certificates, starting by creating a JKS keystore then converting it to PKCS12, starting by creating a PKCS12 keystore directly, adding/modifying a keystore password after creating the PKCS12 keystore, and probably several more I forgot. This morning's attempts involved cutting and pasting example commands directly from the Jetty documentation, then modifying the specifics. One would expect that even though I apparently got on a slow horse, I would eventually stumble into some combination that would work, but it seems quite elusive. David Fuhs Information Security Office California State University, Chico df...@csuchico.edu 530-898-4852 From: jetty-users-boun...@eclipse.org on behalf of Simone Bordet Sent: Tuesday, May 26, 2020 11:18 AM To: JETTY user mailing list Subject: Re: [jetty-users] Keystore Problems Hi, On Tue, May 26, 2020 at 8:07 PM David C Fuhs wrote: > > To generate the private key: > openssl genrsa 4096 > new_host.key > > To combine the SSL certificate plus CA certificates into one file: > cat ssl_cert interm_certs > combined_certs > Results in a file with the SSL certificate first, followed by the > intermediate certificates, with the root CA certificate last in the file. > > Stack traces follow, the first is using the JKS version of the keystore, the > second with the PKCS12 version of the keystore. Can you open the keyStores using: https://keystore-explorer.org/ If you cannot, then the keyStores are wrong. There is no need to use the JKS format anymore, keep the keyStores in PKCS12. Make sure that you are using a keyStore password only (not a keyManager password), unless you really want to. If you have a keyManager password, then you have to configure Jetty with it. -- Simone Bordet http://cometd.org http://webtide.com Developer advice, training, services and support from the Jetty & CometD experts. ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Keystore Problems
Hi, On Tue, May 26, 2020 at 8:07 PM David C Fuhs wrote: > > To generate the private key: > openssl genrsa 4096 > new_host.key > > To combine the SSL certificate plus CA certificates into one file: > cat ssl_cert interm_certs > combined_certs > Results in a file with the SSL certificate first, followed by the > intermediate certificates, with the root CA certificate last in the file. > > Stack traces follow, the first is using the JKS version of the keystore, the > second with the PKCS12 version of the keystore. Can you open the keyStores using: https://keystore-explorer.org/ If you cannot, then the keyStores are wrong. There is no need to use the JKS format anymore, keep the keyStores in PKCS12. Make sure that you are using a keyStore password only (not a keyManager password), unless you really want to. If you have a keyManager password, then you have to configure Jetty with it. -- Simone Bordet http://cometd.org http://webtide.com Developer advice, training, services and support from the Jetty & CometD experts. ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Keystore Problems
at org.eclipse.jetty.util.ssl.SslContextFactory.doStart(SslContextFactory.java:245) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72) at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169) at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117) at org.eclipse.jetty.server.SslConnectionFactory.doStart(SslConnectionFactory.java:97) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72) at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169) at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117) at org.eclipse.jetty.server.AbstractConnector.doStart(AbstractConnector.java:321) at org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:81) at org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:231) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72) at org.eclipse.jetty.server.Server.doStart(Server.java:385) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72) at org.eclipse.jetty.xml.XmlConfiguration.lambda$main$1(XmlConfiguration.java:1929) ... 2 common frames omitted Caused by: javax.crypto.BadPaddingException: Given final block not properly padded. Such issues can arise if a bad key is used during decryption. at java.base/com.sun.crypto.provider.CipherCore.unpad(CipherCore.java:975) at java.base/com.sun.crypto.provider.CipherCore.fillOutputBuffer(CipherCore.java:1056) at java.base/com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:853) at java.base/com.sun.crypto.provider.PKCS12PBECipherCore.implDoFinal(PKCS12PBECipherCore.java:408) at java.base/com.sun.crypto.provider.PKCS12PBECipherCore$PBEWithSHA1AndDESede.engineDoFinal(PKCS12PBECipherCore.java:440) at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2202) at java.base/sun.security.pkcs12.PKCS12KeyStore.lambda$engineGetKey$0(PKCS12KeyStore.java:406) at java.base/sun.security.pkcs12.PKCS12KeyStore$RetryWithZero.run(PKCS12KeyStore.java:295) at java.base/sun.security.pkcs12.PKCS12KeyStore.engineGetKey(PKCS12KeyStore.java:400) ... 25 common frames omitted 2020-05-26 David Fuhs Information Security Office California State University, Chico df...@csuchico.edu 530-898-4852 From: jetty-users-boun...@eclipse.org on behalf of Joakim Erdfelt Sent: Tuesday, May 26, 2020 10:49 AM To: JETTY user mailing list Subject: Re: [jetty-users] Keystore Problems How were new_host.key and combined_certs created? Also, can you provide the complete stacktraces? Joakim Erdfelt / joa...@webtide.com<mailto:joa...@webtide.com> On Tue, May 26, 2020 at 12:44 PM David C Fuhs mailto:df...@csuchico.edu>> wrote: Good morning all: Red Hat Enterprise Linux Server release 7.8 (Maipo) jetty-distribution-9.4.28.v20200408 java-11-openjdk-11.0.7.10-4.el7_8.x86_64 jetty.ssl.port=8443 Generated a new private key (without a password) using openssl. Generated a certificate request. Received new SSL certificate, plus intermediate and CA certificates. The goal: create a new keystore (preferably PKCS12) that works with Jetty. Following instructions at: https://www.eclipse.org/jetty/documentation/current/configuring-ssl.html Combined the new SSL certificate + intermediate certificates + root certificate in one file in that order (combined_certs). openssl pkcs12 -export -inkey new_host.key -in combined_certs -out abc.pkcs12 Import into keystore: keytool -importkeystore -srckeystore abc.pkcs12 -srckeystore PKCS12 -destkeystore abc.jks Followed recommendation to convert JKS to PKCS12: keytool -importkeystore -srckeystore abc.jks -destkeystore abc.p12 -deststoretype pkcs12 The commands above all complete successfully (prompts for passphrases and passphrase itself omitted). At this point, we have two keystores, one JKS and one PCKS12: However, Jetty fails to start correctly with either. Startup error when using the JKS keystore: PrivilegedActionException: null Caused by: java.security.UnrecoverableKeyException: Cannot recover key Startup error when using the PKCS12 keystore: PrivilegedActionException: null Caused by: java.security.UnrecoverableKeyException: Get Key failed: Given final block not properly padded. Such issues arise if a bad key is used during decryption. Also ran the same processes as above, but with the private key added first to the file containing the certificates, but with similar Jetty failures on startup. What am I missing? Exactly what steps are required to get from a valid RSA private key + SSL certificate + intermediate and CA certificates (generated by openssl) to a worki
Re: [jetty-users] Keystore Problems
How were new_host.key and combined_certs created? Also, can you provide the complete stacktraces? Joakim Erdfelt / joa...@webtide.com On Tue, May 26, 2020 at 12:44 PM David C Fuhs wrote: > Good morning all: > > Red Hat Enterprise Linux Server release 7.8 (Maipo) > jetty-distribution-9.4.28.v20200408 > java-11-openjdk-11.0.7.10-4.el7_8.x86_64 > jetty.ssl.port=8443 > > Generated a new private key (without a password) using openssl. > Generated a certificate request. > Received new SSL certificate, plus intermediate and CA certificates. > > The goal: create a new keystore (preferably PKCS12) that works with Jetty. > > Following instructions at: > https://www.eclipse.org/jetty/documentation/current/configuring-ssl.html > > Combined the new SSL certificate + intermediate certificates + root > certificate in one file in that order (combined_certs). > > openssl pkcs12 -export -inkey new_host.key -in combined_certs -out > abc.pkcs12 > > Import into keystore: > > keytool -importkeystore -srckeystore abc.pkcs12 -srckeystore PKCS12 > -destkeystore abc.jks > > Followed recommendation to convert JKS to PKCS12: > > keytool -importkeystore -srckeystore abc.jks -destkeystore abc.p12 > -deststoretype pkcs12 > > The commands above all complete successfully (prompts for passphrases and > passphrase itself omitted). > > At this point, we have two keystores, one JKS and one PCKS12: > > However, Jetty fails to start correctly with either. > > Startup error when using the JKS keystore: > PrivilegedActionException: null > Caused by: java.security.UnrecoverableKeyException: Cannot recover key > > Startup error when using the PKCS12 keystore: > PrivilegedActionException: null > Caused by: java.security.UnrecoverableKeyException: Get Key failed: Given > final block not properly padded. Such issues arise if a bad key is used > during decryption. > > Also ran the same processes as above, but with the private key added first > to the file containing the certificates, but with similar Jetty failures on > startup. > > What am I missing? > > Exactly what steps are required to get from a valid RSA private key + SSL > certificate + intermediate and CA certificates (generated by openssl) to a > working PKCS12 keystore? > > Thanks in advance. > > David Fuhs > Information Security Office > California State University, Chico > df...@csuchico.edu > 530-898-4852 > > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
[jetty-users] Keystore Problems
Good morning all: Red Hat Enterprise Linux Server release 7.8 (Maipo) jetty-distribution-9.4.28.v20200408 java-11-openjdk-11.0.7.10-4.el7_8.x86_64 jetty.ssl.port=8443 Generated a new private key (without a password) using openssl. Generated a certificate request. Received new SSL certificate, plus intermediate and CA certificates. The goal: create a new keystore (preferably PKCS12) that works with Jetty. Following instructions at: https://www.eclipse.org/jetty/documentation/current/configuring-ssl.html Combined the new SSL certificate + intermediate certificates + root certificate in one file in that order (combined_certs). openssl pkcs12 -export -inkey new_host.key -in combined_certs -out abc.pkcs12 Import into keystore: keytool -importkeystore -srckeystore abc.pkcs12 -srckeystore PKCS12 -destkeystore abc.jks Followed recommendation to convert JKS to PKCS12: keytool -importkeystore -srckeystore abc.jks -destkeystore abc.p12 -deststoretype pkcs12 The commands above all complete successfully (prompts for passphrases and passphrase itself omitted). At this point, we have two keystores, one JKS and one PCKS12: However, Jetty fails to start correctly with either. Startup error when using the JKS keystore: PrivilegedActionException: null Caused by: java.security.UnrecoverableKeyException: Cannot recover key Startup error when using the PKCS12 keystore: PrivilegedActionException: null Caused by: java.security.UnrecoverableKeyException: Get Key failed: Given final block not properly padded. Such issues arise if a bad key is used during decryption. Also ran the same processes as above, but with the private key added first to the file containing the certificates, but with similar Jetty failures on startup. What am I missing? Exactly what steps are required to get from a valid RSA private key + SSL certificate + intermediate and CA certificates (generated by openssl) to a working PKCS12 keystore? Thanks in advance. David Fuhs Information Security Office California State University, Chico df...@csuchico.edu 530-898-4852 ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] keystore
fair enough, congrats at least :)
--
jesse mcconnell
jesse.mcconn...@gmail.com
On Wed, Mar 14, 2018 at 2:15 PM, Lou DeGenaro
wrote:
> Unfortunately no. I could only supply an IP address (which it seems is
> not allowed) and is only accessible internally anyway.
>
> Lou.
>
> On Wed, Mar 14, 2018 at 3:04 PM, Jesse McConnell <
> jesse.mcconn...@gmail.com> wrote:
>
>> That is an interesting nugget Lou, any chance you can report results from
>> here: https://www.ssllabs.com/ssltest/ ?
>>
>>
>>
>> --
>> jesse mcconnell
>> jesse.mcconn...@gmail.com
>>
>> On Wed, Mar 14, 2018 at 1:53 PM, Lou DeGenaro
>> wrote:
>>
>>> Looking here: https://www.ibm.com/support/kn
>>> owledgecenter/en/SSYKE2_8.0.0/com.ibm.java.security.componen
>>> t.80.doc/security-component/jsse2Docs/matchsslcontext_tls.html
>>>
>>> I added -Dcom.ibm.jsse2.overrideDefaultTLS=true to the launch of my
>>> Jetty server and much joy resulted.
>>>
>>> Lou.
>>>
>>> On Wed, Mar 14, 2018 at 2:45 PM, Lothar Kimmeringer
>>> wrote:
>>>
Am 14.03.2018 um 17:53 schrieb Silvio Bierman:
> Those are ciphers for the SSL protocol instead of TLS. You do not want
> to use those...
>
I'm not defending IBM here for their decision to follow the
NIH-principle.
The ciphers are for TLS, the session where this trace came from was an
OFTP2-connection that is restricted to TLS and was using TLSv1.2 for the
handshake:
OFTP TLS-ReceiveThread2 (Thread nr. 6, for server-socket listening on
address /x.x.x.x on port 6619), READ: TLSv1.2 Handshake, length = 181
JsseJCE: Using AlgorithmParameters EC from provider IBMJCE version 1.8
JsseJCE: Using AlgorithmParameters EC from provider IBMJCE version 1.8
JsseJCE: Using AlgorithmParameters EC from provider IBMJCE version 1.8
JsseJCE: Using AlgorithmParameters EC from provider IBMJCE version 1.8
*** ClientHello, TLSv1.2
RandomCookie: GMT: 1491538846 bytes = { 239, 0, 205, 234, 239, 135,
27, 62, 91, 187, 205, 216, 254, 230, 62, 170, 127, 69, 1, 60, 88, 75, 88,
14, 181, 116, 137, 40 }
Session ID: {}
Cipher Suites:
[...]
The corresponding Wireshark trace showed the cipher-list with the names
you're used to, so there really are no SSL-ciphers here, "just" a
different naming scheme.
Cheers, Lothar
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
>>>
>>>
>>> ___
>>> jetty-users mailing list
>>> jetty-users@eclipse.org
>>> To change your delivery options, retrieve your password, or unsubscribe
>>> from this list, visit
>>> https://dev.eclipse.org/mailman/listinfo/jetty-users
>>>
>>
>>
>> ___
>> jetty-users mailing list
>> jetty-users@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/jetty-users
>>
>
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/jetty-users
>
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] keystore
Unfortunately no. I could only supply an IP address (which it seems is not
allowed) and is only accessible internally anyway.
Lou.
On Wed, Mar 14, 2018 at 3:04 PM, Jesse McConnell
wrote:
> That is an interesting nugget Lou, any chance you can report results from
> here: https://www.ssllabs.com/ssltest/ ?
>
>
>
> --
> jesse mcconnell
> jesse.mcconn...@gmail.com
>
> On Wed, Mar 14, 2018 at 1:53 PM, Lou DeGenaro
> wrote:
>
>> Looking here: https://www.ibm.com/support/kn
>> owledgecenter/en/SSYKE2_8.0.0/com.ibm.java.security.componen
>> t.80.doc/security-component/jsse2Docs/matchsslcontext_tls.html
>>
>> I added -Dcom.ibm.jsse2.overrideDefaultTLS=true to the launch of my
>> Jetty server and much joy resulted.
>>
>> Lou.
>>
>> On Wed, Mar 14, 2018 at 2:45 PM, Lothar Kimmeringer
>> wrote:
>>
>>>
>>>
>>> Am 14.03.2018 um 17:53 schrieb Silvio Bierman:
>>>
Those are ciphers for the SSL protocol instead of TLS. You do not want
to use those...
>>>
>>> I'm not defending IBM here for their decision to follow the
>>> NIH-principle.
>>> The ciphers are for TLS, the session where this trace came from was an
>>> OFTP2-connection that is restricted to TLS and was using TLSv1.2 for the
>>> handshake:
>>>
>>> OFTP TLS-ReceiveThread2 (Thread nr. 6, for server-socket listening on
>>> address /x.x.x.x on port 6619), READ: TLSv1.2 Handshake, length = 181
>>> JsseJCE: Using AlgorithmParameters EC from provider IBMJCE version 1.8
>>> JsseJCE: Using AlgorithmParameters EC from provider IBMJCE version 1.8
>>> JsseJCE: Using AlgorithmParameters EC from provider IBMJCE version 1.8
>>> JsseJCE: Using AlgorithmParameters EC from provider IBMJCE version 1.8
>>> *** ClientHello, TLSv1.2
>>> RandomCookie: GMT: 1491538846 bytes = { 239, 0, 205, 234, 239, 135, 27,
>>> 62, 91, 187, 205, 216, 254, 230, 62, 170, 127, 69, 1, 60, 88, 75, 88, 14,
>>> 181, 116, 137, 40 }
>>> Session ID: {}
>>> Cipher Suites:
>>> [...]
>>>
>>> The corresponding Wireshark trace showed the cipher-list with the names
>>> you're used to, so there really are no SSL-ciphers here, "just" a
>>> different naming scheme.
>>>
>>>
>>>
>>> Cheers, Lothar
>>> ___
>>> jetty-users mailing list
>>> jetty-users@eclipse.org
>>> To change your delivery options, retrieve your password, or unsubscribe
>>> from this list, visit
>>> https://dev.eclipse.org/mailman/listinfo/jetty-users
>>>
>>
>>
>> ___
>> jetty-users mailing list
>> jetty-users@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/jetty-users
>>
>
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/jetty-users
>
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] keystore
That is an interesting nugget Lou, any chance you can report results from
here: https://www.ssllabs.com/ssltest/ ?
--
jesse mcconnell
jesse.mcconn...@gmail.com
On Wed, Mar 14, 2018 at 1:53 PM, Lou DeGenaro
wrote:
> Looking here: https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.
> 0/com.ibm.java.security.component.80.doc/security-component/jsse2Docs/
> matchsslcontext_tls.html
>
> I added -Dcom.ibm.jsse2.overrideDefaultTLS=true to the launch of my Jetty
> server and much joy resulted.
>
> Lou.
>
> On Wed, Mar 14, 2018 at 2:45 PM, Lothar Kimmeringer
> wrote:
>
>>
>>
>> Am 14.03.2018 um 17:53 schrieb Silvio Bierman:
>>
>>> Those are ciphers for the SSL protocol instead of TLS. You do not want
>>> to use those...
>>>
>>
>> I'm not defending IBM here for their decision to follow the NIH-principle.
>> The ciphers are for TLS, the session where this trace came from was an
>> OFTP2-connection that is restricted to TLS and was using TLSv1.2 for the
>> handshake:
>>
>> OFTP TLS-ReceiveThread2 (Thread nr. 6, for server-socket listening on
>> address /x.x.x.x on port 6619), READ: TLSv1.2 Handshake, length = 181
>> JsseJCE: Using AlgorithmParameters EC from provider IBMJCE version 1.8
>> JsseJCE: Using AlgorithmParameters EC from provider IBMJCE version 1.8
>> JsseJCE: Using AlgorithmParameters EC from provider IBMJCE version 1.8
>> JsseJCE: Using AlgorithmParameters EC from provider IBMJCE version 1.8
>> *** ClientHello, TLSv1.2
>> RandomCookie: GMT: 1491538846 bytes = { 239, 0, 205, 234, 239, 135, 27,
>> 62, 91, 187, 205, 216, 254, 230, 62, 170, 127, 69, 1, 60, 88, 75, 88, 14,
>> 181, 116, 137, 40 }
>> Session ID: {}
>> Cipher Suites:
>> [...]
>>
>> The corresponding Wireshark trace showed the cipher-list with the names
>> you're used to, so there really are no SSL-ciphers here, "just" a
>> different naming scheme.
>>
>>
>>
>> Cheers, Lothar
>> ___
>> jetty-users mailing list
>> jetty-users@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/jetty-users
>>
>
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/jetty-users
>
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] keystore
Looking here:
https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java.security.component.80.doc/security-component/jsse2Docs/matchsslcontext_tls.html
I added -Dcom.ibm.jsse2.overrideDefaultTLS=true to the launch of my Jetty
server and much joy resulted.
Lou.
On Wed, Mar 14, 2018 at 2:45 PM, Lothar Kimmeringer
wrote:
>
>
> Am 14.03.2018 um 17:53 schrieb Silvio Bierman:
>
>> Those are ciphers for the SSL protocol instead of TLS. You do not want to
>> use those...
>>
>
> I'm not defending IBM here for their decision to follow the NIH-principle.
> The ciphers are for TLS, the session where this trace came from was an
> OFTP2-connection that is restricted to TLS and was using TLSv1.2 for the
> handshake:
>
> OFTP TLS-ReceiveThread2 (Thread nr. 6, for server-socket listening on
> address /x.x.x.x on port 6619), READ: TLSv1.2 Handshake, length = 181
> JsseJCE: Using AlgorithmParameters EC from provider IBMJCE version 1.8
> JsseJCE: Using AlgorithmParameters EC from provider IBMJCE version 1.8
> JsseJCE: Using AlgorithmParameters EC from provider IBMJCE version 1.8
> JsseJCE: Using AlgorithmParameters EC from provider IBMJCE version 1.8
> *** ClientHello, TLSv1.2
> RandomCookie: GMT: 1491538846 bytes = { 239, 0, 205, 234, 239, 135, 27,
> 62, 91, 187, 205, 216, 254, 230, 62, 170, 127, 69, 1, 60, 88, 75, 88, 14,
> 181, 116, 137, 40 }
> Session ID: {}
> Cipher Suites:
> [...]
>
> The corresponding Wireshark trace showed the cipher-list with the names
> you're used to, so there really are no SSL-ciphers here, "just" a
> different naming scheme.
>
>
>
> Cheers, Lothar
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/jetty-users
>
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] keystore
Am 14.03.2018 um 17:53 schrieb Silvio Bierman:
Those are ciphers for the SSL protocol instead of TLS. You do not want to use
those...
I'm not defending IBM here for their decision to follow the NIH-principle.
The ciphers are for TLS, the session where this trace came from was an
OFTP2-connection that is restricted to TLS and was using TLSv1.2 for the
handshake:
OFTP TLS-ReceiveThread2 (Thread nr. 6, for server-socket listening on address
/x.x.x.x on port 6619), READ: TLSv1.2 Handshake, length = 181
JsseJCE: Using AlgorithmParameters EC from provider IBMJCE version 1.8
JsseJCE: Using AlgorithmParameters EC from provider IBMJCE version 1.8
JsseJCE: Using AlgorithmParameters EC from provider IBMJCE version 1.8
JsseJCE: Using AlgorithmParameters EC from provider IBMJCE version 1.8
*** ClientHello, TLSv1.2
RandomCookie: GMT: 1491538846 bytes = { 239, 0, 205, 234, 239, 135, 27, 62,
91, 187, 205, 216, 254, 230, 62, 170, 127, 69, 1, 60, 88, 75, 88, 14, 181, 116,
137, 40 }
Session ID: {}
Cipher Suites:
[...]
The corresponding Wireshark trace showed the cipher-list with the names
you're used to, so there really are no SSL-ciphers here, "just" a
different naming scheme.
Cheers, Lothar
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] keystore
Also, with the IBM JVM you might have to configure the following on the Jetty side ... SslContextFactory ... .setProtocol(String protocol) - this defaults to "TLS" (the openjdk official name), yours is likely different (based on my reading of the IBM JVM documentation). .setProvider(String provider) - this defaults to "" (unset) as we use the default provider, but your IBM JVM seems to want to do things "the IBM way", not "the standard way". As a last resort, you might need to create the javax.net.ssl.SSLContext manually, the IBM way, and give it to the jetty side SslContextFactory.setSslContext(SSLContext context) Joakim Erdfelt / joa...@webtide.com On Wed, Mar 14, 2018 at 12:04 PM, Joakim Erdfelt wrote: > Also, read and understand the linked to issue at the IBM side for TLS > (from the prior message) > > https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0. > 0/com.ibm.java.security.component.80.doc/security-component/jsse2Docs/ > matchsslcontext_tls.html > > The IBM JVM does not apparently follow the OpenJDK standard naming of > things (which dozens of other alternate JVMs do), that article tells you > how to correct the startup of your IBM JVM to address that as well. > > > > Joakim Erdfelt / joa...@webtide.com > > On Wed, Mar 14, 2018 at 11:53 AM, Silvio Bierman < > sbier...@jambo-software.com> wrote: > >> Those are ciphers for the SSL protocol instead of TLS. You do not want to >> use those... >> >> >> >> Sent from my Samsung Galaxy smartphone. >> >> ---- Original message >> From: Lothar Kimmeringer >> Date: 3/14/18 17:36 (GMT+01:00) >> To: jetty-users@eclipse.org >> Subject: Re: [jetty-users] keystore >> >> Hi, >> >> Am 14.03.2018 um 17:24 schrieb Joakim Erdfelt: >> >> > * The IBM JVM is not sane, look into its cipher suites and protocols. >> > >> > A quick comparison shows that it has half the cipher suites that oracle >> jvm or openjdk has. >> >> Not necessarily. At least the JVM for i Series has more or less the same >> ciphers but the textual representation is not starting with TLS_... but >> SSL_... >> so filters based on the textual representation will filter out most >> of them (in my case where I found that out, all ciphers were filtered). >> >> Here as an example -Djavax.net.debug=ssl:handshake output for a >> ClientHello >> sent by an AS/400: >> >> Cipher Suites: [ >> TLS_EMPTY_RENEGOTIATION_INFO_SCSV, >> SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, >> SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA384, >> SSL_RSA_WITH_AES_256_CBC_SHA256, >> SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, >> SSL_ECDH_RSA_WITH_AES_256_CBC_SHA384, >> SSL_DHE_RSA_WITH_AES_256_CBC_SHA256, >> SSL_DHE_DSS_WITH_AES_256_CBC_SHA256, >> SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, >> SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA, >> SSL_RSA_WITH_AES_256_CBC_SHA, >> SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA, >> SSL_ECDH_RSA_WITH_AES_256_CBC_SHA, >> SSL_DHE_RSA_WITH_AES_256_CBC_SHA, >> SSL_DHE_DSS_WITH_AES_256_CBC_SHA, >> SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, >> SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA256, >> SSL_RSA_WITH_AES_128_CBC_SHA256, >> SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, >> SSL_ECDH_RSA_WITH_AES_128_CBC_SHA256, >> SSL_DHE_RSA_WITH_AES_128_CBC_SHA256, >> SSL_DHE_DSS_WITH_AES_128_CBC_SHA256, >> SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, >> SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA, >> SSL_RSA_WITH_AES_128_CBC_SHA, >> SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA, >> SSL_ECDH_RSA_WITH_AES_128_CBC_SHA, >> SSL_DHE_RSA_WITH_AES_128_CBC_SHA, >> SSL_DHE_DSS_WITH_AES_128_CBC_SHA, >> SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, >> SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, >> SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384, >> SSL_RSA_WITH_AES_256_GCM_SHA384, >> SSL_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, >> SSL_ECDH_RSA_WITH_AES_256_GCM_SHA384, >> SSL_DHE_DSS_WITH_AES_256_GCM_SHA384, >> SSL_DHE_RSA_WITH_AES_256_GCM_SHA384, >> SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256, >> SSL_RSA_WITH_AES_128_GCM_SHA256, >> SSL_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, >> SSL_ECDH_RSA_WITH_AES_128_GCM_SHA256, >> SSL_DHE_RSA_WITH_AES_128_GCM_SHA256, >> SSL_DHE_DSS_WITH_AES_128_GCM_SHA256] >> >> >> Cheers, Lothar >> ___ >> jetty-users mailing list >> jetty-users@eclipse.org >> To change your delivery options, retrieve your password, or unsubscribe >> from this list, visit >> https://dev.eclipse.org/mailman/listinfo/jetty-users >> >> ___ >> jetty-users mailing list >> jetty-users@eclipse.org >> To change your delivery options, retrieve your password, or unsubscribe >> from this list, visit >> https://dev.eclipse.org/mailman/listinfo/jetty-users >> > > ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] keystore
Also, read and understand the linked to issue at the IBM side for TLS (from the prior message) https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java.security.component.80.doc/security-component/jsse2Docs/matchsslcontext_tls.html The IBM JVM does not apparently follow the OpenJDK standard naming of things (which dozens of other alternate JVMs do), that article tells you how to correct the startup of your IBM JVM to address that as well. Joakim Erdfelt / joa...@webtide.com On Wed, Mar 14, 2018 at 11:53 AM, Silvio Bierman < sbier...@jambo-software.com> wrote: > Those are ciphers for the SSL protocol instead of TLS. You do not want to > use those... > > > > Sent from my Samsung Galaxy smartphone. > > Original message > From: Lothar Kimmeringer > Date: 3/14/18 17:36 (GMT+01:00) > To: jetty-users@eclipse.org > Subject: Re: [jetty-users] keystore > > Hi, > > Am 14.03.2018 um 17:24 schrieb Joakim Erdfelt: > > > * The IBM JVM is not sane, look into its cipher suites and protocols. > > > > A quick comparison shows that it has half the cipher suites that oracle > jvm or openjdk has. > > Not necessarily. At least the JVM for i Series has more or less the same > ciphers but the textual representation is not starting with TLS_... but > SSL_... > so filters based on the textual representation will filter out most > of them (in my case where I found that out, all ciphers were filtered). > > Here as an example -Djavax.net.debug=ssl:handshake output for a > ClientHello > sent by an AS/400: > > Cipher Suites: [ > TLS_EMPTY_RENEGOTIATION_INFO_SCSV, > SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, > SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA384, > SSL_RSA_WITH_AES_256_CBC_SHA256, > SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, > SSL_ECDH_RSA_WITH_AES_256_CBC_SHA384, > SSL_DHE_RSA_WITH_AES_256_CBC_SHA256, > SSL_DHE_DSS_WITH_AES_256_CBC_SHA256, > SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, > SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA, > SSL_RSA_WITH_AES_256_CBC_SHA, > SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA, > SSL_ECDH_RSA_WITH_AES_256_CBC_SHA, > SSL_DHE_RSA_WITH_AES_256_CBC_SHA, > SSL_DHE_DSS_WITH_AES_256_CBC_SHA, > SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, > SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA256, > SSL_RSA_WITH_AES_128_CBC_SHA256, > SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, > SSL_ECDH_RSA_WITH_AES_128_CBC_SHA256, > SSL_DHE_RSA_WITH_AES_128_CBC_SHA256, > SSL_DHE_DSS_WITH_AES_128_CBC_SHA256, > SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, > SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA, > SSL_RSA_WITH_AES_128_CBC_SHA, > SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA, > SSL_ECDH_RSA_WITH_AES_128_CBC_SHA, > SSL_DHE_RSA_WITH_AES_128_CBC_SHA, > SSL_DHE_DSS_WITH_AES_128_CBC_SHA, > SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, > SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, > SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384, > SSL_RSA_WITH_AES_256_GCM_SHA384, > SSL_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, > SSL_ECDH_RSA_WITH_AES_256_GCM_SHA384, > SSL_DHE_DSS_WITH_AES_256_GCM_SHA384, > SSL_DHE_RSA_WITH_AES_256_GCM_SHA384, > SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256, > SSL_RSA_WITH_AES_128_GCM_SHA256, > SSL_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, > SSL_ECDH_RSA_WITH_AES_128_GCM_SHA256, > SSL_DHE_RSA_WITH_AES_128_GCM_SHA256, > SSL_DHE_DSS_WITH_AES_128_GCM_SHA256] > > > Cheers, Lothar > ___ > jetty-users mailing list > jetty-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users > > ___ > jetty-users mailing list > jetty-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users > ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] keystore
Hi, Am 14.03.2018 um 17:47 schrieb Joakim Erdfelt: Conclusion: You have a cipher suite issue. I don't have any issues (I just added my 2 cents to this thread). My point is if we have a similar effect here than with JVMs on iSeries that the JVM reports ciphers "SSL_-something" and jetty is configured to only enable ciphers "TLS_-something", the server might filter out all the "good ones" leading to the situation that server and client don't share any ciphers leading to this error. The fix in that case would be to change the jetty-configuration of enabled ciphers to the corresponding textual representations of these ciphers on that particular system (replace TLS_ by SSL_ that is) Cheers, Lothar ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] keystore
Those are ciphers for the SSL protocol instead of TLS. You do not want to use those... Sent from my Samsung Galaxy smartphone. Original message From: Lothar Kimmeringer Date: 3/14/18 17:36 (GMT+01:00) To: jetty-users@eclipse.org Subject: Re: [jetty-users] keystore Hi, Am 14.03.2018 um 17:24 schrieb Joakim Erdfelt: > * The IBM JVM is not sane, look into its cipher suites and protocols. > > A quick comparison shows that it has half the cipher suites that oracle jvm > or openjdk has. Not necessarily. At least the JVM for i Series has more or less the same ciphers but the textual representation is not starting with TLS_... but SSL_... so filters based on the textual representation will filter out most of them (in my case where I found that out, all ciphers were filtered). Here as an example -Djavax.net.debug=ssl:handshake output for a ClientHello sent by an AS/400: Cipher Suites: [ TLS_EMPTY_RENEGOTIATION_INFO_SCSV, SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA384, SSL_RSA_WITH_AES_256_CBC_SHA256, SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, SSL_ECDH_RSA_WITH_AES_256_CBC_SHA384, SSL_DHE_RSA_WITH_AES_256_CBC_SHA256, SSL_DHE_DSS_WITH_AES_256_CBC_SHA256, SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_AES_256_CBC_SHA, SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA, SSL_ECDH_RSA_WITH_AES_256_CBC_SHA, SSL_DHE_RSA_WITH_AES_256_CBC_SHA, SSL_DHE_DSS_WITH_AES_256_CBC_SHA, SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA256, SSL_RSA_WITH_AES_128_CBC_SHA256, SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, SSL_ECDH_RSA_WITH_AES_128_CBC_SHA256, SSL_DHE_RSA_WITH_AES_128_CBC_SHA256, SSL_DHE_DSS_WITH_AES_128_CBC_SHA256, SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_AES_128_CBC_SHA, SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA, SSL_ECDH_RSA_WITH_AES_128_CBC_SHA, SSL_DHE_RSA_WITH_AES_128_CBC_SHA, SSL_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384, SSL_RSA_WITH_AES_256_GCM_SHA384, SSL_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, SSL_ECDH_RSA_WITH_AES_256_GCM_SHA384, SSL_DHE_DSS_WITH_AES_256_GCM_SHA384, SSL_DHE_RSA_WITH_AES_256_GCM_SHA384, SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256, SSL_RSA_WITH_AES_128_GCM_SHA256, SSL_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, SSL_ECDH_RSA_WITH_AES_128_GCM_SHA256, SSL_DHE_RSA_WITH_AES_128_GCM_SHA256, SSL_DHE_DSS_WITH_AES_128_GCM_SHA256] Cheers, Lothar ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] keystore
> Secure Connection Failed Error code: SSL_ERROR_NO_CYPHER_OVERLAP The stated reason from Firefox for that error is that you lack the required cipher suites for the updated TLS configuration present since FireFox 50.x * https://support.mozilla.org/en-US/questions/1148536 * https://support.mozilla.org/en-US/questions/1153050 * https://support.mozilla.org/en-US/questions/1167953 Your IBM JVM reports 14 selected Cipher Suites (31 disabled) by default. Oracle JVM reports 29 selected Cipher Suites (53 disabled) by default. Conclusion: You have a cipher suite issue. Try MSIE or FireFox 45 (suggestions made in the mozilla support forum). If those work, then you have a Cipher Suite issue with your IBM JVM. Joakim Erdfelt / joa...@webtide.com On Wed, Mar 14, 2018 at 11:36 AM, Lothar Kimmeringer wrote: > Hi, > > Am 14.03.2018 um 17:24 schrieb Joakim Erdfelt: > > * The IBM JVM is not sane, look into its cipher suites and protocols. >> >> A quick comparison shows that it has half the cipher suites that oracle >> jvm or openjdk has. >> > > Not necessarily. At least the JVM for i Series has more or less the same > ciphers but the textual representation is not starting with TLS_... but > SSL_... > so filters based on the textual representation will filter out most > of them (in my case where I found that out, all ciphers were filtered). > > Here as an example -Djavax.net.debug=ssl:handshake output for a > ClientHello > sent by an AS/400: > > Cipher Suites: [ > TLS_EMPTY_RENEGOTIATION_INFO_SCSV, > SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, > SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA384, > SSL_RSA_WITH_AES_256_CBC_SHA256, > SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, > SSL_ECDH_RSA_WITH_AES_256_CBC_SHA384, > SSL_DHE_RSA_WITH_AES_256_CBC_SHA256, > SSL_DHE_DSS_WITH_AES_256_CBC_SHA256, > SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, > SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA, > SSL_RSA_WITH_AES_256_CBC_SHA, > SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA, > SSL_ECDH_RSA_WITH_AES_256_CBC_SHA, > SSL_DHE_RSA_WITH_AES_256_CBC_SHA, > SSL_DHE_DSS_WITH_AES_256_CBC_SHA, > SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, > SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA256, > SSL_RSA_WITH_AES_128_CBC_SHA256, > SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, > SSL_ECDH_RSA_WITH_AES_128_CBC_SHA256, > SSL_DHE_RSA_WITH_AES_128_CBC_SHA256, > SSL_DHE_DSS_WITH_AES_128_CBC_SHA256, > SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, > SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA, > SSL_RSA_WITH_AES_128_CBC_SHA, > SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA, > SSL_ECDH_RSA_WITH_AES_128_CBC_SHA, > SSL_DHE_RSA_WITH_AES_128_CBC_SHA, > SSL_DHE_DSS_WITH_AES_128_CBC_SHA, > SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, > SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, > SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384, > SSL_RSA_WITH_AES_256_GCM_SHA384, > SSL_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, > SSL_ECDH_RSA_WITH_AES_256_GCM_SHA384, > SSL_DHE_DSS_WITH_AES_256_GCM_SHA384, > SSL_DHE_RSA_WITH_AES_256_GCM_SHA384, > SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256, > SSL_RSA_WITH_AES_128_GCM_SHA256, > SSL_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, > SSL_ECDH_RSA_WITH_AES_128_GCM_SHA256, > SSL_DHE_RSA_WITH_AES_128_GCM_SHA256, > SSL_DHE_DSS_WITH_AES_128_GCM_SHA256] > > > Cheers, Lothar > ___ > jetty-users mailing list > jetty-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users > ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] keystore
Hi, Am 14.03.2018 um 17:24 schrieb Joakim Erdfelt: * The IBM JVM is not sane, look into its cipher suites and protocols. A quick comparison shows that it has half the cipher suites that oracle jvm or openjdk has. Not necessarily. At least the JVM for i Series has more or less the same ciphers but the textual representation is not starting with TLS_... but SSL_... so filters based on the textual representation will filter out most of them (in my case where I found that out, all ciphers were filtered). Here as an example -Djavax.net.debug=ssl:handshake output for a ClientHello sent by an AS/400: Cipher Suites: [ TLS_EMPTY_RENEGOTIATION_INFO_SCSV, SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA384, SSL_RSA_WITH_AES_256_CBC_SHA256, SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, SSL_ECDH_RSA_WITH_AES_256_CBC_SHA384, SSL_DHE_RSA_WITH_AES_256_CBC_SHA256, SSL_DHE_DSS_WITH_AES_256_CBC_SHA256, SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_AES_256_CBC_SHA, SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA, SSL_ECDH_RSA_WITH_AES_256_CBC_SHA, SSL_DHE_RSA_WITH_AES_256_CBC_SHA, SSL_DHE_DSS_WITH_AES_256_CBC_SHA, SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA256, SSL_RSA_WITH_AES_128_CBC_SHA256, SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, SSL_ECDH_RSA_WITH_AES_128_CBC_SHA256, SSL_DHE_RSA_WITH_AES_128_CBC_SHA256, SSL_DHE_DSS_WITH_AES_128_CBC_SHA256, SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_AES_128_CBC_SHA, SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA, SSL_ECDH_RSA_WITH_AES_128_CBC_SHA, SSL_DHE_RSA_WITH_AES_128_CBC_SHA, SSL_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384, SSL_RSA_WITH_AES_256_GCM_SHA384, SSL_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, SSL_ECDH_RSA_WITH_AES_256_GCM_SHA384, SSL_DHE_DSS_WITH_AES_256_GCM_SHA384, SSL_DHE_RSA_WITH_AES_256_GCM_SHA384, SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256, SSL_RSA_WITH_AES_128_GCM_SHA256, SSL_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, SSL_ECDH_RSA_WITH_AES_128_GCM_SHA256, SSL_DHE_RSA_WITH_AES_128_GCM_SHA256, SSL_DHE_DSS_WITH_AES_128_GCM_SHA256] Cheers, Lothar ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] keystore
Your server has no handlers, none, completely empty.
Perhaps you missed the ...
server.setHandler(resourceHandler);
Better yet, use ...
HandlerList handlers = new HandlerList();
handlers.addHandler(resourceHandler);
handlers.addHandler(new DefaultHandler()); // always last
server.setHandler(handlers);
Also, add this before your server.start();
server.setDumpAfterStart(true);
server.start();
server.join();
That should produce the dump I mentioned in the prior email.
Joakim Erdfelt / joa...@webtide.com
On Wed, Mar 14, 2018 at 9:55 AM, Lou DeGenaro
wrote:
> Have you attempted to configure the SSL Cipher Suites on the Jetty server
> side?
>
> > NO. I'm using vanilla jetty as shipped. Is there something else I need
> to do?
>
> Code shown below.
>
> Thanks.
>
> Lou.
>
> private void server_main(String[] args) {
> try {
> // === jetty.xml ===
>
>
>
> // Setup Threadpool
>
>
> QueuedThreadPool threadPool = new QueuedThreadPool();
> threadPool.setMaxThreads(max_threads);
>
> // Server
>
>
> server = new Server(threadPool);
>
> // Scheduler
>
>
> server.addBean(new ScheduledExecutorScheduler());
>
> // === jetty-http.xml ===
>
>
> ServerConnector http = new ServerConnector(server, new
> HttpConnectionFactory());
> http.setPort(port_http);
> http.setIdleTimeout(idle_timeout);
> server.addConnector(http);
>
> // === jetty-https.xml ===
>
>
> // SSL Context Factory
>
>
> SslContextFactory sslContextFactory = new SslContextFactory();
>
> HttpConfiguration http_config = new HttpConfiguration();
> http_config.setSecureScheme("https");
> http_config.setSecurePort(port_https);
>
> HttpConfiguration https_config = new
> HttpConfiguration(http_config);
> https_config.addCustomizer(new SecureRequestCustomizer());
>
> ServerConnector https = new ServerConnector(server,
> new SslConnectionFactory(sslContextFactory,"http/1.1"),
> new HttpConnectionFactory(https_config));
>
> https.setPort(port_https);
> sslContextFactory.setKeyStorePath(keystore);
>
> sslContextFactory.setKeyStorePassword(keystore_password);
> sslContextFactory.setKeyManagerPassword(keymanager_password);
>
> server.setConnectors(new Connector[] { http });
> server.addConnector(https);
>
> //
> ResourceHandler resourceHandler = new ResourceHandler();
> resourceHandler.setDirectoriesListed(true);
> resourceHandler.setResourceBase(jetty_server_root);
>
> server.start();
> server.join();
> }
> catch(Exception e) {
> e.printStackTrace();
> }
> }
>
> On Wed, Mar 14, 2018 at 10:44 AM, Joakim Erdfelt
> wrote:
>
>> Have you attempted to configure the SSL Cipher Suites on the Jetty server
>> side?
>>
>> If you enable the jetty startup dump you'll see the list of enabled
>> cipher suites and protocols that Jetty is running with (including the
>> reason why a specific available protocol or cipher suite is disabled).
>>
>> $ java -jar /path/to/my/jetty-home/start.jar
>> jetty.server.dumpAfterStart=true
>>
>> Example output:
>>
>> | += SslConnectionFactory@51c668e3{SSL->http/1.1} - STARTED
>> | | += SslContextFactory@19f040ba[provider=null,keyStore=file:///
>> mnt/c/code/jetty/distros/jetty-distribution-9.4.8.v20171121/
>> demo-base/etc/keystore,trustStore=file:///mnt/c/code/jetty/distros/jetty-
>> distribution-9.4.8.v20171121/demo-base/etc/keystore] trustAll=false
>> | | +- Protocol Selections
>> | | | +- Enabled (size=3)
>> | | | | +- TLSv1
>> | | | | +- TLSv1.1
>> | | | | +- TLSv1.2
>> | | | +- Disabled (size=2)
>> | | | +- SSLv2Hello - ConfigExcluded:'SSLv2Hello'
>> | | | +- SSLv3 - JreDisabled:java.security,
>> ConfigExcluded:'SSLv3'
>> | | +- Cipher Suite Selections
>> | | +- Enabled (size=29)
>> | | | +- TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
>> | | | +- TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
>> | | | +- TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
>> | | | +- TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
>> | | | +- TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
>> | | | +- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
>> | | | +- TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
>> | | | +- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
>> | | | +- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
>> | | | +- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
>> | | | +- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
>> | | | +- TLS_ECDHE_ECDSA_WITH_AES_256_G
Re: [jetty-users] keystore
Have you attempted to configure the SSL Cipher Suites on the Jetty server
side?
> NO. I'm using vanilla jetty as shipped. Is there something else I need
to do?
Code shown below.
Thanks.
Lou.
private void server_main(String[] args) {
try {
// === jetty.xml
===
// Setup
Threadpool
QueuedThreadPool threadPool = new QueuedThreadPool();
threadPool.setMaxThreads(max_threads);
//
Server
server = new Server(threadPool);
//
Scheduler
server.addBean(new ScheduledExecutorScheduler());
// === jetty-http.xml
===
ServerConnector http = new ServerConnector(server, new
HttpConnectionFactory());
http.setPort(port_http);
http.setIdleTimeout(idle_timeout);
server.addConnector(http);
// === jetty-https.xml
===
// SSL Context
Factory
SslContextFactory sslContextFactory = new SslContextFactory();
HttpConfiguration http_config = new HttpConfiguration();
http_config.setSecureScheme("https");
http_config.setSecurePort(port_https);
HttpConfiguration https_config = new
HttpConfiguration(http_config);
https_config.addCustomizer(new SecureRequestCustomizer());
ServerConnector https = new ServerConnector(server,
new SslConnectionFactory(sslContextFactory,"http/1.1"),
new HttpConnectionFactory(https_config));
https.setPort(port_https);
sslContextFactory.setKeyStorePath(keystore);
sslContextFactory.setKeyStorePassword(keystore_password);
sslContextFactory.setKeyManagerPassword(keymanager_password);
server.setConnectors(new Connector[] { http });
server.addConnector(https);
//
ResourceHandler resourceHandler = new ResourceHandler();
resourceHandler.setDirectoriesListed(true);
resourceHandler.setResourceBase(jetty_server_root);
server.start();
server.join();
}
catch(Exception e) {
e.printStackTrace();
}
}
On Wed, Mar 14, 2018 at 10:44 AM, Joakim Erdfelt wrote:
> Have you attempted to configure the SSL Cipher Suites on the Jetty server
> side?
>
> If you enable the jetty startup dump you'll see the list of enabled cipher
> suites and protocols that Jetty is running with (including the reason why a
> specific available protocol or cipher suite is disabled).
>
> $ java -jar /path/to/my/jetty-home/start.jar jetty.server.dumpAfterStart=
> true
>
> Example output:
>
> | += SslConnectionFactory@51c668e3{SSL->http/1.1} - STARTED
> | | += SslContextFactory@19f040ba[provider=null,keyStore=file://
> /mnt/c/code/jetty/distros/jetty-distribution-9.4.8.
> v20171121/demo-base/etc/keystore,trustStore=file:///
> mnt/c/code/jetty/distros/jetty-distribution-9.4.8.v20171121/demo-base/etc/keystore]
> trustAll=false
> | | +- Protocol Selections
> | | | +- Enabled (size=3)
> | | | | +- TLSv1
> | | | | +- TLSv1.1
> | | | | +- TLSv1.2
> | | | +- Disabled (size=2)
> | | | +- SSLv2Hello - ConfigExcluded:'SSLv2Hello'
> | | | +- SSLv3 - JreDisabled:java.security,
> ConfigExcluded:'SSLv3'
> | | +- Cipher Suite Selections
> | | +- Enabled (size=29)
> | | | +- TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
> | | | +- TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
> | | | +- TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
> | | | +- TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
> | | | +- TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
> | | | +- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
> | | | +- TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
> | | | +- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
> | | | +- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
> | | | +- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
> | | | +- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
> | | | +- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
> | | | +- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
> | | | +- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
> | | | +- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
> | | | +- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> | | | +- TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
> | | | +- TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
> | | | +- TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
> | | | +- TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
> | | | +- TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
> | | | +- TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
> | | | +- TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
> | | | +- TLS_ECDH_RSA_WIT
Re: [jetty-users] keystore
Have you attempted to configure the SSL Cipher Suites on the Jetty server
side?
If you enable the jetty startup dump you'll see the list of enabled cipher
suites and protocols that Jetty is running with (including the reason why a
specific available protocol or cipher suite is disabled).
$ java -jar /path/to/my/jetty-home/start.jar
jetty.server.dumpAfterStart=true
Example output:
| += SslConnectionFactory@51c668e3{SSL->http/1.1} - STARTED
| | +=
SslContextFactory@19f040ba[provider=null,keyStore=file:///mnt/c/code/jetty/distros/jetty-distribution-9.4.8.v20171121/demo-base/etc/keystore,trustStore=file:///mnt/c/code/jetty/distros/jetty-distribution-9.4.8.v20171121/demo-base/etc/keystore]
trustAll=false
| | +- Protocol Selections
| | | +- Enabled (size=3)
| | | | +- TLSv1
| | | | +- TLSv1.1
| | | | +- TLSv1.2
| | | +- Disabled (size=2)
| | | +- SSLv2Hello - ConfigExcluded:'SSLv2Hello'
| | | +- SSLv3 - JreDisabled:java.security,
ConfigExcluded:'SSLv3'
| | +- Cipher Suite Selections
| | +- Enabled (size=29)
| | | +- TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
| | | +- TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
| | | +- TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
| | | +- TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
| | | +- TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
| | | +- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
| | | +- TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
| | | +- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
| | | +- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
| | | +- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
| | | +- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
| | | +- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
| | | +- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
| | | +- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
| | | +- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
| | | +- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
| | | +- TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
| | | +- TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
| | | +- TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
| | | +- TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
| | | +- TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
| | | +- TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
| | | +- TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
| | | +- TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
| | | +- TLS_EMPTY_RENEGOTIATION_INFO_SCSV
| | | +- TLS_RSA_WITH_AES_128_CBC_SHA256
| | | +- TLS_RSA_WITH_AES_128_GCM_SHA256
| | | +- TLS_RSA_WITH_AES_256_CBC_SHA256
| | | +- TLS_RSA_WITH_AES_256_GCM_SHA384
| | +- Disabled (size=53)
| | +- SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA -
JreDisabled:java.security, ConfigExcluded:'^.*_(MD5|SHA|SHA1)$'
| | +- SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA -
ConfigExcluded:'^.*_(MD5|SHA|SHA1)$'
| | +- SSL_DHE_DSS_WITH_DES_CBC_SHA -
JreDisabled:java.security, ConfigExcluded:'^.*_(MD5|SHA|SHA1)$'
| | +- SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA -
JreDisabled:java.security, ConfigExcluded:'^.*_(MD5|SHA|SHA1)$'
| | +- SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA -
ConfigExcluded:'^.*_(MD5|SHA|SHA1)$'
| | +- SSL_DHE_RSA_WITH_DES_CBC_SHA -
JreDisabled:java.security, ConfigExcluded:'^.*_(MD5|SHA|SHA1)$'
| | +- SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA -
JreDisabled:java.security, ConfigExcluded:'^.*_(MD5|SHA|SHA1)$'
| | +- SSL_DH_anon_WITH_3DES_EDE_CBC_SHA -
JreDisabled:java.security, ConfigExcluded:'^.*_(MD5|SHA|SHA1)$'
| | +- SSL_DH_anon_WITH_DES_CBC_SHA -
JreDisabled:java.security, ConfigExcluded:'^.*_(MD5|SHA|SHA1)$'
| | +- SSL_RSA_EXPORT_WITH_DES40_CBC_SHA -
JreDisabled:java.security, ConfigExcluded:'^.*_(MD5|SHA|SHA1)$'
| | +- SSL_RSA_WITH_3DES_EDE_CBC_SHA -
ConfigExcluded:'^.*_(MD5|SHA|SHA1)$'
| | +- SSL_RSA_WITH_DES_CBC_SHA -
JreDisabled:java.security, ConfigExcluded:'^.*_(MD5|SHA|SHA1)$'
| | +- SSL_RSA_WITH_NULL_MD5 - JreDisabled:java.security,
ConfigExcluded:'^.*_(MD5|SHA|SHA1)$'
| | +- SSL_RSA_WITH_NULL_SHA - JreDisabled:java.security,
ConfigExcluded:'^.*_(MD5|SHA|SHA1)$'
| | +- TLS_DHE_DSS_WITH_AES_128_CBC_SHA -
ConfigExcluded:'^.*_(MD5|SHA|SHA1)$'
| | +- TLS_DHE_DSS_WITH_AES_256_CBC_SHA -
ConfigExcluded:'^.*_(MD5|SHA|SHA1)$'
| | +- TLS_DHE_RSA_WITH_AES_128_CBC_SHA -
ConfigExcluded:'^.*_(MD5|SHA|SHA1)$'
| | +- TLS_DHE_RSA_WITH_AES_256_CBC_SHA -
ConfigExcluded:'^.*_(MD5|SHA|SHA1)$'
| | +- TLS_DH_anon_WITH_AES_12
Re: [jetty-users] keystore
Still having (likely user error) issues with SSL. I generate my keystore thus: /share/jdk1.8/bin/keytool -genkey -noprompt -alias jetty -dname "CN=my.cn, OU=my.ou, O=my.o, L=my.l, S=my.s, C=my.c" -keyalg RSA -keysize 2048 -sigalg SHA256withRSA -validity 1 -keystore /home/webserver/etc/keystore -storepass uE9RVnqAXAh -keypass uE9RVnqAXAh I run jetty 9.4.8 with java 1.8 and the keystore. I visit https:/myhost:8443/ using Firefox 52.4.0 (64-bit) and my windows displays: Secure Connection Failed Error code: SSL_ERROR_NO_CYPHER_OVERLAP Thanks for your advise. Lou. On Mon, Mar 12, 2018 at 2:03 AM, Greg Wilkins wrote: > Any jetty.keystore.password is not set anywhere? if it is set, is it set > to your password? > Try hard coding it in the XML to debug before playing with parameters. > > cheers > > > On 11 March 2018 at 06:48, Lou DeGenaro wrote: > >> yep. >> >> On Sat, Mar 10, 2018 at 12:59 PM, John English >> wrote: >> >>> On 10/03/2018 16:15, Lou DeGenaro wrote: >>> >>> default="my-password"/> >>> default="my-password"/> >>> >>> The keystore password and truststore password are really the same? Are >>> you sure? >>> >>> -- >>> John English >>> ___ >>> jetty-users mailing list >>> jetty-users@eclipse.org >>> To change your delivery options, retrieve your password, or unsubscribe >>> from this list, visit >>> https://dev.eclipse.org/mailman/listinfo/jetty-users >>> >> >> >> ___ >> jetty-users mailing list >> jetty-users@eclipse.org >> To change your delivery options, retrieve your password, or unsubscribe >> from this list, visit >> https://dev.eclipse.org/mailman/listinfo/jetty-users >> > > > > -- > Greg Wilkins CTO http://webtide.com > > ___ > jetty-users mailing list > jetty-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users > ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] keystore
Any jetty.keystore.password is not set anywhere? if it is set, is it set to your password? Try hard coding it in the XML to debug before playing with parameters. cheers On 11 March 2018 at 06:48, Lou DeGenaro wrote: > yep. > > On Sat, Mar 10, 2018 at 12:59 PM, John English > wrote: > >> On 10/03/2018 16:15, Lou DeGenaro wrote: >> >>> >> default="my-password"/> >>> >> default="my-password"/> >>> >> >> The keystore password and truststore password are really the same? Are >> you sure? >> >> -- >> John English >> ___ >> jetty-users mailing list >> jetty-users@eclipse.org >> To change your delivery options, retrieve your password, or unsubscribe >> from this list, visit >> https://dev.eclipse.org/mailman/listinfo/jetty-users >> > > > ___ > jetty-users mailing list > jetty-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] keystore
yep. On Sat, Mar 10, 2018 at 12:59 PM, John English wrote: > On 10/03/2018 16:15, Lou DeGenaro wrote: > >> > default="my-password"/> >> > default="my-password"/> >> > > The keystore password and truststore password are really the same? Are you > sure? > > -- > John English > ___ > jetty-users mailing list > jetty-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users > ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] keystore
On 10/03/2018 16:15, Lou DeGenaro wrote: default="my-password"/> name="jetty.truststore.password" default="my-password"/> The keystore password and truststore password are really the same? Are you sure? -- John English ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
[jetty-users] keystore
I've downloaded jetty 9.2.13 (yes, we will move on to something better soon). I made one small change to jetty-https.xml replacing 433 with 8443 for the secure port. I create a small test webapp: webapps/test/index.html Hello World! I launch this vanilla and otherwise unadulterated jetty thus: > java -jar start.jar -Dorg.eclipse.jetty.LEVEL=DEBUG Using my FF browser I visit https://myhost:8443/test/ and after adding an exception for an "Insecure Connection" I see: Hello World! Great. Now comes the part I don't understand (somewhat naive ssl user here). I have a keystore and password that is working fine for an embedded jetty (also 9.2.13) in another application. Works fine for https with the same "Insecure Connection" due to self-signed cert. I take the keystore from my application and put in into /etc of the vanilla jetty 9.2.13. And I take the password from my application and put in into jetty-ssl.xml thus: When I launch the jetty server the same way: > java -jar start.jar -Dorg.eclipse.jetty.LEVEL=DEBUG I get: 2018-03-10 09:12:19.794:WARN:oejuc.AbstractLifeCycle:main: FAILED SslContextFactory@2a3046da(/home/degenaro/test/jetty-distribution-9.2.13.v20150730/etc/keystore,/home/degenaro/test/jetty-distribution-9.2.13.v20150730/etc/keystore): java.io.IOException: Keystore was tampered with, or password was incorrect java.io.IOException: Keystore was tampered with, or password was incorrect at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:780) at sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:56) at sun.security.provider.KeyStoreDelegator.engineLoad(KeyStoreDelegator.java:224) at sun.security.provider.JavaKeyStore$DualFormatJKS.engineLoad(JavaKeyStore.java:70) at java.security.KeyStore.load(KeyStore.java:1445) Certainly user error, but what have I done wrong?? Thanks. Lou. ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
