Re: 2.3.2.1 - EC keys suppport?
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/71ceeaaed73af48eb2cdfd2e1d953ee645c2e9b2.patch Aki
Re: 2.3.2.1 - EC keys suppport?
> 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.
Re: 2.3.2.1 - EC keys suppport?
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 -curves >>> brainpoolP512r1 ] >>> [ openssl s_client -connect localhost: -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 > 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
Re: 2.3.2.1 - EC keys suppport?
> >>> 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 -curves >> brainpoolP512r1 ] >> [ openssl s_client -connect localhost: -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 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.
Re: 2.3.2.1 - EC keys suppport?
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 -curves > brainpoolP512r1 ] > [ openssl s_client -connect localhost: -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 >From 71ceeaaed73af48eb2cdfd2e1d953ee645c2e9b2 Mon Sep 17 00:00:00 2001 From: Aki Tuomi Date: Tue, 31 Jul 2018 08:45:29 +0300 Subject: [PATCH] lib-master: Copy ssl_curve_list setting Otherwise it won't get used. Broken in 30dca95419 --- src/lib-master/master-service-ssl-settings.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/lib-master/master-service-ssl-settings.c b/src/lib-master/master-service-ssl-settings.c index 2434e3632c..2bc59b0f4d 100644 --- a/src/lib-master/master-service-ssl-settings.c +++ b/src/lib-master/master-service-ssl-settings.c @@ -213,4 +213,5 @@ void master_service_ssl_settings_to_iostream_set( set_r->prefer_server_ciphers = ssl_set->ssl_prefer_server_ciphers; set_r->compression = ssl_set->parsed_opts.compression; set_r->tickets = ssl_set->parsed_opts.tickets; + set_r->curve_list = p_strdup(pool, ssl_set->ssl_curve_list); } -- 2.14.3
Re: 2.3.2.1 - EC keys suppport?
> 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 -curves brainpoolP512r1 ] [ openssl s_client -connect localhost: -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.
Re: 2.3.2.1 - EC keys suppport?
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 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 >> >> openssl s_client -connect localhost: >> > 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.
Re: 2.3.2.1 - EC keys suppport?
>> >>> 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 >>> 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 > > openssl s_client -connect localhost: > 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...
Re: 2.3.2.1 - EC keys suppport?
On 30 July 2018 at 21:00 ѽ҉ᶬḳ℠ < v...@gmx.net> wrote: 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 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-i
Re: 2.3.2.1 - EC keys suppport?
>> 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 >> >> 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 ] and [ openssl s_server -cert rsa.cert.pem -key rsa.key.pem -port ] and both with the output: Using default temp DH parameters ACCEPT Which would indicate this not being caused by openssl.
Re: 2.3.2.1 - EC keys suppport?
> 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 > > 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 o
Re: 2.3.2.1 - EC keys suppport?
> On 30 July 2018 at 20:37 ѽ҉ᶬḳ℠ 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(0003) > >>> 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 : > >>> 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(0003) > >>> 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(0003) > > 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 : > > 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
Re: 2.3.2.1 - EC keys suppport?
>>> 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(0003) >>> 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 : >>> 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(0003) >>> 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(0003) > 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 : > 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(0003) > 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
Re: 2.3.2.1 - EC keys suppport?
>> 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(0003) >> 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 : >> 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(0003) >> 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(0003) 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 : 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(0003) 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
Re: 2.3.2.1 - EC keys suppport?
> On 30 July 2018 at 20:01 ѽ҉ᶬḳ℠ 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(0003) > 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 : > 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(0003) > 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
Re: 2.3.2.1 - EC keys suppport?
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(0003) 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 : 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(0003) 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.
Re: 2.3.2.1 - EC keys suppport?
> On 29 July 2018 at 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 ]. > > Can you try, with your ECC cert, openssl s_client -connect server:143 -starttls imap and paste result? Aki
Re: 2.3.2.1 - EC keys suppport?
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.
Re: 2.3.2.1 - EC keys suppport?
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
Re: 2.3.2.1 - EC keys suppport?
>> 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 ].
2.3.2.1 - EC keys suppport?
Am 29.07.2018 um 21:06 schrieb ѽ҉ᶬḳ℠: > facing [ no shared cipher ] error with EC private keys. the client connecting to your instance has to support ecdsa Andreas
2.3.2.1 - EC keys suppport?
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?
