Felix,
> Am 01.01.2020 um 20:27 schrieb Felix Schumacher
> <felix.schumac...@internetallee.de>:
>
>
>> Am 01.01.20 um 18:19 schrieb logo:
>> Felix,
>>
>>>> Am 01.01.2020 um 11:49 schrieb Felix Schumacher
>>>> <felix.schumac...@internetallee.de>:
>>>
>>>
>>> Am 27.12.19 um 17:36 schrieb logo:
>>>> Chris
>>>>
>>>> Am 2019-12-27 16:33, schrieb Christopher Schultz:
>>>> Peter,
>>>>
>>>> On 12/26/19 18:55, logo wrote:
>>>>>>> Hi Mark,
>>>> I hope it's okay if I reply. :)
>>>>
>>>>> :-)
>>>>
>>>>
>>>>>>> I just recently tested Step CA (smallstep.com) as an internal CA
>>>>>>> that provides an internal ACME service.
>>>>>>>
>>>>>>> After I deployed the created cert to my Tomcat (8.5.50 with
>>>>>>> adoptopenjdk 11) I noticed that while the openssl connector
>>>>>>> immediately started, the JSSE connector with the same cert would
>>>>>>> fail with a "java.security.KeyStoreException: Cannot store
>>>>>>> non-PrivateKeys“ I use the openssl XML certificate config also for
>>>>>>> JSSE.
>>>>>>>
>>>>>>> It took me quite a while to figure this one out - as the message
>>>>>>> usually indicates a public key as cert. I noticed that Step Ca is
>>>>>>> creating ECDSA certs by default. The Openssl Connector delivers the
>>>>>>> new ECDSA cert just fine.
>>>>>>>
>>>>>>> While Java (afaik) seems to be able to handle ECDSA, tomcat will
>>>>>>> fall through a case statement in
>>>>>>> org.apache.tomcat.util.net.jsse.PEMFile
>>>>>>>
>>>>>>> When loading the PEM file parts it will skip all cases in
>>>>>>>
>>>>>>> for (Part part : parts) { switch (part.type) { case "PRIVATE KEY":
>>>>>>> privateKey = part.toPrivateKey(null, keyAlgorithm, Format.PKCS8);
>>>>>>> break; case "ENCRYPTED PRIVATE KEY": privateKey =
>>>>>>> part.toPrivateKey(password, keyAlgorithm, Format.PKCS8); break;
>>>>>>> case "RSA PRIVATE KEY": privateKey = part.toPrivateKey(null,
>>>>>>> keyAlgorithm, Format.PKCS1); break; case "CERTIFICATE": case "X509
>>>>>>> CERTIFICATE": certificates.add(part.toCertificate()); break; } }
>>>>>>>
>>>>>>> as an EC certificate will start with EC PRIVATE KEY.
>>>>>>>
>>>>>>> Is this something that is expected? ECDSA unsupported? Or just an
>>>>>>> incomplete implementation, edge case or a bug?
>>>> EC should work. What does your <Connector> configuration look like?
>>>>
>>>>
>>>>> <Connector port="8443"
>>>>> protocol="org.apache.coyote.http11.Http11Nio2Protocol"
>>>>>
>>>> sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation"
>>>>> maxThreads="150"
>>>>> SSLEnabled="true" >
>>>>> <UpgradeProtocol
>>>> className="org.apache.coyote.http2.Http2Protocol" />
>>>>> <SSLHostConfig>
>>>>> <Certificate
>>>>> certificateKeyFile="${catalina.base}/conf/ssl/privkey.pem"
>>>>> certificateFile="${catalina.base}/conf/ssl/cert.pem"
>>>>> />
>>>>> </SSLHostConfig>
>>>>> </Connector>
>>>>> really basic.
>>>>> First I had a type attribute "RSA" but even ommitting this didn't
>>>> change it.
>>>>
>>>>> Once Tomcat hits the PEMFile-Class the parts read from the
>>>> ECDSA-PEM-file are not transferred to a private key so the class
>>>> member "privateKey" is null. None of the cases above match "EC PRIVATE
>>>> KEY".
>>> The comments at the beginning of PEMFile state that it works for PKCS8,
>>> only. But the code makes an exception for RSA keys, so it probably makes
>>> sense to ad EC keys, too.
>>>
>> Please!
>
> After looking into the code, it doesn't look easy at all.
>
> The code tries to stay away from oracles internal API for cryptography
> and the standard API is not very helpful with regard to EC.
>
>>
>>> Have you tried to convert your key to pkcs8?
>>>
>> Thanks! That works fine!
>>
>> openssl pkcs8 -topk8 -nocrypt -in ssl/privkey.pem -out ssl/privkey-p8.pem
>
>
> Glad it worked.
>
There may be an issue with the provided/available ciphers!
The connector comes up correctly, is accessible through the browser but if I
test the ssl setup, I get an error message that the key/cert may not be used
for "Key agreement"
See:
testssl.sh <tomcat>:8443
Signature Algorithm ECDSA with SHA256
Server key size EC 256 bits
Server key usage Digital Signature, Key Encipherment
Certificate incorrectly used for key agreement
Server extended key usage TLS Web Server Authentication, TLS Web Client
Authentication
I cannot find the reason for that yet, testssl complains if there are
TLS_ECDH_*-ciphers with the wrong server key usage. The setup may be causing
troubles in testssl.sh as Tomcat provides ciphers that maybe should not be
available with ECDSA certs (? _RSA??? Maybe even ECDH_ECDSA???)?
Testing 370 ciphers via OpenSSL plus sockets against the server, ordered by
encryption strength
Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption Bits
Cipher Suite Name (IANA/RFC)
-----------------------------------------------------------------------------------------------------------------------------
x1302 TLS_AES_256_GCM_SHA384 ECDH 256 AESGCM 256
TLS_AES_256_GCM_SHA384
xc02c ECDHE-ECDSA-AES256-GCM-SHA384 ECDH 256 AESGCM 256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
xc024 ECDHE-ECDSA-AES256-SHA384 ECDH 256 AES 256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
xc00a ECDHE-ECDSA-AES256-SHA ECDH 256 AES 256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
xc032 ECDH-RSA-AES256-GCM-SHA384 ECDH/RSA AESGCM 256
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
xc02e ECDH-ECDSA-AES256-GCM-SHA384 ECDH/ECDSA AESGCM 256
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
xc02a ECDH-RSA-AES256-SHA384 ECDH/RSA AES 256
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
xc026 ECDH-ECDSA-AES256-SHA384 ECDH/ECDSA AES 256
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
xc00f ECDH-RSA-AES256-SHA ECDH/RSA AES 256
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
xc005 ECDH-ECDSA-AES256-SHA ECDH/ECDSA AES 256
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
x1301 TLS_AES_128_GCM_SHA256 ECDH 256 AESGCM 128
TLS_AES_128_GCM_SHA256
xc02b ECDHE-ECDSA-AES128-GCM-SHA256 ECDH 256 AESGCM 128
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
xc023 ECDHE-ECDSA-AES128-SHA256 ECDH 256 AES 128
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
xc009 ECDHE-ECDSA-AES128-SHA ECDH 256 AES 128
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
xc031 ECDH-RSA-AES128-GCM-SHA256 ECDH/RSA AESGCM 128
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
xc02d ECDH-ECDSA-AES128-GCM-SHA256 ECDH/ECDSA AESGCM 128
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
xc029 ECDH-RSA-AES128-SHA256 ECDH/RSA AES 128
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
xc025 ECDH-ECDSA-AES128-SHA256 ECDH/ECDSA AES 128
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
xc00e ECDH-RSA-AES128-SHA ECDH/RSA AES 128
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
xc004 ECDH-ECDSA-AES128-SHA ECDH/ECDSA AES 128
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
Same cert works on the openssl connector (or an apache httpd) and does not show
this issue (only ECDHE key exchange and ECDSA signature, well openssl does not
implement ECDH-ECDSA).
Testing 370 ciphers via OpenSSL plus sockets against the server, ordered by
encryption strength
Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption Bits
Cipher Suite Name (IANA/RFC)
-----------------------------------------------------------------------------------------------------------------------------
x1302 TLS_AES_256_GCM_SHA384 ECDH 253 AESGCM 256
TLS_AES_256_GCM_SHA384
x1303 TLS_CHACHA20_POLY1305_SHA256 ECDH 253 ChaCha20 256
TLS_CHACHA20_POLY1305_SHA256
xc02c ECDHE-ECDSA-AES256-GCM-SHA384 ECDH 253 AESGCM 256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
xc024 ECDHE-ECDSA-AES256-SHA384 ECDH 253 AES 256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
xc00a ECDHE-ECDSA-AES256-SHA ECDH 253 AES 256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
xcca9 ECDHE-ECDSA-CHACHA20-POLY1305 ECDH 253 ChaCha20 256
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
xc0af ECDHE-ECDSA-AES256-CCM8 ECDH 253 AESCCM8 256
TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8
xc0ad ECDHE-ECDSA-AES256-CCM ECDH 253 AESCCM 256
TLS_ECDHE_ECDSA_WITH_AES_256_CCM
xc073 ECDHE-ECDSA-CAMELLIA256-SHA384 ECDH 253 Camellia 256
TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384
xc05d ECDHE-ECDSA-ARIA256-GCM-SHA384 ECDH 253 ARIAGCM 256
TLS_ECDHE_ECDSA_WITH_ARIA_256_GCM_SHA384
x1301 TLS_AES_128_GCM_SHA256 ECDH 253 AESGCM 128
TLS_AES_128_GCM_SHA256
xc02b ECDHE-ECDSA-AES128-GCM-SHA256 ECDH 253 AESGCM 128
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
xc023 ECDHE-ECDSA-AES128-SHA256 ECDH 253 AES 128
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
xc009 ECDHE-ECDSA-AES128-SHA ECDH 253 AES 128
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
xc0ae ECDHE-ECDSA-AES128-CCM8 ECDH 253 AESCCM8 128
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
xc0ac ECDHE-ECDSA-AES128-CCM ECDH 253 AESCCM 128
TLS_ECDHE_ECDSA_WITH_AES_128_CCM
xc072 ECDHE-ECDSA-CAMELLIA128-SHA256 ECDH 253 Camellia 128
TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256
xc05c ECDHE-ECDSA-ARIA128-GCM-SHA256 ECDH 253 ARIAGCM 128
TLS_ECDHE_ECDSA_WITH_ARIA_128_GCM_SHA256
There is probably more complexity to implementation of ECDSA in Tomcat with
JSSE?!?
Peter
> Felix
>
>>
>> Happy new Year!
>>
>> Peter
>>
>>> Felix
>>>
>>>>> Peter
>>>> -chris
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
