You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by logo <lo...@kreuser.name> on 2019/12/26 23:55:07 UTC
ECDSA Private Keys
Hi Mark,
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?
Best regards
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: ECDSA Private Keys
Posted by logo <lo...@kreuser.name>.
> Am 02.01.2020 um 17:13 schrieb Christopher Schultz <ch...@christopherschultz.net>:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Peter,
>
> On 1/2/20 04:24, logo wrote:
>
>> 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)
>> ----------------------------------------------------------------------
> - -------------------------------------------------------
>>
>>
>>
<snip>
>> There is probably more complexity to implementation of ECDSA in
>> Tomcat with JSSE?!?
>
> I seem to remember a bug where Tomcat does not check the "usage" of a
> key before trying to use it. I couldn't find it in BZ, maybe it was
> fixed in some partial way.
>
> What do those lists represent? All the cipher suites tried, or all
> that connected successfully?
>
testssl.sh [1] tries a list of 370 ciphers. Apparently those are the successful socket connects.
[1] https://github.com/drwetter/testssl.sh
Peter
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4OFroACgkQHPApP6U8
> pFifJw//befvNHGem8GtKH5ds3bEdZk/nvxi1FsytOMA7YplenYI7LxnPrHYeQj0
> L6jUxgYJk5canTmCi/Zw2st03wCAXCfO+AHUYDu4TwA+Ml7ij+cmwtt5Di9onhg0
> c23bDS8WNkiTA6aW4dX5RgPj7+C60k8he+uLCpeoDjWh6b778IR7UcRdd+9uFdVU
> wx4ILhl1MNnbQeyH6UMolQA4ms+4HG09mDYcQwK4B5VejQnbtzud1hkB0mJJCCes
> MbSaE/6BA4cs9feHV8rzWqy1EW5v9MyfbgNweFMS2GJXHNr1mMiUbmW5clnGphL5
> OhLonEA8FFaceuutePz+LefQiznsbCBljSuKTB4nzy14KY3mDBAyxp3N3SLD+Rno
> Aowhp657foWlre652MORmgK7KZWGg8PZ3fxtIuGXFxk9uY0Ib0x3jvvMxm0XWMW0
> BysOmO1LW6kDKUBZSxBh1ZBq4hExySWdn2wT8n4tbYnPdDcun1EjXKSYofKevRXP
> +CDY8GER1TpLasiDbL9FHYcEtOIsKgGg85REfB13zlMkUNleTEinM7laLQnUFyIt
> hHB7Ua28lykMI3CpaOWDFfNhtzsRW5TRh7DT84OCqnnQQl3vz0Xxr6pg1dPT3M+o
> Ns3Hcr/MhgD05sOcA9i3hGRmtpRcYYznqQYdTMSxjb9HWzEjDpk=
> =A9OL
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: ECDSA Private Keys
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Peter,
On 1/2/20 04:24, logo wrote:
> 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?!?
I seem to remember a bug where Tomcat does not check the "usage" of a
key before trying to use it. I couldn't find it in BZ, maybe it was
fixed in some partial way.
What do those lists represent? All the cipher suites tried, or all
that connected successfully?
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4OFroACgkQHPApP6U8
pFifJw//befvNHGem8GtKH5ds3bEdZk/nvxi1FsytOMA7YplenYI7LxnPrHYeQj0
L6jUxgYJk5canTmCi/Zw2st03wCAXCfO+AHUYDu4TwA+Ml7ij+cmwtt5Di9onhg0
c23bDS8WNkiTA6aW4dX5RgPj7+C60k8he+uLCpeoDjWh6b778IR7UcRdd+9uFdVU
wx4ILhl1MNnbQeyH6UMolQA4ms+4HG09mDYcQwK4B5VejQnbtzud1hkB0mJJCCes
MbSaE/6BA4cs9feHV8rzWqy1EW5v9MyfbgNweFMS2GJXHNr1mMiUbmW5clnGphL5
OhLonEA8FFaceuutePz+LefQiznsbCBljSuKTB4nzy14KY3mDBAyxp3N3SLD+Rno
Aowhp657foWlre652MORmgK7KZWGg8PZ3fxtIuGXFxk9uY0Ib0x3jvvMxm0XWMW0
BysOmO1LW6kDKUBZSxBh1ZBq4hExySWdn2wT8n4tbYnPdDcun1EjXKSYofKevRXP
+CDY8GER1TpLasiDbL9FHYcEtOIsKgGg85REfB13zlMkUNleTEinM7laLQnUFyIt
hHB7Ua28lykMI3CpaOWDFfNhtzsRW5TRh7DT84OCqnnQQl3vz0Xxr6pg1dPT3M+o
Ns3Hcr/MhgD05sOcA9i3hGRmtpRcYYznqQYdTMSxjb9HWzEjDpk=
=A9OL
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: ECDSA Private Keys
Posted by Mark Thomas <ma...@apache.org>.
On 02/01/2020 09:24, logo wrote:
<snip/>
> Testing 370 ciphers via OpenSSL plus sockets against the server, ordered by encryption strength
I've been through these and this is the summary of the results.
I'm testing OpenSSL master (although not updated for a while) and JSSE
from AdoptOpenJDK 1.8.0_222-b10
Cipher suites supported and reported by both implementations:
C009, C00A, C023, C024, C02B, C02C
Note: These cipher suites are used with slightly different
configurations because OpenSSL and JSSE support different curves
All the remaining OpenSSL cipher suites are not supported by JSSE.
All of the remaining JSSE cipher suites are not supported by OpenSSL
(they were removed in 1.1.0).
So while the results appear to be very different, those differences are
explainable.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: ECDSA Private Keys
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Peter,
On 1/10/20 2:07 PM, logo wrote:
> Chris and Mark,
>
>
>> Am 09.01.2020 um 21:49 schrieb Christopher Schultz
>> <ch...@christopherschultz.net>:
>>
> All,
>
> On 1/9/20 3:45 PM, Christopher Schultz wrote:
>>>> Mark and Peter,
>>>>
>>>> On 1/9/20 3:36 PM, Mark Thomas wrote:
>>>>> On 09/01/2020 20:22, logo wrote:
>>>>>> Mark,
>>>>>>
>>>>>>> Am 09.01.2020 um 20:36 schrieb Mark Thomas
>>>>>>> <ma...@apache.org>:
>>>>>>>
>>>>>>> On 02/01/2020 09:24, logo wrote:
>>>>>>>
>>>>>>> <snip/>
>>>>>>>
>>>>>>>> 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
>>>>>>
>>>>>> The key usage error is caused by identifying ECDH_RSA
>>>>>> ciphers on the connector… (most certainly an unexpected
>>>>>> edge case, I’ve debugged it that far). That should not be
>>>>>> the case - as it is an ECDSA Cert, right?
>>>>
>>>>> I don't think so.
>>>>
>>>>> I'm seeing ECHD/RSA ciphers in the output and I am not
>>>>> getting that warning.
>>>>
>>>>> My reading of a couple of questions on stack exchange
>>>>> suggests RSA vs DSA ciphers depends on how the CA signs the
>>>>> cert. My test CA signs with RSA.
>>>>
>
>> Root and Intermediate are RSA-signed.
>
>> Cert is: Signature Algorithm ECDSA with SHA256 Server key
>> size EC 256 bits
>
>
>>>> DSA is almost never used. Nearly 100% of keys in the world
>>>> are plain-RSA or EC. I know of no CA that uses DSA for
>>>> signing. So pretty much every cert you will come across will
>>>> be EC-with-RSA or RSA-with-RSA (that's
>>>> keytype-with-signature-type).
>
> Obviously, the above is a mixture of half-truths and irrelevant
> information. I was thinking of RSA versus DSA keys, not ECDSA as a
> signature algorithm in its own right.
>
>> Maybe I’m causing a lot of hassle by asking these questions. So
>> far I was happy to get a cert with a key, drop it in the right
>> spot and all worked well. If I stick to RSA that should stay like
>> this.
The choice of RSA versus ECDSA is really up to you. Modern TLS will
use ECDH for key agreement regardless of the certificate. This is how
you get your forward-secrecy and it's a Good Thing. RSA and ECDSA
certs are only used for authentication (checking the identity and
trust of the site).
RSA requires more CPU time for an equivalent-strength ECSDA key, so
the obvious choice is ECDSA, right? Well, maybe not. Evidently, RSA is
more resistant to quantum attacks (which are officially theoretical
ATM), so RSA with a big-old key is your best bet if you are wearing a
nice, thick tin-foil hat.
Frankly, since the authentication step is quite short compared to the
bulk encryption (which usually uses AES or some similarly fast
symmetric encryption algorithm), the choice comes down to user
preference. There is no clear winner for RSA versus ECSDA for
certificates.
But all software should work with all available primitives. So if
Tomcat can't handle this for some reason and you just happen to be the
first person to hit it, let's get it fixed (with respect and thanks to
markt's efforts).
The last thing we need is a monoculture where everything is using ECDH
for key agreement (which is, AIUI, mathematically correct), RSA for
authentication, AES for encryption, and SHA256 for signing. IF
everyone is using the same cipher suite, then it means (a) the Bad
Guys have an obvious target and (b) any problem with the design or
implementation of that cipher suite, TLS, or e.g. OpenSSL means that
the whole world is suddenly vulnerable.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4bTf4ACgkQHPApP6U8
pFj3/A//QndJMeUl7fJLo/61IFaSLpHTvMEwRVPLBLGSNpAF+P4U8/gpWsHJtDGD
T2PuVyKLLy/Skb69sgFzb1r+Un2+7pTTPp2M+hPEVH09wBVis2RDRefUJH/b5Eyp
/gUp7f7o01UjHw484/ocTzRedlv5ZoHN+9V+7dNBXOuvucwu1YWnyO6gd9oHAZkj
//Hopus4R/oS47wGY64fiwD2Xqr8FkxLx7c1zfWCiGETQF+Q2AYslccZE+5jevSs
EZiqwmgHYbzJqikJxpqg80pX4lcXwZxUllvvpMCxvPndlB36Azy5p0DXsni42uet
hjDpJEtQYsdABP5ODGivQEv/rucq7phaehNuobPJUtmIKiAmapDj8T2BSld1f0CB
S85rSbSJGM5/hnv92t0sz3ZMZHKdJyiu73E2YMd31kBJtV94cV71sOcpCByN698c
d59RTYVbqP7VsXP/1TYR4EaqIqyruPa3u1v6zx23/DlafWFCmvoxUiBXiozYZ/4F
ePFJ2PiUXAyhy/WA3xTD95FbRqs+ip9W0P7VNiuPHLbSrumPpawy/AOXtYWxbsp9
PQdwdbu7oK8SuPCLSj4S/oFn6P+jZ1TJ+rZXZhuc+pjAprZVSI5J7VkupNmPDVNb
STEjG/LwasiaJPkO8/AC6n3EVhMye8ZsXX2XIzhBs0m1TpGCumI=
=18Im
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: ECDSA Private Keys
Posted by logo <lo...@kreuser.name>.
Chris and Mark,
> Am 09.01.2020 um 21:49 schrieb Christopher Schultz <ch...@christopherschultz.net>:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> All,
>
> On 1/9/20 3:45 PM, Christopher Schultz wrote:
>> Mark and Peter,
>>
>> On 1/9/20 3:36 PM, Mark Thomas wrote:
>>> On 09/01/2020 20:22, logo wrote:
>>>> Mark,
>>>>
>>>>> Am 09.01.2020 um 20:36 schrieb Mark Thomas
>>>>> <ma...@apache.org>:
>>>>>
>>>>> On 02/01/2020 09:24, logo wrote:
>>>>>
>>>>> <snip/>
>>>>>
>>>>>> 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
>>>>
>>>> The key usage error is caused by identifying ECDH_RSA ciphers
>>>> on the connector… (most certainly an unexpected edge case,
>>>> I’ve debugged it that far). That should not be the case - as it
>>>> is an ECDSA Cert, right?
>>
>>> I don't think so.
>>
>>> I'm seeing ECHD/RSA ciphers in the output and I am not getting
>>> that warning.
>>
>>> My reading of a couple of questions on stack exchange suggests
>>> RSA vs DSA ciphers depends on how the CA signs the cert. My test
>>> CA signs with RSA.
>>
Root and Intermediate are RSA-signed.
Cert is:
Signature Algorithm ECDSA with SHA256
Server key size EC 256 bits
>> DSA is almost never used. Nearly 100% of keys in the world are
>> plain-RSA or EC. I know of no CA that uses DSA for signing. So
>> pretty much every cert you will come across will be EC-with-RSA or
>> RSA-with-RSA (that's keytype-with-signature-type).
>
> Obviously, the above is a mixture of half-truths and irrelevant
> information. I was thinking of RSA versus DSA keys, not ECDSA as a
> signature algorithm in its own right.
Maybe I’m causing a lot of hassle by asking these questions. So far I was happy to get a cert with a key, drop it in the right spot and all worked well. If I stick to RSA that should stay like this.
So actually it won’t be a problem of the client - as long as it finds one matching cipher. So for now, we should be fine if an EC-key is supported.
Nevertheless I will try to contact Dirk Wetter and ask him if he can explain the finding.
Peter
>
> Carry on...
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4XkdgACgkQHPApP6U8
> pFiJ/xAAudFM0wtuRNTIZy6hHGpwLZ4QX6Z9mbWYBYJ93eId8VKL8jQyHgkGTXyT
> OZ2moW+13Grr5zGxo7WgS4EGc1+MKnrBfSY0BwQJwKCwDCJOKTCqMjSybUMrrM7Y
> POf/Lwc+KbxTNhMd7KonxpwYOhox6Cu+I0wh/EQl5jsJCDK4VFW9Y7BjywlQsGjI
> reYQCEu7Sc98c+x8lw1eb6soAj7cIRzmyf8lofS0eOXW10waesIrZSL+8/QyiGd6
> ku6198xaB4ofGOaeXBOO3L91e/2Kx4oRPd0FQHqe0h/nUp9+YJbOr6ypub9nCuuX
> Oq/MAPUv2Abds3mYAAdRNipJmsGmcud3dgJubzmVAQqfoJTCZHtn90p7IBJGK1t0
> 7nCmFCDGdqEYv43v6lBrzc6X5BBMT99c7gZ7pqWq7n2lAmorVNZK3rDkT4wMUjP3
> OO0YapUd2+PyrneBFGb5e6lHvzHGk6sbKTNoeMkcMFAD3S5cE20w79gBruYP3y3B
> PlwFIXmYQTGBExIpTxZQziD19yKsavi8tMXWfLHt9yw04a9vIxeQdaSG6sFLQrj7
> ZzyX1q9uhxieyTNNjwaDxhkLpnSJDHelu5SLV32TBr+9OL3426r3cVsivQQlouWD
> iAGdB84DMZLj0dINM1Y7XJHe/4FHjoMfnn7ELIiTdYmPm1sLJMQ=
> =c/td
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: ECDSA Private Keys
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
All,
On 1/9/20 3:45 PM, Christopher Schultz wrote:
> Mark and Peter,
>
> On 1/9/20 3:36 PM, Mark Thomas wrote:
>> On 09/01/2020 20:22, logo wrote:
>>> Mark,
>>>
>>>> Am 09.01.2020 um 20:36 schrieb Mark Thomas
>>>> <ma...@apache.org>:
>>>>
>>>> On 02/01/2020 09:24, logo wrote:
>>>>
>>>> <snip/>
>>>>
>>>>> 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
>>>
>>> The key usage error is caused by identifying ECDH_RSA ciphers
>>> on the connector… (most certainly an unexpected edge case,
>>> I’ve debugged it that far). That should not be the case - as it
>>> is an ECDSA Cert, right?
>
>> I don't think so.
>
>> I'm seeing ECHD/RSA ciphers in the output and I am not getting
>> that warning.
>
>> My reading of a couple of questions on stack exchange suggests
>> RSA vs DSA ciphers depends on how the CA signs the cert. My test
>> CA signs with RSA.
>
> DSA is almost never used. Nearly 100% of keys in the world are
> plain-RSA or EC. I know of no CA that uses DSA for signing. So
> pretty much every cert you will come across will be EC-with-RSA or
> RSA-with-RSA (that's keytype-with-signature-type).
Obviously, the above is a mixture of half-truths and irrelevant
information. I was thinking of RSA versus DSA keys, not ECDSA as a
signature algorithm in its own right.
Carry on...
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4XkdgACgkQHPApP6U8
pFiJ/xAAudFM0wtuRNTIZy6hHGpwLZ4QX6Z9mbWYBYJ93eId8VKL8jQyHgkGTXyT
OZ2moW+13Grr5zGxo7WgS4EGc1+MKnrBfSY0BwQJwKCwDCJOKTCqMjSybUMrrM7Y
POf/Lwc+KbxTNhMd7KonxpwYOhox6Cu+I0wh/EQl5jsJCDK4VFW9Y7BjywlQsGjI
reYQCEu7Sc98c+x8lw1eb6soAj7cIRzmyf8lofS0eOXW10waesIrZSL+8/QyiGd6
ku6198xaB4ofGOaeXBOO3L91e/2Kx4oRPd0FQHqe0h/nUp9+YJbOr6ypub9nCuuX
Oq/MAPUv2Abds3mYAAdRNipJmsGmcud3dgJubzmVAQqfoJTCZHtn90p7IBJGK1t0
7nCmFCDGdqEYv43v6lBrzc6X5BBMT99c7gZ7pqWq7n2lAmorVNZK3rDkT4wMUjP3
OO0YapUd2+PyrneBFGb5e6lHvzHGk6sbKTNoeMkcMFAD3S5cE20w79gBruYP3y3B
PlwFIXmYQTGBExIpTxZQziD19yKsavi8tMXWfLHt9yw04a9vIxeQdaSG6sFLQrj7
ZzyX1q9uhxieyTNNjwaDxhkLpnSJDHelu5SLV32TBr+9OL3426r3cVsivQQlouWD
iAGdB84DMZLj0dINM1Y7XJHe/4FHjoMfnn7ELIiTdYmPm1sLJMQ=
=c/td
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: ECDSA Private Keys
Posted by Stefan Mayr <st...@mayr-stefan.de>.
Am 09.01.2020 um 21:45 schrieb Christopher Schultz:
> DSA is almost never used. Nearly 100% of keys in the world are
> plain-RSA or EC. I know of no CA that uses DSA for signing. So pretty
> much every cert you will come across will be EC-with-RSA or
> RSA-with-RSA (that's keytype-with-signature-type).
I guess this might change. Let's Encrypt is quite popular and plans to
change to ECDSA for Root and Intermediate certificates
Source: https://letsencrypt.org/upcoming-features/
- Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: ECDSA Private Keys
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark and Peter,
On 1/9/20 3:36 PM, Mark Thomas wrote:
> On 09/01/2020 20:22, logo wrote:
>> Mark,
>>
>>> Am 09.01.2020 um 20:36 schrieb Mark Thomas <ma...@apache.org>:
>>>
>>> On 02/01/2020 09:24, logo wrote:
>>>
>>> <snip/>
>>>
>>>> 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
>>
>> The key usage error is caused by identifying ECDH_RSA ciphers on
>> the connector… (most certainly an unexpected edge case, I’ve
>> debugged it that far). That should not be the case - as it is an
>> ECDSA Cert, right?
>
> I don't think so.
>
> I'm seeing ECHD/RSA ciphers in the output and I am not getting that
> warning.
>
> My reading of a couple of questions on stack exchange suggests RSA
> vs DSA ciphers depends on how the CA signs the cert. My test CA
> signs with RSA.
DSA is almost never used. Nearly 100% of keys in the world are
plain-RSA or EC. I know of no CA that uses DSA for signing. So pretty
much every cert you will come across will be EC-with-RSA or
RSA-with-RSA (that's keytype-with-signature-type).
> key usage and extended key usage are properties of the certificate.
> My understanding is that the cipher doesn't play a role here.
+1
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4XkMsACgkQHPApP6U8
pFjECA/8CBx2d+AoQ8zi4rkatrow7c0VuzY/FVGS9nbwtevsiPhV6JXHPwarT1iX
WWQta+brIbNf6LHBjC1UpkCpJpoumgNPpmwofv5+gTj1dbhnpLhsWEZaiHYRPQ7Y
90Q5JbdnvSJZOdupbY+swtw9V/8yJt+D3VFdaUAchSibPKyYReGWr0ctMlRwmH7S
h+qGTrxfAxff8CCnw6upeDnMnN1LznPFut3UJT1OCQ/H92IXXvmK652oyU6SjZ3A
t47Yyuj/DvXN6CHVQouM4J5W2uxujOFJGLpqRxZ73EyThrRwijN/FtWBD51LPCk4
BpXYNA6Epobd9TnYZDt638WW0HOrkzh15a37kzD4ONGGJEJMVW65uqram7UMVnIY
I2QoKYRM+3PZfrUFl1Elaspy2rFfUJiLdtWscRE207tmYN4smW24DnwuxQNKWYCn
6SMvVPzzmfPY4oNXwKNhO+ZGaLHAdezQUyD5jpgu1AFB0iztrWTc5Gm+b2v2B+/Q
rwAn63NhKaG10jrmTrqoMeVDNkBPOGHiQL6mf730TsvD12WfojwP2IgVrSv3j+RY
27dhoR3OGQGFldq/lHVJ22awEGvdDc82gQzt3RvbMiSdcp/hikrTE4xbdEQFpdps
1piz2DnIwdMMQiAdCCucem52kv1CRFJUWgsBMLiRE0nIuRSrMGA=
=oqwA
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: ECDSA Private Keys
Posted by Mark Thomas <ma...@apache.org>.
On 09/01/2020 20:22, logo wrote:
> Mark,
>
>> Am 09.01.2020 um 20:36 schrieb Mark Thomas <ma...@apache.org>:
>>
>> On 02/01/2020 09:24, logo wrote:
>>
>> <snip/>
>>
>>> 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
>
> The key usage error is caused by identifying ECDH_RSA ciphers on the connector… (most certainly an unexpected edge case, I’ve debugged it that far). That should not be the case - as it is an ECDSA Cert, right?
I don't think so.
I'm seeing ECHD/RSA ciphers in the output and I am not getting that warning.
My reading of a couple of questions on stack exchange suggests RSA vs
DSA ciphers depends on how the CA signs the cert. My test CA signs with RSA.
key usage and extended key usage are properties of the certificate. My
understanding is that the cipher doesn't play a role here.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: ECDSA Private Keys
Posted by logo <lo...@kreuser.name>.
Mark,
> Am 09.01.2020 um 20:36 schrieb Mark Thomas <ma...@apache.org>:
>
> On 02/01/2020 09:24, logo wrote:
>
> <snip/>
>
>> 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
The key usage error is caused by identifying ECDH_RSA ciphers on the connector… (most certainly an unexpected edge case, I’ve debugged it that far). That should not be the case - as it is an ECDSA Cert, right?
>
> The allowed usages are configured when a certificate is created. See:
> https://www.openssl.org/docs/manmaster/man5/x509v3_config.html
>
> You need to take this up with your Certificate Authority.
The CA is issuing the right cert with appropriate usage for a Webserver "Digital Signature, Key Encipherment".
>
> I'll look at the cipher differences next.
>
testssl.sh -e https://<server>:<port> should give you my result.
Thanks.
Peter
[1] https://github.com/drwetter/testssl.sh <https://github.com/drwetter/testssl.sh>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: ECDSA Private Keys
Posted by Mark Thomas <ma...@apache.org>.
On 02/01/2020 09:24, logo wrote:
<snip/>
> 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
The allowed usages are configured when a certificate is created. See:
https://www.openssl.org/docs/manmaster/man5/x509v3_config.html
You need to take this up with your Certificate Authority.
I'll look at the cipher differences next.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: ECDSA Private Keys
Posted by logo <lo...@kreuser.name>.
Felix,
> Am 01.01.2020 um 20:27 schrieb Felix Schumacher <fe...@internetallee.de>:
>
>
>> Am 01.01.20 um 18:19 schrieb logo:
>> Felix,
>>
>>>> Am 01.01.2020 um 11:49 schrieb Felix Schumacher <fe...@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-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: ECDSA Private Keys
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 01.01.20 um 18:19 schrieb logo:
> Felix,
>
>> Am 01.01.2020 um 11:49 schrieb Felix Schumacher <fe...@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.
Felix
>
> Happy new Year!
>
> Peter
>
>> Felix
>>
>>>> Peter
>>> -chris
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: ECDSA Private Keys
Posted by logo <lo...@kreuser.name>.
Felix,
> Am 01.01.2020 um 11:49 schrieb Felix Schumacher <fe...@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!
> 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
Happy new Year!
Peter
> Felix
>
>>
>>> Peter
>>
>> -chris
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: ECDSA Private Keys
Posted by Felix Schumacher <fe...@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.
Have you tried to convert your key to pkcs8?
Felix
>
> > Peter
>
> -chris
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: ECDSA Private Keys
Posted by logo <lo...@kreuser.name>.
Chris
Am 2019-12-27 16:33, schrieb Christopher Schultz:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> 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".
Peter
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4GJDIACgkQHPApP6U8
> pFi1HBAAxzrE1P4o2nj9/6/nr9sVEiPOusw30P2YnaJGvvkv2jvHoj1TITGVlaTg
> Y/Oy4GPA7NEn0ofRPFwaphL0+kETxZyHSBotxtlsOZsg2aLj2tLKCmwCZe2UfPcA
> nRmVtn+TgPOHOb3x+sSKhOzv73SjbnqVVRQLCa/4t/D/S8nfR6Lc9yqPibLI4y/+
> +gqnKhs7TW5f74ZAMjLlWKrEwbsr1KRcCW7G4vA6859fxDtPSckPR5MoHBe3H/pK
> 2D26EoNb5jZ5McxgM9xmGe74lYXp3XVOQLEOZnBNAjGd6VWs4oyHFbc3/800vD6E
> gyQLgFonupS0XE3gj0cy3HVWggSQhd9AlQXwyBNQg8UWA4tQNhRiPTvgX5gAYWnf
> AHBKPb5LpDm8cEkCM63Ow92ce4a6JHFBxEs2TX2h14iHGCk1ARERiM2tgltugxub
> vmkJLGkDGd6EM2B62Wv8dnA6/1qtebgrW6IcZrESEKaP3T5qYivs5uUq4sYLXMho
> G8v24Om8tRDOCoE1gl+UIWRsoMZQttOJSYwbBriOWa7OJ3PSq3nzE22zSgqhqHOh
> QwPBXMSYQNz6aMXKxCwwS5GjdrRQqIQINi8YbRf4Wjre4zZNIzPJ4FgDtROQYl85
> 32Gsa4pcwyEtM2a+8iH98dXhpP5ST1CxCiGXhlzEFmXbFgSadKg=
> =aSBb
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: ECDSA Private Keys
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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?
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4GJDIACgkQHPApP6U8
pFi1HBAAxzrE1P4o2nj9/6/nr9sVEiPOusw30P2YnaJGvvkv2jvHoj1TITGVlaTg
Y/Oy4GPA7NEn0ofRPFwaphL0+kETxZyHSBotxtlsOZsg2aLj2tLKCmwCZe2UfPcA
nRmVtn+TgPOHOb3x+sSKhOzv73SjbnqVVRQLCa/4t/D/S8nfR6Lc9yqPibLI4y/+
+gqnKhs7TW5f74ZAMjLlWKrEwbsr1KRcCW7G4vA6859fxDtPSckPR5MoHBe3H/pK
2D26EoNb5jZ5McxgM9xmGe74lYXp3XVOQLEOZnBNAjGd6VWs4oyHFbc3/800vD6E
gyQLgFonupS0XE3gj0cy3HVWggSQhd9AlQXwyBNQg8UWA4tQNhRiPTvgX5gAYWnf
AHBKPb5LpDm8cEkCM63Ow92ce4a6JHFBxEs2TX2h14iHGCk1ARERiM2tgltugxub
vmkJLGkDGd6EM2B62Wv8dnA6/1qtebgrW6IcZrESEKaP3T5qYivs5uUq4sYLXMho
G8v24Om8tRDOCoE1gl+UIWRsoMZQttOJSYwbBriOWa7OJ3PSq3nzE22zSgqhqHOh
QwPBXMSYQNz6aMXKxCwwS5GjdrRQqIQINi8YbRf4Wjre4zZNIzPJ4FgDtROQYl85
32Gsa4pcwyEtM2a+8iH98dXhpP5ST1CxCiGXhlzEFmXbFgSadKg=
=aSBb
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: ECDSA Private Keys
Posted by Mark Thomas <ma...@apache.org>.
On 08/01/2020 21:39, logo wrote:
<snip/>
>> I have confirmed that this updated key then works cleanly with both the
>> OpenSSL and JSSE TLS implementations.
>>
>
> Felix already suggested that. I've tried it and at first it looks good. Connector starts and serves the ECDSA cert.
Sorry I missed that. It was late and I was trying to do things too quickly.
> Please see the last two emails with the findings of the testssl.sh scans. I don’t know but tomcat now also serves strange ciphers… (at least some that openssl doesn’t even support and the scanner gets some strange results!)
>
> https://markmail.org/message/nj7lvuplld4c5nqx
ACK. I'll try and dig deeper once I've tackled the conversion issue.
>> In theory, Tomcat should be able to do this conversion for you. The
>> issue will be how much of the crypto API we need to do that is part of
>> the public API and, where it isn't, how easy it is to craft our own.
>>
>> I'm currently investigating…
>>
>
> Thanks for your support. I got the people at smallstep to create an option to also create RSA certs. So there is currently a workaround to use their acme process with tomcat.
Yes, we can do the conversion. It isn't too bad but I need to clean up
my rather hacky approach to make it more robust before committing it. I
hope to make progress on this today.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: ECDSA Private Keys
Posted by logo <lo...@kreuser.name>.
Hi Mark,
> Am 08.01.2020 um 19:04 schrieb Mark Thomas <ma...@apache.org>:
>
> On 26/12/2019 23:55, logo wrote:
>
> <snip/>
>
>> 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?
>
> Hi,
>
> Sorry for not getting to this sooner.
>
> I'm not 100% sure that Java directly supports the format that includes:
> -----BEGIN EC PRIVATE KEY-----
>
>
> Initial research suggests you need to "update" the format of the key file:
>
> openssl pkcs8 -topk8 -inform pem -in file.key -outform pem -nocrypt -out
> file.pem
>
> I have confirmed that this updated key then works cleanly with both the
> OpenSSL and JSSE TLS implementations.
>
Felix already suggested that. I've tried it and at first it looks good. Connector starts and serves the ECDSA cert.
Please see the last two emails with the findings of the testssl.sh scans. I don’t know but tomcat now also serves strange ciphers… (at least some that openssl doesn’t even support and the scanner gets some strange results!)
https://markmail.org/message/nj7lvuplld4c5nqx
> In theory, Tomcat should be able to do this conversion for you. The
> issue will be how much of the crypto API we need to do that is part of
> the public API and, where it isn't, how easy it is to craft our own.
>
> I'm currently investigating…
>
Thanks for your support. I got the people at smallstep to create an option to also create RSA certs. So there is currently a workaround to use their acme process with tomcat.
Peter
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: ECDSA Private Keys
Posted by Mark Thomas <ma...@apache.org>.
On 26/12/2019 23:55, logo wrote:
<snip/>
> 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?
Hi,
Sorry for not getting to this sooner.
I'm not 100% sure that Java directly supports the format that includes:
-----BEGIN EC PRIVATE KEY-----
Initial research suggests you need to "update" the format of the key file:
openssl pkcs8 -topk8 -inform pem -in file.key -outform pem -nocrypt -out
file.pem
I have confirmed that this updated key then works cleanly with both the
OpenSSL and JSSE TLS implementations.
In theory, Tomcat should be able to do this conversion for you. The
issue will be how much of the crypto API we need to do that is part of
the public API and, where it isn't, how easy it is to craft our own.
I'm currently investigating...
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org