Hello, It is a PKIX KeyManager with a loaded P12 key store. But I tried quite a few alternatives, so maybe there is something wrong within all the commented code. If you think it should work I can try to clean it up for reproduction.
Gruss Bernd -- http://bernd.eckenfels.net ________________________________ From: Xuelei Fan <xuelei....@oracle.com> Sent: Tuesday, May 23, 2017 9:12:10 PM To: Bernd; security-dev@openjdk.java.net Subject: Re: ECC Key Usage ignored with and ECDH(E) ciphers Hi Bernd, What are the JSSE key/trust managers used for the testing ("SunX509" or "PKIX")? Thanks & Regards, Xuelei On 5/23/2017 7:08 AM, Bernd wrote: > Hello, > > according to RFC 4492 the key usage for ECDHE and ECDH ciphers need to > be observed in regards to key agreement: When I use ECDH_ECDSA ciphers > then the server certificate must have the keyAgreement usage. When I use > ECDHE_ECDSA ciphers then the server certificate must have > "digitalSignature". > > # Note that there is no structural difference between ECDH and ECDSA > # keys. A certificate issuer may use X.509 v3 keyUsage and > # extendedKeyUsage extensions to restrict the use of an ECC public key > # to certain computations [15 > <https://tools.ietf.org/search/rfc4492#ref-15>]. This document refers to an > ECC key as > # ECDH-capable if its use in ECDH is permitted. ECDSA-capable is > # defined similarly. > > > This rule is enforced by the openssl s_client: when the server proposes > a cipher which does not pass this check it will terminate the connection: > > > openssl s_client -cipher ECDHE-ECDSA-AES128-SHA256 -connect > localhost:1234 > > 1252:error:1411713E:SSL routines:ssl_check_srvr_ecc_cert_and_alg:ecc > cert not for signing:.\ssl\ssl_lib.c:2512: > > 1252:error:14082130:SSL routines:ssl3_check_cert_and_algorithm:bad > ecc cert:.\ssl\s3_clnt.c:3544: > > In this case the certificate had key usage: > > > [ server-exch ] > > extendedKeyUsage = serverAuth > > basicConstraints = CA:FALSE > > keyUsage = keyAgreement > > subjectAltName=IP:127.0.0.1,DNS:localhost. > > The connect with static ECDH works: > > > openssl s_client -cipher ECDH-ECDSA-AES128-SHA256 -connect localhost:1234 > ... > > SSL-Session: > > Protocol : TLSv1.2 > > Cipher : ECDH-ECDSA-AES128-SHA256 > > The other way around, when I use the following key usage: > > > [ server-sign ] > > extendedKeyUsage = serverAuth > > basicConstraints = CA:FALSE > > keyUsage = digitalSignature > > subjectAltName=IP:127.0.0.1,DNS:localhost. > > OpenSSL client works this way: > > >openssl s_client -cipher ECDH-ECDSA-AES128-SHA256 -connect localhost:1234 > >9916:error:1411713D:SSL routines:ssl_check_srvr_ecc_cert_and_alg:ecc > cert not for key agreement > > >openssl s_client -cipher ECDHE-ECDSA-AES128-SHA256 -connect localhost:1234 > >SSL-Session: > > Protocol : TLSv1.2 > > Cipher : ECDHE-ECDSA-AES128-SHA256 > > In both cases however JSSE (OracleJDK8u121 or OpenJDK 9-ea+162) will > offer both cipher suites and not filter them by key usage capabilties. > Would you agree this is a bug? And should this also apply to client > side? I have not tested it with RSA certificates, but I would expect > this to be the same. > > Gruss > Bernd > > PS: config file and openssl commands to create multiple ECC certificates > used for this test: > https://gist.github.com/ecki/d66d79bf0cf12872d015804f5edec6e4 > >
