<!doctype html>
<html>
<head>
<meta charset="UTF-8">
</head>
<body>
<div>
<br>
</div>
<blockquote type="cite">
<div>
On 30 July 2018 at 21:00 ѽ҉ᶬḳ℠ <
<a href="mailto:vtol@gmx.net">vtol@gmx.net</a>>
wrote:
</div>
<div>
<br>
</div>
<div>
<br>
</div>
<div>
<br>
</div>
<blockquote type="cite">
<div>
I did some local testing and it seems that you are using a curve that is
not acceptable for openssl as a server key.
</div>
</blockquote>
<blockquote type="cite">
<div>
I tested with openssl s_server -cert ec-cert.pem -key ec-key.pem -port 5555
</div>
</blockquote>
<blockquote type="cite">
<div>
using cert generated with brainpool. Everything works if I use prime256v1
or secp521r1. This is a limitation in OpenSSL and not something we can really do
anything about.
</div>
</blockquote>
<blockquote type="cite">
<div>
Aki Tuomi
</div>
<div>
Open-Xchange Oy
</div>
</blockquote>
<div>
Which openssl version you are using? This end it is OpenSSL 1.1.0h.
</div>
<div>
There are no issues creating private keys, issuing csr, signing certs
</div>
<div>
with that particular curve. Printing certs and verifying certs against
</div>
<div>
keys is panning out too, comparing md5 hashes also no errors. So why
</div>
<div>
would openssl not accept (limit) keys is has generated and verified with
</div>
<div>
no error?
</div>
<div>
<br>
</div>
<div>
[ openssl ecparam -list_curves ]
</div>
<div>
secp112r1 : SECG/WTLS curve over a 112 bit prime field
</div>
<div>
secp112r2 : SECG curve over a 112 bit prime field
</div>
<div>
secp128r1 : SECG curve over a 128 bit prime field
</div>
<div>
secp128r2 : SECG curve over a 128 bit prime field
</div>
<div>
secp160k1 : SECG curve over a 160 bit prime field
</div>
<div>
secp160r1 : SECG curve over a 160 bit prime field
</div>
<div>
secp160r2 : SECG/WTLS curve over a 160 bit prime field
</div>
<div>
secp192k1 : SECG curve over a 192 bit prime field
</div>
<div>
secp224k1 : SECG curve over a 224 bit prime field
</div>
<div>
secp224r1 : NIST/SECG curve over a 224 bit prime field
</div>
<div>
secp256k1 : SECG curve over a 256 bit prime field
</div>
<div>
secp384r1 : NIST/SECG curve over a 384 bit prime field
</div>
<div>
secp521r1 : NIST/SECG curve over a 521 bit prime field
</div>
<div>
prime192v1: NIST/X9.62/SECG curve over a 192 bit prime field
</div>
<div>
prime192v2: X9.62 curve over a 192 bit prime field
</div>
<div>
prime192v3: X9.62 curve over a 192 bit prime field
</div>
<div>
prime239v1: X9.62 curve over a 239 bit prime field
</div>
<div>
prime239v2: X9.62 curve over a 239 bit prime field
</div>
<div>
prime239v3: X9.62 curve over a 239 bit prime field
</div>
<div>
prime256v1: X9.62/SECG curve over a 256 bit prime field
</div>
<div>
sect113r1 : SECG curve over a 113 bit binary field
</div>
<div>
sect113r2 : SECG curve over a 113 bit binary field
</div>
<div>
sect131r1 : SECG/WTLS curve over a 131 bit binary field
</div>
<div>
sect131r2 : SECG curve over a 131 bit binary field
</div>
<div>
sect163k1 : NIST/SECG/WTLS curve over a 163 bit binary field
</div>
<div>
sect163r1 : SECG curve over a 163 bit binary field
</div>
<div>
sect163r2 : NIST/SECG curve over a 163 bit binary field
</div>
<div>
sect193r1 : SECG curve over a 193 bit binary field
</div>
<div>
sect193r2 : SECG curve over a 193 bit binary field
</div>
<div>
sect233k1 : NIST/SECG/WTLS curve over a 233 bit binary field
</div>
<div>
sect233r1 : NIST/SECG/WTLS curve over a 233 bit binary field
</div>
<div>
sect239k1 : SECG curve over a 239 bit binary field
</div>
<div>
sect283k1 : NIST/SECG curve over a 283 bit binary field
</div>
<div>
sect283r1 : NIST/SECG curve over a 283 bit binary field
</div>
<div>
sect409k1 : NIST/SECG curve over a 409 bit binary field
</div>
<div>
sect409r1 : NIST/SECG curve over a 409 bit binary field
</div>
<div>
sect571k1 : NIST/SECG curve over a 571 bit binary field
</div>
<div>
sect571r1 : NIST/SECG curve over a 571 bit binary field
</div>
<div>
c2pnb163v1: X9.62 curve over a 163 bit binary field
</div>
<div>
c2pnb163v2: X9.62 curve over a 163 bit binary field
</div>
<div>
c2pnb163v3: X9.62 curve over a 163 bit binary field
</div>
<div>
c2pnb176v1: X9.62 curve over a 176 bit binary field
</div>
<div>
c2tnb191v1: X9.62 curve over a 191 bit binary field
</div>
<div>
c2tnb191v2: X9.62 curve over a 191 bit binary field
</div>
<div>
c2tnb191v3: X9.62 curve over a 191 bit binary field
</div>
<div>
c2pnb208w1: X9.62 curve over a 208 bit binary field
</div>
<div>
c2tnb239v1: X9.62 curve over a 239 bit binary field
</div>
<div>
c2tnb239v2: X9.62 curve over a 239 bit binary field
</div>
<div>
c2tnb239v3: X9.62 curve over a 239 bit binary field
</div>
<div>
c2pnb272w1: X9.62 curve over a 272 bit binary field
</div>
<div>
c2pnb304w1: X9.62 curve over a 304 bit binary field
</div>
<div>
c2tnb359v1: X9.62 curve over a 359 bit binary field
</div>
<div>
c2pnb368w1: X9.62 curve over a 368 bit binary field
</div>
<div>
c2tnb431r1: X9.62 curve over a 431 bit binary field
</div>
<div>
wap-wsg-idm-ecid-wtls1: WTLS curve over a 113 bit binary field
</div>
<div>
wap-wsg-idm-ecid-wtls3: NIST/SECG/WTLS curve over a 163 bit binary field
</div>
<div>
wap-wsg-idm-ecid-wtls4: SECG curve over a 113 bit binary field
</div>
<div>
wap-wsg-idm-ecid-wtls5: X9.62 curve over a 163 bit binary field
</div>
<div>
wap-wsg-idm-ecid-wtls6: SECG/WTLS curve over a 112 bit prime field
</div>
<div>
wap-wsg-idm-ecid-wtls7: SECG/WTLS curve over a 160 bit prime field
</div>
<div>
wap-wsg-idm-ecid-wtls8: WTLS curve over a 112 bit prime field
</div>
<div>
wap-wsg-idm-ecid-wtls9: WTLS curve over a 160 bit prime field
</div>
<div>
wap-wsg-idm-ecid-wtls10: NIST/SECG/WTLS curve over a 233 bit binary field
</div>
<div>
wap-wsg-idm-ecid-wtls11: NIST/SECG/WTLS curve over a 233 bit binary field
</div>
<div>
wap-wsg-idm-ecid-wtls12: WTLS curve over a 224 bit prime field
</div>
<div>
Oakley-EC2N-3:
</div>
<div>
IPSec/IKE/Oakley curve #3 over a 155 bit binary field.
</div>
<div>
Not suitable for ECDSA.
</div>
<div>
Questionable extension field!
</div>
<div>
Oakley-EC2N-4:
</div>
<div>
IPSec/IKE/Oakley curve #4 over a 185 bit binary field.
</div>
<div>
Not suitable for ECDSA.
</div>
<div>
Questionable extension field!
</div>
<div>
brainpoolP160r1: RFC 5639 curve over a 160 bit prime field
</div>
<div>
brainpoolP160t1: RFC 5639 curve over a 160 bit prime field
</div>
<div>
brainpoolP192r1: RFC 5639 curve over a 192 bit prime field
</div>
<div>
brainpoolP192t1: RFC 5639 curve over a 192 bit prime field
</div>
<div>
brainpoolP224r1: RFC 5639 curve over a 224 bit prime field
</div>
<div>
brainpoolP224t1: RFC 5639 curve over a 224 bit prime field
</div>
<div>
brainpoolP256r1: RFC 5639 curve over a 256 bit prime field
</div>
<div>
brainpoolP256t1: RFC 5639 curve over a 256 bit prime field
</div>
<div>
brainpoolP320r1: RFC 5639 curve over a 320 bit prime field
</div>
<div>
brainpoolP320t1: RFC 5639 curve over a 320 bit prime field
</div>
<div>
brainpoolP384r1: RFC 5639 curve over a 384 bit prime field
</div>
<div>
brainpoolP384t1: RFC 5639 curve over a 384 bit prime field
</div>
<div>
brainpoolP512r1: RFC 5639 curve over a 512 bit prime field
</div>
<div>
brainpoolP512t1: RFC 5639 curve over a 512 bit prime field
</div>
</blockquote>
<div>
<br>
</div>
<div>
try
</div>
<div>
<br>
</div>
<div>
openssl s_server -cert /path/to/cert -key /path/to/key -port 5555
</div>
<div>
<br>
</div>
<div>
openssl s_client -connect localhost:5555
</div>
<div>
<br>
</div>
<div>
Aki
</div>
<div class="io-ox-signature">
---
<br>Aki Tuomi
</div>
</body>
</html>
>> >>> I did some local testing and it seems that you are using a curve >>> that is not acceptable for openssl as a server key. >>> I tested with openssl s_server -cert ec-cert.pem -key ec-key.pem >>> -port 5555 >>> using cert generated with brainpool. Everything works if I use >>> prime256v1 or secp521r1. This is a limitation in OpenSSL and not >>> something we can really do anything about. >>> Aki Tuomi >>> Open-Xchange Oy >> Which openssl version you are using? This end it is OpenSSL 1.1.0h. >> There are no issues creating private keys, issuing csr, signing certs >> with that particular curve. Printing certs and verifying certs against >> keys is panning out too, comparing md5 hashes also no errors. So why >> would openssl not accept (limit) keys is has generated and verified with >> no error? >> >> > try > > openssl s_server -cert /path/to/cert -key /path/to/key -port 5555 > > openssl s_client -connect localhost:5555 >Uhum, I see now. What a strange thing (bug?) openssl is doing. Thank you for valuable time/effort having debug this. Seems I have to start the CA all over...
>>>> I did some local testing and it seems that you are using a curve >>>> that is not acceptable for openssl as a server key. >>>> I tested with openssl s_server -cert ec-cert.pem -key ec-key.pem >>>> -port 5555 >>>> using cert generated with brainpool. Everything works if I use >>>> prime256v1 or secp521r1. This is a limitation in OpenSSL and not >>>> something we can really do anything about. >>>> Aki Tuomi >>>> Open-Xchange Oy >>> Which openssl version you are using? This end it is OpenSSL 1.1.0h. >>> There are no issues creating private keys, issuing csr, signing certs >>> with that particular curve. Printing certs and verifying certs against >>> keys is panning out too, comparing md5 hashes also no errors. So why >>> would openssl not accept (limit) keys is has generated and verified with >>> no error? >>> >>> >> try >> >> openssl s_server -cert /path/to/cert -key /path/to/key -port 5555 >> >> openssl s_client -connect localhost:5555 >> > Uhum, I see now. What a strange thing (bug?) openssl is doing. Thank you > for valuable time/effort having debug this. Seems I have to start the CA > all over...Perhaps for whose interested - IETF RFC 7027 specifies for TLS use: [ brainpoolP256r1 | brainpoolP384r1 | brainpoolP512r1 ] And thus t1 would not work anyway. However, having tested r1 the result was just the same. A tcpdump during the openssl test [ s_server | s_client ] then revealed (TLSv1.2 Record Layer: Handshake Protocol: Client Hello) : Extension: supported_groups (len=10) ??? Type: supported_groups (10) ??? Length: 10 ??? Supported Groups List Length: 8 ??? Supported Groups (4 groups) ??????? Supported Group: x25519 (0x001d) ??????? Supported Group: secp256r1 (0x0017) ??????? Supported Group: secp521r1 (0x0019) ??????? Supported Group: secp384r1 (0x0018) Apparently [ brainpool ] would apparently not fit into any of those groups. Perhaps a bug in OpenSSL 1.1.0h thus.