Hi,
facing [ no shared cipher ] error with EC private keys. This happens when the private key is generated with [ openssl ecparam -name brainpoolP512t1 -genkey ] with OpenSSL 1.1.0hh on the same machine Dovecot is running on.
Tried some variations of [ ssl_cipher_list ] but to no avail - the [ no shared cipher ] error persists.
Once the key is generated with [ openssl genpkey -algorithm RSA ] however the error is gone.
Thus wondering whether (1) I am missing something or (2) this a bug or (3) there is no support for EC keys?
facing [ no shared cipher ] error with EC private keys. the client connecting to your instance has to support ecdsa
It does - Thunderbird 60.0b10 (64-bit)
[ security.ssl3.ecdhe_ecdsa_aes_256_gcm_sha384;true ]
It seems there is a difference between the private key (rsa vs. ecc -> SSL_CTX?) used for the certificate signing request and the signed certificate.
The csr created from a private key with [ openssl genpkey -algorithm RSA ] and signed by a CA with [ ecdhe_ecdsa ] works with no error.
But as stated in the initial message it does not work if the private key for the csr is generated with [ openssl ecparam -name brainpoolP512t1 -genkey ].
On 29.07.2018 23:39, ѽ҉ᶬḳ℠ wrote:
facing [ no shared cipher ] error with EC private keys. the client connecting to your instance has to support ecdsa
It does - Thunderbird 60.0b10 (64-bit)
[ security.ssl3.ecdhe_ecdsa_aes_256_gcm_sha384;true ]
It seems there is a difference between the private key (rsa vs. ecc -> SSL_CTX?) used for the certificate signing request and the signed certificate.
The csr created from a private key with [ openssl genpkey -algorithm RSA ] and signed by a CA with [ ecdhe_ecdsa ] works with no error.
But as stated in the initial message it does not work if the private key for the csr is generated with [ openssl ecparam -name brainpoolP512t1 -genkey ].
Hi!
Can you show doveconf ssl_cipher_list?
Aki
facing [ no shared cipher ] error with EC private keys. the client connecting to your instance has to support ecdsa
It does - Thunderbird 60.0b10 (64-bit)
[ security.ssl3.ecdhe_ecdsa_aes_256_gcm_sha384;true ]
It seems there is a difference between the private key (rsa vs. ecc -> SSL_CTX?) used for the certificate signing request and the signed certificate.
The csr created from a private key with [ openssl genpkey -algorithm RSA ] and signed by a CA with [ ecdhe_ecdsa ] works with no error.
But as stated in the initial message it does not work if the private key for the csr is generated with [ openssl ecparam -name brainpoolP512t1 -genkey ].
Can you show doveconf ssl_cipher_list?
Tried several variations, e.g. ALL, ALL:HIGH:MEDIUM:LOW and right now set to ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384 which is working fine when the csr was created from a private key with RSA algorithm but not if csr key is generated with an EC key.
On 29 July 2018 at 23:39 ѽ҉ᶬḳ℠ <vtol@gmx.net> wrote:
facing [ no shared cipher ] error with EC private keys. the client connecting to your instance has to support ecdsa
It does - Thunderbird 60.0b10 (64-bit)
[ security.ssl3.ecdhe_ecdsa_aes_256_gcm_sha384;true ]
It seems there is a difference between the private key (rsa vs. ecc -> SSL_CTX?) used for the certificate signing request and the signed certificate.
The csr created from a private key with [ openssl genpkey -algorithm RSA ] and signed by a CA with [ ecdhe_ecdsa ] works with no error.
But as stated in the initial message it does not work if the private key for the csr is generated with [ openssl ecparam -name brainpoolP512t1 -genkey ].
Can you try, with your ECC cert,
openssl s_client -connect server:143 -starttls imap
and paste result?
Aki
facing [ no shared cipher ] error with EC private keys. the client connecting to your instance has to support ecdsa
It does - Thunderbird 60.0b10 (64-bit)
[ security.ssl3.ecdhe_ecdsa_aes_256_gcm_sha384;true ]
It seems there is a difference between the private key (rsa vs. ecc -> SSL_CTX?) used for the certificate signing request and the signed certificate.
The csr created from a private key with [ openssl genpkey -algorithm RSA ] and signed by a CA with [ ecdhe_ecdsa ] works with no error.
But as stated in the initial message it does not work if the private key for the csr is generated with [ openssl ecparam -name brainpoolP512t1 -genkey ].
Can you try, with your ECC cert,
openssl s_client -connect server:143 -starttls imap
and paste result?
This is for the certificate where the csr is generated with an EC private key and the [ no shared cipher ] error:
CONNECTED(00000003) write:errno=0
no peer certificate available
No client certificate CA names sent
SSL handshake has read 309 bytes and written 202 bytes Verification: OK
New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1532969474 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no
and this for the certificate where the csr is generated with a RSA private key:
CONNECTED(00000003) depth=0 C = 00, ST = CH, L = DC, O = foo.bar, OU = mail, CN = Server foo.bar Mail IMAP verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 C = 00, ST = CH, L = DC, O = foo.bar, OU = mail, CN = Server foo.bar Mail IMAP verify error:num=21:unable to verify the first certificate verify return:1
Certificate chain 0 s:/C=00/ST=CH/L=DC/O=foo.bar/OU=mail/CN=Server foo.bar Mail IMAP i:/C=00/ST=CH/O=foo.bar/OU=Server/CN=IM Server foo.bar
Server certificate -----BEGIN CERTIFICATE----- [ truncated ] -----END CERTIFICATE----- subject=/C=00/ST=CH/L=DC/O=foo.bar/OU=mail/CN=Server foo.bar Mail IMAP issuer=/C=00/ST=CH/O=foo.bar/OU=Server/CN=IM Server foo.bar
No client certificate CA names sent Peer signing digest: SHA512 Server Temp Key: X25519, 253 bits
SSL handshake has read 2361 bytes and written 295 bytes Verification error: unable to verify the first certificate
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 4096 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: C23E6478F4C6372F2A524504031B32EDC9FDCAA343AE5017A09E47C5E7B60DD6 Session-ID-ctx: Master-Key: [ obfuscated ] PSK identity: None PSK identity hint: None SRP username: None Start Time: 1532969755 Timeout : 7200 (sec) Verify return code: 21 (unable to verify the first certificate) Extended master secret: yes
. OK Pre-login capabilities listed, post-login capabilities have more.
On 30 July 2018 at 20:01 ѽ҉ᶬḳ℠ <vtol@gmx.net> wrote:
facing [ no shared cipher ] error with EC private keys. the client connecting to your instance has to support ecdsa
It does - Thunderbird 60.0b10 (64-bit)
[ security.ssl3.ecdhe_ecdsa_aes_256_gcm_sha384;true ]
It seems there is a difference between the private key (rsa vs. ecc -> SSL_CTX?) used for the certificate signing request and the signed certificate.
The csr created from a private key with [ openssl genpkey -algorithm RSA ] and signed by a CA with [ ecdhe_ecdsa ] works with no error.
But as stated in the initial message it does not work if the private key for the csr is generated with [ openssl ecparam -name brainpoolP512t1 -genkey ].
Can you try, with your ECC cert,
openssl s_client -connect server:143 -starttls imap
and paste result?
This is for the certificate where the csr is generated with an EC private key and the [ no shared cipher ] error:
CONNECTED(00000003) write:errno=0
no peer certificate available
No client certificate CA names sent
SSL handshake has read 309 bytes and written 202 bytes Verification: OK
New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1532969474 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no
and this for the certificate where the csr is generated with a RSA private key:
CONNECTED(00000003) depth=0 C = 00, ST = CH, L = DC, O = foo.bar, OU = mail, CN = Server foo.bar Mail IMAP verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 C = 00, ST = CH, L = DC, O = foo.bar, OU = mail, CN = Server foo.bar Mail IMAP verify error:num=21:unable to verify the first certificate verify return:1
Certificate chain 0 s:/C=00/ST=CH/L=DC/O=foo.bar/OU=mail/CN=Server foo.bar Mail IMAP i:/C=00/ST=CH/O=foo.bar/OU=Server/CN=IM Server foo.bar
Server certificate -----BEGIN CERTIFICATE----- [ truncated ] -----END CERTIFICATE----- subject=/C=00/ST=CH/L=DC/O=foo.bar/OU=mail/CN=Server foo.bar Mail IMAP issuer=/C=00/ST=CH/O=foo.bar/OU=Server/CN=IM Server foo.bar
No client certificate CA names sent Peer signing digest: SHA512 Server Temp Key: X25519, 253 bits
SSL handshake has read 2361 bytes and written 295 bytes Verification error: unable to verify the first certificate
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 4096 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: C23E6478F4C6372F2A524504031B32EDC9FDCAA343AE5017A09E47C5E7B60DD6 Session-ID-ctx: Master-Key: [ obfuscated ] PSK identity: None PSK identity hint: None SRP username: None Start Time: 1532969755 Timeout : 7200 (sec) Verify return code: 21 (unable to verify the first certificate) Extended master secret: yes
. OK Pre-login capabilities listed, post-login capabilities have more.
Can you configure ssl_cipher_list = ALL and try again? Also, can you send the *PUBLIC* part of the certificate?
Aki
facing [ no shared cipher ] error with EC private keys. the client connecting to your instance has to support ecdsa
It does - Thunderbird 60.0b10 (64-bit)
[ security.ssl3.ecdhe_ecdsa_aes_256_gcm_sha384;true ]
It seems there is a difference between the private key (rsa vs. ecc -> SSL_CTX?) used for the certificate signing request and the signed certificate.
The csr created from a private key with [ openssl genpkey -algorithm RSA ] and signed by a CA with [ ecdhe_ecdsa ] works with no error.
But as stated in the initial message it does not work if the private key for the csr is generated with [ openssl ecparam -name brainpoolP512t1 -genkey ].
Can you try, with your ECC cert,
openssl s_client -connect server:143 -starttls imap
and paste result?
This is for the certificate where the csr is generated with an EC private key and the [ no shared cipher ] error:
CONNECTED(00000003) write:errno=0
no peer certificate available
No client certificate CA names sent
SSL handshake has read 309 bytes and written 202 bytes Verification: OK
New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1532969474 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no
and this for the certificate where the csr is generated with a RSA private key:
CONNECTED(00000003) depth=0 C = 00, ST = CH, L = DC, O = foo.bar, OU = mail, CN = Server foo.bar Mail IMAP verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 C = 00, ST = CH, L = DC, O = foo.bar, OU = mail, CN = Server foo.bar Mail IMAP verify error:num=21:unable to verify the first certificate verify return:1
Certificate chain 0 s:/C=00/ST=CH/L=DC/O=foo.bar/OU=mail/CN=Server foo.bar Mail IMAP i:/C=00/ST=CH/O=foo.bar/OU=Server/CN=IM Server foo.bar
Server certificate -----BEGIN CERTIFICATE----- [ truncated ] -----END CERTIFICATE----- subject=/C=00/ST=CH/L=DC/O=foo.bar/OU=mail/CN=Server foo.bar Mail IMAP issuer=/C=00/ST=CH/O=foo.bar/OU=Server/CN=IM Server foo.bar
No client certificate CA names sent Peer signing digest: SHA512 Server Temp Key: X25519, 253 bits
SSL handshake has read 2361 bytes and written 295 bytes Verification error: unable to verify the first certificate
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 4096 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: C23E6478F4C6372F2A524504031B32EDC9FDCAA343AE5017A09E47C5E7B60DD6 Session-ID-ctx: Master-Key: [ obfuscated ] PSK identity: None PSK identity hint: None SRP username: None Start Time: 1532969755 Timeout : 7200 (sec) Verify return code: 21 (unable to verify the first certificate) Extended master secret: yes
. OK Pre-login capabilities listed, post-login capabilities have more.
Can you configure ssl_cipher_list = ALL and try again? Also, can you send the *PUBLIC* part of the certificate?
[ ssl_cipher_list = ALL ] set/applied
This is for the certificate where the csr is generated with an EC private key and the [ no shared cipher ] error:
CONNECTED(00000003) write:errno=0
no peer certificate available
No client certificate CA names sent
SSL handshake has read 309 bytes and written 202 bytes Verification: OK
New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1532970888 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no
and this for the certificate where the csr is generated with a RSA private key:
CONNECTED(00000003) depth=0 C = 00, ST = CH, L = DC, O = foo.bar, OU = mail, CN = Server foo.bar Mail IMAP verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 C = 00, ST = CH, L = DC, O = foo.bar, OU = mail, CN = Server foo.bar Mail IMAP verify error:num=21:unable to verify the first certificate verify return:1
Certificate chain 0 s:/C=00/ST=CH/L=DC/O=foo.bar/OU=mail/CN=Server foo.bar Mail IMAP i:/C=00/ST=CH/O=foo.bar/OU=Server/CN=IM Server foo.bar
Server certificate -----BEGIN CERTIFICATE----- MIIFIjCCBIagAwIBAgICEAYwCgYIKoZIzj0EAwQwWTELMAkGA1UEBhMCMDAxCzAJ BgNVBAgMAkNIMRAwDgYDVQQKDAd2dG9sLm1lMQ8wDQYDVQQLDAZTZXJ2ZXIxGjAY BgNVBAMMEUlNIFNlcnZlciB2dG9sLm1lMB4XDTE4MDczMDExMTE1NloXDTE5MDcz MDExMTE1NlowazELMAkGA1UEBhMCMDAxCzAJBgNVBAgMAkNIMQswCQYDVQQHDAJE QzEQMA4GA1UECgwHdnRvbC5tZTENMAsGA1UECwwEbWFpbDEhMB8GA1UEAwwYU2Vy dmVyIHZ0b2wubWUgTWFpbCBJTUFQMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIIC CgKCAgEAx3Rr6Goz0xHmRGwTC5XWvTYLLXli9nhaSqpfSXSBNembIpAJMQxeZKS5 T1VI1Kufp5HIpBFAXKo/yAMNS4E+LtctX2ITsZD1sUJw20J7TJtDR6mX7qiNJTlT FXHx5VZWLp2Jv3Wlw85iNUoRcIY2IB3Q9KACTPlMl8Be9BPYAevgyqh5d67LFgwf 77Soq4ppa0sLxTUf1Lyh9lvpIRdDnDhs749PlLrgWIagra2ONdesOlwMOANjn5+8 sKnooVlwsygDEIu2QWYeAJO43GWFMiMtb4sAii52fwbwzLNOA/jF1EDz2zbimBMc Tcy430CucN7wYQQa8KVU/EdaYXsDRFLPfyvkFw/1GKOm4MzCBNUp3soqMgFCNWix HwGw82hzMadXqKHwosSoDa291hpboxppYwqohG4rlbLNXZKINTrIYgh4EldI3HGy YhikuVVODa254DLoj/iS2A7ZWpvDGGqirEMEZEJi9pdO3E5CUctiZFe0zrKk6xX7 VfQq+wZzN2F6LFVyLEIR238FOKfUdoHP5i4d+2HIzUC1ZTYXLMrmC8aLPnvQLKmO lS8+EPrFz4LTTvw6Tt5oO0TH51FruLRRfp545yuT/7MOt4pf9jXjvuTrQDVTp+z2 6+nZZ5rxv1mAB/d0DvCg3sS3QxnzytmzlE0WVODb9zl0HNVz2GkCAwEAAaOCAV8w ggFbMAkGA1UdEwQCMAAwHQYDVR0OBBYEFD+YAO8k3NK95IXhPgriJNfICQDuMIGR BgNVHSMEgYkwgYaAFLcvDVPejjtNaMC39YNvdzbHnbWZoWqkaDBmMQswCQYDVQQG EwIwMDELMAkGA1UECAwCQ0gxCzAJBgNVBAcMAkRDMRAwDgYDVQQKDAd2dG9sLm1l MQ8wDQYDVQQLDAZTZXJ2ZXIxGjAYBgNVBAMMEUNBIFNlcnZlciB2dG9sLm1lggIQ ADAOBgNVHQ8BAf8EBAMCBaAwEwYDVR0lBAwwCgYIKwYBBQUHAwEwEQYIKwYBBQUH ARgEBTADAgERMEYGA1UdHwQ/MD0wO6A5oDeGNWZpbGU6L2V0Yy9wa2kvdnRvbC5t ZS9zZXJ2ZXIvaW0vY3JsL2ltX3NlcnZlci5jcmwucGVtMBsGA1UdEQQUMBKHBKwY bQaCBG1haWyCBGltYXAwCgYIKoZIzj0EAwQDgYkAMIGFAkEAml53KubdaDmaiUXz ir5NvZmQ8/0B9UbcSKbJq30HJYhx4gotbSYU8LuEYBzAthzHwnQ0FyHV5rZPo4Gp RBEFkgJAfYk9C3w0urb6KE+e+bFXHketkG+P5aQyUw2kWKI7GikRX2mS5ZbSGNfe 7Q79jSPczn3gguffxmoSW/idw5BpCw== -----END CERTIFICATE----- subject=/C=00/ST=CH/L=DC/O=foo.bar/OU=mail/CN=Server foo.bar Mail IMAP issuer=/C=00/ST=CH/O=foo.bar/OU=Server/CN=IM Server foo.bar
No client certificate CA names sent Peer signing digest: SHA512 Server Temp Key: X25519, 253 bits
SSL handshake has read 2361 bytes and written 295 bytes Verification error: unable to verify the first certificate
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 4096 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: 9636556EDC5BA951A6EE3BCAB17BCFAEEE8B380C097EC0C7F20D68BAF2775782 Session-ID-ctx: Master-Key: [ obfuscated ] PSK identity: None PSK identity hint: None SRP username: None Start Time: 1532971172 Timeout : 7200 (sec) Verify return code: 21 (unable to verify the first certificate) Extended master secret: yes
. OK Pre-login capabilities listed, post-login capabilities have more.
> facing [ no shared cipher ] error with EC private keys. the client connecting to your instance has to support ecdsa
It does - Thunderbird 60.0b10 (64-bit)
[ security.ssl3.ecdhe_ecdsa_aes_256_gcm_sha384;true ]
It seems there is a difference between the private key (rsa vs. ecc -> SSL_CTX?) used for the certificate signing request and the signed certificate.
The csr created from a private key with [ openssl genpkey -algorithm RSA ] and signed by a CA with [ ecdhe_ecdsa ] works with no error.
But as stated in the initial message it does not work if the private key for the csr is generated with [ openssl ecparam -name brainpoolP512t1 -genkey ].
Can you try, with your ECC cert,
openssl s_client -connect server:143 -starttls imap
and paste result?
This is for the certificate where the csr is generated with an EC private key and the [ no shared cipher ] error:
CONNECTED(00000003) write:errno=0
no peer certificate available
No client certificate CA names sent
SSL handshake has read 309 bytes and written 202 bytes Verification: OK
New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1532969474 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no
and this for the certificate where the csr is generated with a RSA private key:
CONNECTED(00000003) depth=0 C = 00, ST = CH, L = DC, O = foo.bar, OU = mail, CN = Server foo.bar Mail IMAP verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 C = 00, ST = CH, L = DC, O = foo.bar, OU = mail, CN = Server foo.bar Mail IMAP verify error:num=21:unable to verify the first certificate verify return:1
Certificate chain 0 s:/C=00/ST=CH/L=DC/O=foo.bar/OU=mail/CN=Server foo.bar Mail IMAP i:/C=00/ST=CH/O=foo.bar/OU=Server/CN=IM Server foo.bar
Server certificate -----BEGIN CERTIFICATE----- [ truncated ] -----END CERTIFICATE----- subject=/C=00/ST=CH/L=DC/O=foo.bar/OU=mail/CN=Server foo.bar Mail IMAP issuer=/C=00/ST=CH/O=foo.bar/OU=Server/CN=IM Server foo.bar
No client certificate CA names sent Peer signing digest: SHA512 Server Temp Key: X25519, 253 bits
SSL handshake has read 2361 bytes and written 295 bytes Verification error: unable to verify the first certificate
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 4096 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: C23E6478F4C6372F2A524504031B32EDC9FDCAA343AE5017A09E47C5E7B60DD6 Session-ID-ctx: Master-Key: [ obfuscated ] PSK identity: None PSK identity hint: None SRP username: None Start Time: 1532969755 Timeout : 7200 (sec) Verify return code: 21 (unable to verify the first certificate) Extended master secret: yes
. OK Pre-login capabilities listed, post-login capabilities have more.
Can you configure ssl_cipher_list = ALL and try again? Also, can you send the *PUBLIC* part of the certificate?
[ ssl_cipher_list = ALL ] set/applied
This is for the certificate where the csr is generated with an EC private key and the [ no shared cipher ] error:
CONNECTED(00000003) write:errno=0
no peer certificate available
No client certificate CA names sent
SSL handshake has read 309 bytes and written 202 bytes Verification: OK
New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1532970888 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no
and this for the certificate where the csr is generated with a RSA private key:
CONNECTED(00000003) depth=0 C = 00, ST = CH, L = DC, O = foo.bar, OU = mail, CN = Server foo.bar Mail IMAP verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 C = 00, ST = CH, L = DC, O = foo.bar, OU = mail, CN = Server foo.bar Mail IMAP verify error:num=21:unable to verify the first certificate verify return:1
Certificate chain 0 s:/C=00/ST=CH/L=DC/O=foo.bar/OU=mail/CN=Server foo.bar Mail IMAP i:/C=00/ST=CH/O=foo.bar/OU=Server/CN=IM Server foo.bar
Server certificate -----BEGIN CERTIFICATE----- MIIFIjCCBIagAwIBAgICEAYwCgYIKoZIzj0EAwQwWTELMAkGA1UEBhMCMDAxCzAJ BgNVBAgMAkNIMRAwDgYDVQQKDAd2dG9sLm1lMQ8wDQYDVQQLDAZTZXJ2ZXIxGjAY BgNVBAMMEUlNIFNlcnZlciB2dG9sLm1lMB4XDTE4MDczMDExMTE1NloXDTE5MDcz MDExMTE1NlowazELMAkGA1UEBhMCMDAxCzAJBgNVBAgMAkNIMQswCQYDVQQHDAJE QzEQMA4GA1UECgwHdnRvbC5tZTENMAsGA1UECwwEbWFpbDEhMB8GA1UEAwwYU2Vy dmVyIHZ0b2wubWUgTWFpbCBJTUFQMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIIC CgKCAgEAx3Rr6Goz0xHmRGwTC5XWvTYLLXli9nhaSqpfSXSBNembIpAJMQxeZKS5 T1VI1Kufp5HIpBFAXKo/yAMNS4E+LtctX2ITsZD1sUJw20J7TJtDR6mX7qiNJTlT FXHx5VZWLp2Jv3Wlw85iNUoRcIY2IB3Q9KACTPlMl8Be9BPYAevgyqh5d67LFgwf 77Soq4ppa0sLxTUf1Lyh9lvpIRdDnDhs749PlLrgWIagra2ONdesOlwMOANjn5+8 sKnooVlwsygDEIu2QWYeAJO43GWFMiMtb4sAii52fwbwzLNOA/jF1EDz2zbimBMc Tcy430CucN7wYQQa8KVU/EdaYXsDRFLPfyvkFw/1GKOm4MzCBNUp3soqMgFCNWix HwGw82hzMadXqKHwosSoDa291hpboxppYwqohG4rlbLNXZKINTrIYgh4EldI3HGy YhikuVVODa254DLoj/iS2A7ZWpvDGGqirEMEZEJi9pdO3E5CUctiZFe0zrKk6xX7 VfQq+wZzN2F6LFVyLEIR238FOKfUdoHP5i4d+2HIzUC1ZTYXLMrmC8aLPnvQLKmO lS8+EPrFz4LTTvw6Tt5oO0TH51FruLRRfp545yuT/7MOt4pf9jXjvuTrQDVTp+z2 6+nZZ5rxv1mAB/d0DvCg3sS3QxnzytmzlE0WVODb9zl0HNVz2GkCAwEAAaOCAV8w ggFbMAkGA1UdEwQCMAAwHQYDVR0OBBYEFD+YAO8k3NK95IXhPgriJNfICQDuMIGR BgNVHSMEgYkwgYaAFLcvDVPejjtNaMC39YNvdzbHnbWZoWqkaDBmMQswCQYDVQQG EwIwMDELMAkGA1UECAwCQ0gxCzAJBgNVBAcMAkRDMRAwDgYDVQQKDAd2dG9sLm1l MQ8wDQYDVQQLDAZTZXJ2ZXIxGjAYBgNVBAMMEUNBIFNlcnZlciB2dG9sLm1lggIQ ADAOBgNVHQ8BAf8EBAMCBaAwEwYDVR0lBAwwCgYIKwYBBQUHAwEwEQYIKwYBBQUH ARgEBTADAgERMEYGA1UdHwQ/MD0wO6A5oDeGNWZpbGU6L2V0Yy9wa2kvdnRvbC5t ZS9zZXJ2ZXIvaW0vY3JsL2ltX3NlcnZlci5jcmwucGVtMBsGA1UdEQQUMBKHBKwY bQaCBG1haWyCBGltYXAwCgYIKoZIzj0EAwQDgYkAMIGFAkEAml53KubdaDmaiUXz ir5NvZmQ8/0B9UbcSKbJq30HJYhx4gotbSYU8LuEYBzAthzHwnQ0FyHV5rZPo4Gp RBEFkgJAfYk9C3w0urb6KE+e+bFXHketkG+P5aQyUw2kWKI7GikRX2mS5ZbSGNfe 7Q79jSPczn3gguffxmoSW/idw5BpCw== -----END CERTIFICATE----- subject=/C=00/ST=CH/L=DC/O=foo.bar/OU=mail/CN=Server foo.bar Mail IMAP issuer=/C=00/ST=CH/O=foo.bar/OU=Server/CN=IM Server foo.bar
No client certificate CA names sent Peer signing digest: SHA512 Server Temp Key: X25519, 253 bits
SSL handshake has read 2361 bytes and written 295 bytes Verification error: unable to verify the first certificate
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 4096 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: 9636556EDC5BA951A6EE3BCAB17BCFAEEE8B380C097EC0C7F20D68BAF2775782 Session-ID-ctx: Master-Key: [ obfuscated ] PSK identity: None PSK identity hint: None SRP username: None Start Time: 1532971172 Timeout : 7200 (sec) Verify return code: 21 (unable to verify the first certificate) Extended master secret: yes
. OK Pre-login capabilities listed, post-login capabilities have more.
Missed the public certificate where the csr is generated with an EC private key and the [ no shared cipher ] error:
-----BEGIN CERTIFICATE----- MIIDmTCCAv6gAwIBAgICEAEwCgYIKoZIzj0EAwQwWTELMAkGA1UEBhMCMDAxCzAJ BgNVBAgMAkNIMRAwDgYDVQQKDAd2dG9sLm1lMQ8wDQYDVQQLDAZTZXJ2ZXIxGjAY BgNVBAMMEUlNIFNlcnZlciB2dG9sLm1lMB4XDTE4MDcyNTE0NDAxMloXDTE5MDcy NTE0NDAxMlowazELMAkGA1UEBhMCMDAxCzAJBgNVBAgMAkNIMQswCQYDVQQHDAJE QzEQMA4GA1UECgwHdnRvbC5tZTENMAsGA1UECwwEbWFpbDEhMB8GA1UEAwwYU2Vy dmVyIE1haWwgSW1hcCB2dG9sLm1lMIGbMBQGByqGSM49AgEGCSskAwMCCAEBDgOB ggAEdZAqTZhgEaAspsZWe8ss8LC2vxMP9ClHwtjKwVuTAnhJFDX5wWkaukjVw1HW ngwQAI2n9KwyRC3311yWKOQjrkhPw50sbK1UOuypof0fucYzo+B1+YRaae9a2vJx DjljXrvEcXskXdjUFdMIxUAtnHbHuyql8bMJ715ypXADUdGjggFfMIIBWzAJBgNV HRMEAjAAMB0GA1UdDgQWBBROPXTACC4fuaOX5iSNONpuyVAB5jCBkQYDVR0jBIGJ MIGGgBS3Lw1T3o47TWjAt/WDb3c2x521maFqpGgwZjELMAkGA1UEBhMCMDAxCzAJ BgNVBAgMAkNIMQswCQYDVQQHDAJEQzEQMA4GA1UECgwHdnRvbC5tZTEPMA0GA1UE CwwGU2VydmVyMRowGAYDVQQDDBFDQSBTZXJ2ZXIgdnRvbC5tZYICEAAwDgYDVR0P AQH/BAQDAgWgMBMGA1UdJQQMMAoGCCsGAQUFBwMBMBEGCCsGAQUFBwEYBAUwAwIB ETBGBgNVHR8EPzA9MDugOaA3hjVmaWxlOi9ldGMvcGtpL3Z0b2wubWUvc2VydmVy L2ltL2NybC9pbV9zZXJ2ZXIuY3JsLnBlbTAbBgNVHREEFDAShwSsGG0GggRtYWls ggRpbWFwMAoGCCqGSM49BAMEA4GIADCBhAJAdRE8iPNsGMCuwYQjykDeDVngTmO8 YT3tjFh3RrwNEDewPesByTHxhU6E+s98in9cq8rqAGSH8547Cq2KC/BOywJAGNHd SF0PuAzqghQ7JKXqufjxKEyMMEu4H9HlH/h4lwX9hUO5EVDlCNqkcHHu9TCXBCmR xT/8nuAtTycVigK88A== -----END CERTIFICATE-----
On 30 July 2018 at 20:37 ѽ҉ᶬḳ℠ <vtol@gmx.net> wrote:
>> facing [ no shared cipher ] error with EC private keys. > the client connecting to your instance has to support ecdsa > > It does - Thunderbird 60.0b10 (64-bit)
[ security.ssl3.ecdhe_ecdsa_aes_256_gcm_sha384;true ]
It seems there is a difference between the private key (rsa vs. ecc -> SSL_CTX?) used for the certificate signing request and the signed certificate.
The csr created from a private key with [ openssl genpkey -algorithm RSA ] and signed by a CA with [ ecdhe_ecdsa ] works with no error.
But as stated in the initial message it does not work if the private key for the csr is generated with [ openssl ecparam -name brainpoolP512t1 -genkey ].
Can you try, with your ECC cert,
openssl s_client -connect server:143 -starttls imap
and paste result?
This is for the certificate where the csr is generated with an EC private key and the [ no shared cipher ] error:
CONNECTED(00000003) write:errno=0
no peer certificate available
No client certificate CA names sent
SSL handshake has read 309 bytes and written 202 bytes Verification: OK
New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1532969474 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no
and this for the certificate where the csr is generated with a RSA private key:
CONNECTED(00000003) depth=0 C = 00, ST = CH, L = DC, O = foo.bar, OU = mail, CN = Server foo.bar Mail IMAP verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 C = 00, ST = CH, L = DC, O = foo.bar, OU = mail, CN = Server foo.bar Mail IMAP verify error:num=21:unable to verify the first certificate verify return:1
Certificate chain 0 s:/C=00/ST=CH/L=DC/O=foo.bar/OU=mail/CN=Server foo.bar Mail IMAP i:/C=00/ST=CH/O=foo.bar/OU=Server/CN=IM Server foo.bar
Server certificate -----BEGIN CERTIFICATE----- [ truncated ] -----END CERTIFICATE----- subject=/C=00/ST=CH/L=DC/O=foo.bar/OU=mail/CN=Server foo.bar Mail IMAP issuer=/C=00/ST=CH/O=foo.bar/OU=Server/CN=IM Server foo.bar
No client certificate CA names sent Peer signing digest: SHA512 Server Temp Key: X25519, 253 bits
SSL handshake has read 2361 bytes and written 295 bytes Verification error: unable to verify the first certificate
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 4096 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: C23E6478F4C6372F2A524504031B32EDC9FDCAA343AE5017A09E47C5E7B60DD6 Session-ID-ctx: Master-Key: [ obfuscated ] PSK identity: None PSK identity hint: None SRP username: None Start Time: 1532969755 Timeout : 7200 (sec) Verify return code: 21 (unable to verify the first certificate) Extended master secret: yes
. OK Pre-login capabilities listed, post-login capabilities have more.
Can you configure ssl_cipher_list = ALL and try again? Also, can you send the *PUBLIC* part of the certificate?
[ ssl_cipher_list = ALL ] set/applied
This is for the certificate where the csr is generated with an EC private key and the [ no shared cipher ] error:
CONNECTED(00000003) write:errno=0
no peer certificate available
No client certificate CA names sent
SSL handshake has read 309 bytes and written 202 bytes Verification: OK
New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1532970888 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no
and this for the certificate where the csr is generated with a RSA private key:
CONNECTED(00000003) depth=0 C = 00, ST = CH, L = DC, O = foo.bar, OU = mail, CN = Server foo.bar Mail IMAP verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 C = 00, ST = CH, L = DC, O = foo.bar, OU = mail, CN = Server foo.bar Mail IMAP verify error:num=21:unable to verify the first certificate verify return:1
Certificate chain 0 s:/C=00/ST=CH/L=DC/O=foo.bar/OU=mail/CN=Server foo.bar Mail IMAP i:/C=00/ST=CH/O=foo.bar/OU=Server/CN=IM Server foo.bar
Server certificate -----BEGIN CERTIFICATE----- MIIFIjCCBIagAwIBAgICEAYwCgYIKoZIzj0EAwQwWTELMAkGA1UEBhMCMDAxCzAJ BgNVBAgMAkNIMRAwDgYDVQQKDAd2dG9sLm1lMQ8wDQYDVQQLDAZTZXJ2ZXIxGjAY BgNVBAMMEUlNIFNlcnZlciB2dG9sLm1lMB4XDTE4MDczMDExMTE1NloXDTE5MDcz MDExMTE1NlowazELMAkGA1UEBhMCMDAxCzAJBgNVBAgMAkNIMQswCQYDVQQHDAJE QzEQMA4GA1UECgwHdnRvbC5tZTENMAsGA1UECwwEbWFpbDEhMB8GA1UEAwwYU2Vy dmVyIHZ0b2wubWUgTWFpbCBJTUFQMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIIC CgKCAgEAx3Rr6Goz0xHmRGwTC5XWvTYLLXli9nhaSqpfSXSBNembIpAJMQxeZKS5 T1VI1Kufp5HIpBFAXKo/yAMNS4E+LtctX2ITsZD1sUJw20J7TJtDR6mX7qiNJTlT FXHx5VZWLp2Jv3Wlw85iNUoRcIY2IB3Q9KACTPlMl8Be9BPYAevgyqh5d67LFgwf 77Soq4ppa0sLxTUf1Lyh9lvpIRdDnDhs749PlLrgWIagra2ONdesOlwMOANjn5+8 sKnooVlwsygDEIu2QWYeAJO43GWFMiMtb4sAii52fwbwzLNOA/jF1EDz2zbimBMc Tcy430CucN7wYQQa8KVU/EdaYXsDRFLPfyvkFw/1GKOm4MzCBNUp3soqMgFCNWix HwGw82hzMadXqKHwosSoDa291hpboxppYwqohG4rlbLNXZKINTrIYgh4EldI3HGy YhikuVVODa254DLoj/iS2A7ZWpvDGGqirEMEZEJi9pdO3E5CUctiZFe0zrKk6xX7 VfQq+wZzN2F6LFVyLEIR238FOKfUdoHP5i4d+2HIzUC1ZTYXLMrmC8aLPnvQLKmO lS8+EPrFz4LTTvw6Tt5oO0TH51FruLRRfp545yuT/7MOt4pf9jXjvuTrQDVTp+z2 6+nZZ5rxv1mAB/d0DvCg3sS3QxnzytmzlE0WVODb9zl0HNVz2GkCAwEAAaOCAV8w ggFbMAkGA1UdEwQCMAAwHQYDVR0OBBYEFD+YAO8k3NK95IXhPgriJNfICQDuMIGR BgNVHSMEgYkwgYaAFLcvDVPejjtNaMC39YNvdzbHnbWZoWqkaDBmMQswCQYDVQQG EwIwMDELMAkGA1UECAwCQ0gxCzAJBgNVBAcMAkRDMRAwDgYDVQQKDAd2dG9sLm1l MQ8wDQYDVQQLDAZTZXJ2ZXIxGjAYBgNVBAMMEUNBIFNlcnZlciB2dG9sLm1lggIQ ADAOBgNVHQ8BAf8EBAMCBaAwEwYDVR0lBAwwCgYIKwYBBQUHAwEwEQYIKwYBBQUH ARgEBTADAgERMEYGA1UdHwQ/MD0wO6A5oDeGNWZpbGU6L2V0Yy9wa2kvdnRvbC5t ZS9zZXJ2ZXIvaW0vY3JsL2ltX3NlcnZlci5jcmwucGVtMBsGA1UdEQQUMBKHBKwY bQaCBG1haWyCBGltYXAwCgYIKoZIzj0EAwQDgYkAMIGFAkEAml53KubdaDmaiUXz ir5NvZmQ8/0B9UbcSKbJq30HJYhx4gotbSYU8LuEYBzAthzHwnQ0FyHV5rZPo4Gp RBEFkgJAfYk9C3w0urb6KE+e+bFXHketkG+P5aQyUw2kWKI7GikRX2mS5ZbSGNfe 7Q79jSPczn3gguffxmoSW/idw5BpCw== -----END CERTIFICATE----- subject=/C=00/ST=CH/L=DC/O=foo.bar/OU=mail/CN=Server foo.bar Mail IMAP issuer=/C=00/ST=CH/O=foo.bar/OU=Server/CN=IM Server foo.bar
No client certificate CA names sent Peer signing digest: SHA512 Server Temp Key: X25519, 253 bits
SSL handshake has read 2361 bytes and written 295 bytes Verification error: unable to verify the first certificate
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 4096 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: 9636556EDC5BA951A6EE3BCAB17BCFAEEE8B380C097EC0C7F20D68BAF2775782 Session-ID-ctx: Master-Key: [ obfuscated ] PSK identity: None PSK identity hint: None SRP username: None Start Time: 1532971172 Timeout : 7200 (sec) Verify return code: 21 (unable to verify the first certificate) Extended master secret: yes
. OK Pre-login capabilities listed, post-login capabilities have more.
Missed the public certificate where the csr is generated with an EC private key and the [ no shared cipher ] error:
-----BEGIN CERTIFICATE----- MIIDmTCCAv6gAwIBAgICEAEwCgYIKoZIzj0EAwQwWTELMAkGA1UEBhMCMDAxCzAJ BgNVBAgMAkNIMRAwDgYDVQQKDAd2dG9sLm1lMQ8wDQYDVQQLDAZTZXJ2ZXIxGjAY BgNVBAMMEUlNIFNlcnZlciB2dG9sLm1lMB4XDTE4MDcyNTE0NDAxMloXDTE5MDcy NTE0NDAxMlowazELMAkGA1UEBhMCMDAxCzAJBgNVBAgMAkNIMQswCQYDVQQHDAJE QzEQMA4GA1UECgwHdnRvbC5tZTENMAsGA1UECwwEbWFpbDEhMB8GA1UEAwwYU2Vy dmVyIE1haWwgSW1hcCB2dG9sLm1lMIGbMBQGByqGSM49AgEGCSskAwMCCAEBDgOB ggAEdZAqTZhgEaAspsZWe8ss8LC2vxMP9ClHwtjKwVuTAnhJFDX5wWkaukjVw1HW ngwQAI2n9KwyRC3311yWKOQjrkhPw50sbK1UOuypof0fucYzo+B1+YRaae9a2vJx DjljXrvEcXskXdjUFdMIxUAtnHbHuyql8bMJ715ypXADUdGjggFfMIIBWzAJBgNV HRMEAjAAMB0GA1UdDgQWBBROPXTACC4fuaOX5iSNONpuyVAB5jCBkQYDVR0jBIGJ MIGGgBS3Lw1T3o47TWjAt/WDb3c2x521maFqpGgwZjELMAkGA1UEBhMCMDAxCzAJ BgNVBAgMAkNIMQswCQYDVQQHDAJEQzEQMA4GA1UECgwHdnRvbC5tZTEPMA0GA1UE CwwGU2VydmVyMRowGAYDVQQDDBFDQSBTZXJ2ZXIgdnRvbC5tZYICEAAwDgYDVR0P AQH/BAQDAgWgMBMGA1UdJQQMMAoGCCsGAQUFBwMBMBEGCCsGAQUFBwEYBAUwAwIB ETBGBgNVHR8EPzA9MDugOaA3hjVmaWxlOi9ldGMvcGtpL3Z0b2wubWUvc2VydmVy L2ltL2NybC9pbV9zZXJ2ZXIuY3JsLnBlbTAbBgNVHREEFDAShwSsGG0GggRtYWls ggRpbWFwMAoGCCqGSM49BAMEA4GIADCBhAJAdRE8iPNsGMCuwYQjykDeDVngTmO8 YT3tjFh3RrwNEDewPesByTHxhU6E+s98in9cq8rqAGSH8547Cq2KC/BOywJAGNHd SF0PuAzqghQ7JKXqufjxKEyMMEu4H9HlH/h4lwX9hUO5EVDlCNqkcHHu9TCXBCmR xT/8nuAtTycVigK88A== -----END CERTIFICATE-----
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
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?
[ openssl ecparam -list_curves ] secp112r1 : SECG/WTLS curve over a 112 bit prime field secp112r2 : SECG curve over a 112 bit prime field secp128r1 : SECG curve over a 128 bit prime field secp128r2 : SECG curve over a 128 bit prime field secp160k1 : SECG curve over a 160 bit prime field secp160r1 : SECG curve over a 160 bit prime field secp160r2 : SECG/WTLS curve over a 160 bit prime field secp192k1 : SECG curve over a 192 bit prime field secp224k1 : SECG curve over a 224 bit prime field secp224r1 : NIST/SECG curve over a 224 bit prime field secp256k1 : SECG curve over a 256 bit prime field secp384r1 : NIST/SECG curve over a 384 bit prime field secp521r1 : NIST/SECG curve over a 521 bit prime field prime192v1: NIST/X9.62/SECG curve over a 192 bit prime field prime192v2: X9.62 curve over a 192 bit prime field prime192v3: X9.62 curve over a 192 bit prime field prime239v1: X9.62 curve over a 239 bit prime field prime239v2: X9.62 curve over a 239 bit prime field prime239v3: X9.62 curve over a 239 bit prime field prime256v1: X9.62/SECG curve over a 256 bit prime field sect113r1 : SECG curve over a 113 bit binary field sect113r2 : SECG curve over a 113 bit binary field sect131r1 : SECG/WTLS curve over a 131 bit binary field sect131r2 : SECG curve over a 131 bit binary field sect163k1 : NIST/SECG/WTLS curve over a 163 bit binary field sect163r1 : SECG curve over a 163 bit binary field sect163r2 : NIST/SECG curve over a 163 bit binary field sect193r1 : SECG curve over a 193 bit binary field sect193r2 : SECG curve over a 193 bit binary field sect233k1 : NIST/SECG/WTLS curve over a 233 bit binary field sect233r1 : NIST/SECG/WTLS curve over a 233 bit binary field sect239k1 : SECG curve over a 239 bit binary field sect283k1 : NIST/SECG curve over a 283 bit binary field sect283r1 : NIST/SECG curve over a 283 bit binary field sect409k1 : NIST/SECG curve over a 409 bit binary field sect409r1 : NIST/SECG curve over a 409 bit binary field sect571k1 : NIST/SECG curve over a 571 bit binary field sect571r1 : NIST/SECG curve over a 571 bit binary field c2pnb163v1: X9.62 curve over a 163 bit binary field c2pnb163v2: X9.62 curve over a 163 bit binary field c2pnb163v3: X9.62 curve over a 163 bit binary field c2pnb176v1: X9.62 curve over a 176 bit binary field c2tnb191v1: X9.62 curve over a 191 bit binary field c2tnb191v2: X9.62 curve over a 191 bit binary field c2tnb191v3: X9.62 curve over a 191 bit binary field c2pnb208w1: X9.62 curve over a 208 bit binary field c2tnb239v1: X9.62 curve over a 239 bit binary field c2tnb239v2: X9.62 curve over a 239 bit binary field c2tnb239v3: X9.62 curve over a 239 bit binary field c2pnb272w1: X9.62 curve over a 272 bit binary field c2pnb304w1: X9.62 curve over a 304 bit binary field c2tnb359v1: X9.62 curve over a 359 bit binary field c2pnb368w1: X9.62 curve over a 368 bit binary field c2tnb431r1: X9.62 curve over a 431 bit binary field wap-wsg-idm-ecid-wtls1: WTLS curve over a 113 bit binary field wap-wsg-idm-ecid-wtls3: NIST/SECG/WTLS curve over a 163 bit binary field wap-wsg-idm-ecid-wtls4: SECG curve over a 113 bit binary field wap-wsg-idm-ecid-wtls5: X9.62 curve over a 163 bit binary field wap-wsg-idm-ecid-wtls6: SECG/WTLS curve over a 112 bit prime field wap-wsg-idm-ecid-wtls7: SECG/WTLS curve over a 160 bit prime field wap-wsg-idm-ecid-wtls8: WTLS curve over a 112 bit prime field wap-wsg-idm-ecid-wtls9: WTLS curve over a 160 bit prime field wap-wsg-idm-ecid-wtls10: NIST/SECG/WTLS curve over a 233 bit binary field wap-wsg-idm-ecid-wtls11: NIST/SECG/WTLS curve over a 233 bit binary field wap-wsg-idm-ecid-wtls12: WTLS curve over a 224 bit prime field Oakley-EC2N-3: IPSec/IKE/Oakley curve #3 over a 155 bit binary field. Not suitable for ECDSA. Questionable extension field! Oakley-EC2N-4: IPSec/IKE/Oakley curve #4 over a 185 bit binary field. Not suitable for ECDSA. Questionable extension field! brainpoolP160r1: RFC 5639 curve over a 160 bit prime field brainpoolP160t1: RFC 5639 curve over a 160 bit prime field brainpoolP192r1: RFC 5639 curve over a 192 bit prime field brainpoolP192t1: RFC 5639 curve over a 192 bit prime field brainpoolP224r1: RFC 5639 curve over a 224 bit prime field brainpoolP224t1: RFC 5639 curve over a 224 bit prime field brainpoolP256r1: RFC 5639 curve over a 256 bit prime field brainpoolP256t1: RFC 5639 curve over a 256 bit prime field brainpoolP320r1: RFC 5639 curve over a 320 bit prime field brainpoolP320t1: RFC 5639 curve over a 320 bit prime field brainpoolP384r1: RFC 5639 curve over a 384 bit prime field brainpoolP384t1: RFC 5639 curve over a 384 bit prime field brainpoolP512r1: RFC 5639 curve over a 512 bit prime field brainpoolP512t1: RFC 5639 curve over a 512 bit prime field
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?
Ran both certificate types with [ openssl s_server -cert ec.cert.pem -key ec.key.pem -port 5555 ] and [ openssl s_server -cert rsa.cert.pem -key rsa.key.pem -port 5555 ] and both with the output:
Using default temp DH parameters ACCEPT
Which would indicate this not being caused by openssl.
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.
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.
Turned out not being a bug in OpenSSL after all. From the cli it works with no issues this way:
[ openssl s_server -cert ec.cert.pem -key ec.key.pem -port 5555 -curves brainpoolP512r1 ] [ openssl s_client -connect localhost:5555 -curves brainpoolP512r1 ]
I am not familiar really with the OpenSSL API and only roughly gather that the app (dovecot) would have to make the API call [ SSL_CTX_set1_groups_list ] (https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set1_groups.html) in order to support those curves.
On 31.07.2018 03:32, ѽ҉ᶬḳ℠ wrote:
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.
Turned out not being a bug in OpenSSL after all. From the cli it works with no issues this way:
[ openssl s_server -cert ec.cert.pem -key ec.key.pem -port 5555 -curves brainpoolP512r1 ] [ openssl s_client -connect localhost:5555 -curves brainpoolP512r1 ]
I am not familiar really with the OpenSSL API and only roughly gather that the app (dovecot) would have to make the API call [ SSL_CTX_set1_groups_list ] (https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set1_groups.html) in order to support those curves.
Whoops.
We have a setting called ssl_curve_list in dovecot, and I tried using
that when I was testing. Turns out that there is a bug preventing that
setting from being used. If you are compiling yourself, you can use the
attached patch to fix this.
After applying, you can set
ssl_curve_list = brainpoolP512r1
And then you can connect again.
Aki
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.
Turned out not being a bug in OpenSSL after all. From the cli it works with no issues this way:
[ openssl s_server -cert ec.cert.pem -key ec.key.pem -port 5555 -curves brainpoolP512r1 ] [ openssl s_client -connect localhost:5555 -curves brainpoolP512r1 ]
I am not familiar really with the OpenSSL API and only roughly gather that the app (dovecot) would have to make the API call [ SSL_CTX_set1_groups_list ] (https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set1_groups.html) in order to support those curves.
Whoops.
We have a setting called
ssl_curve_listin dovecot, and I tried using that when I was testing. Turns out that there is a bug preventing that setting from being used. If you are compiling yourself, you can use the attached patch to fix this.After applying, you can set
ssl_curve_list = brainpoolP512r1
And then you can connect again.
Aki
Meantime I stumbled over that setting and was like 'yeah - what are you blubbering about when dovecot caters for it already'. That stopped when testing the setting ... like you said it is a bug apparently.
Now about compiling... that is not really my turf unless it is absolutely necessary. Time being I will (have to) work around with [ ssl_alt_key/cert ] and will notify the downstream repo maintainer about the patch, assuming that needs all that compiling I cannot just modify some file manually.
On 31.07.2018 09:30, ѽ҉ᶬḳ℠ wrote:
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.
Turned out not being a bug in OpenSSL after all. From the cli it works with no issues this way:
[ openssl s_server -cert ec.cert.pem -key ec.key.pem -port 5555 -curves brainpoolP512r1 ] [ openssl s_client -connect localhost:5555 -curves brainpoolP512r1 ]
I am not familiar really with the OpenSSL API and only roughly gather that the app (dovecot) would have to make the API call [ SSL_CTX_set1_groups_list ] (https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set1_groups.html) in order to support those curves.
Whoops.
We have a setting called
ssl_curve_listin dovecot, and I tried using that when I was testing. Turns out that there is a bug preventing that setting from being used. If you are compiling yourself, you can use the attached patch to fix this.After applying, you can set
ssl_curve_list = brainpoolP512r1
And then you can connect again.
Aki Meantime I stumbled over that setting and was like 'yeah - what are you blubbering about when dovecot caters for it already'. That stopped when testing the setting ... like you said it is a bug apparently.
Now about compiling... that is not really my turf unless it is absolutely necessary. Time being I will (have to) work around with [ ssl_alt_key/cert ] and will notify the downstream repo maintainer about the patch, assuming that needs all that compiling I cannot just modify some file manually.
Yeah, it needs to be recompiled to fix.
Aki
Yeah, it needs to be recompiled to fix.
Sure, no worries. Thanks for the quick turnaround on the patch. Downstream is notified and pending migration into their package. Meanwhile ssl_alt_key/certs does the trick. I am grateful that such option is even provisioned or else I would a be in rather bad spot with the CA. Other apps are rather ignorant on that matter.
On 31.07.2018 10:26, ѽ҉ᶬḳ℠ wrote:
Yeah, it needs to be recompiled to fix.
Sure, no worries. Thanks for the quick turnaround on the patch. Downstream is notified and pending migration into their package. Meanwhile ssl_alt_key/certs does the trick. I am grateful that such option is even provisioned or else I would a be in rather bad spot with the CA. Other apps are rather ignorant on that matter.
It's now merged, and can be found in https://github.com/dovecot/core/commit/71ceeaaed73af48eb2cdfd2e1d953ee645c2e...
Aki
participants (3)
-
A. Schulze
-
Aki Tuomi
-
ѽ҉ᶬḳ℠