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 >