Re: AW: 2.3.2.1 - relay to lmtps from other lan host
Got it working. The error (TLS handshake failed: The TLS connection was
non-properly terminated) seems to be caused by [ msmtp ] not supporting
EC certificates.
> Right, now I got then
>
>> service lmtp {
>> unix_listener lmtp {
>> #mode = 0666
>> }
>>
>> inet_listener lmtp {
>> address = 172.24.109.6
>> port = 24
>> }
>> }
> and [ msmtp ] is connecting indeed. Does TLS/STARTTLS need to be added
> to [ inet_listener lmtp ] in order to facilitate [ lmptps ]? If so what
> is the syntax?
>
> Right now this error comes up:
>
>> msmtp: TLS handshake failed: The TLS connection was non-properly
>> terminated.
>> So what should be listening on port 262? Unix sockets are not tcp ports.
>> You have lmtp as unix socket configured but want to access from remote via
>> tcp socket? I think you need inet_listener instead of unix_ listener
>>
>>> looked into the [ dovecot wiki ] but a search for [ lmtps ] came up
>>> empty and thus hoping to get some assistance here.
>>>
>>> I am trying to relay with [ msmtp ] via [ lmtps ] from a lan host other
>>> than [ dovecot ] is running on.
>>>
>>> [ dovecot config ]
>>>
service lmtp {
unix_listener lmtp {
#mode = 0666
}
>>> [ ss -wxl | grep lmtp ]
u_strLISTEN 0 100 /var/run/dovecot/lmtp 68262 * 0
>>> So far so good. Now from the other lan host -> [ msmtp --serverinfo
>>> --tls --tls-certcheck=off --host=172.24.109.6 --protocol=lmtp --port=262
>>> ] produces:
>>>
msmtp: cannot connect to 172.24.109.6, port 262: Connection refused
>
Re: AW: 2.3.2.1 - relay to lmtps from other lan host
Right, now I got then
> service lmtp {
> unix_listener lmtp {
> #mode = 0666
> }
>
> inet_listener lmtp {
> address = 172.24.109.6
> port = 24
> }
> }
and [ msmtp ] is connecting indeed. Does TLS/STARTTLS need to be added
to [ inet_listener lmtp ] in order to facilitate [ lmptps ]? If so what
is the syntax?
Right now this error comes up:
> msmtp: TLS handshake failed: The TLS connection was non-properly
> terminated.
> So what should be listening on port 262? Unix sockets are not tcp ports.
> You have lmtp as unix socket configured but want to access from remote via
> tcp socket? I think you need inet_listener instead of unix_ listener
>
>> looked into the [ dovecot wiki ] but a search for [ lmtps ] came up
>> empty and thus hoping to get some assistance here.
>>
>> I am trying to relay with [ msmtp ] via [ lmtps ] from a lan host other
>> than [ dovecot ] is running on.
>>
>> [ dovecot config ]
>>
>>> service lmtp {
>>> unix_listener lmtp {
>>> #mode = 0666
>>> }
>> [ ss -wxl | grep lmtp ]
>>> u_strLISTEN 0 100 /var/run/dovecot/lmtp 68262 * 0
>> So far so good. Now from the other lan host -> [ msmtp --serverinfo
>> --tls --tls-certcheck=off --host=172.24.109.6 --protocol=lmtp --port=262
>> ] produces:
>>
>>> msmtp: cannot connect to 172.24.109.6, port 262: Connection refused
>>
2.3.2.1 - relay to lmtps from other lan host
Hi,
looked into the [ dovecot wiki ] but a search for [ lmtps ] came up
empty and thus hoping to get some assistance here.
I am trying to relay with [ msmtp ] via [ lmtps ] from a lan host other
than [ dovecot ] is running on.
[ dovecot config ]
> service lmtp {
> unix_listener lmtp {
> #mode = 0666
> }
[ ss -wxl | grep lmtp ]
> u_strLISTEN 0 100 /var/run/dovecot/lmtp 68262 * 0
So far so good. Now from the other lan host -> [ msmtp --serverinfo
--tls --tls-certcheck=off --host=172.24.109.6 --protocol=lmtp --port=262
] produces:
> msmtp: cannot connect to 172.24.109.6, port 262: Connection refused
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?
> >>> 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: dovecot 2.3.x, ECC and wildcard certificates, any issues
>> That is one of the reasons I do not bother since long with public CAs >> but rather deploy my own, including own OSCP responder. > May I ask, how you create a CA which is valid for clients without them > having to install your root cert? > > and CA trust in clients. Latter though could be easily overcome if browser and email clients were to support DNSSEC/DANE validation. That is where DANE/TLSA comes in but it requires DNSSEC/DANE validation in the client and of course DNSSEC and TLSA records in the domain's DNS. Notwithstanding that the upstream DNS resolvers utilized by clients need to support DNSSEC queries/answers as well. Whatever the reasons for lacking such validation support in most of the clients (incl. web browsers) one speculative is that it would kill commercial CAs (as such Let's Encrypt is one too through their sponsors), or at least has the potential to diminish their business (model). Suppose we are not hijacking this thread furthermore and avoid earning a discontent eventually ... ;)
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: dovecot 2.3.x, ECC and wildcard certificates, any issues
That is one of the reasons I do not bother since long with public CAs but rather deploy my own, including own OSCP responder. Which has of course has some drawbacks like redundancy, resilience, bandwidth provision, geographical spread, implementing CA security standards and CA trust in clients. Latter though could be easily overcome if browser and email clients were to support DNSSEC/DANE validation. It may not help you in the short term now but perhaps something to consider long term for the benefit of controlling the certificate handling/signing, depending on the CA scale. > Hello, > > I have discovered what I believe is the issue after hearing back from > Aquamail. And that is that android 7 which I'm running 7.0 that is, > only supports up to the p256 ecc curve. This brings up a question to > users of letsencrypt, when you revoke a certificate does it take it > out on the usage as well? I've got one domain that says i've issued to > many certificates for it and no more can be issued, thought I was > using the staging server. I'd like to get those certs off the > letsencrypt servers so I can make a new one using the p256 curve. Does > anyone know if this is doable? Using acme.sh I tried --revoke which > revoked one cert but letsencrypt still would not let me issue another. > > Thanks. > Dave. > > > On 7/30/18, Aki Tuomi wrote: >> I don't know how to get both RSA and ECC cert from letsencrypt. >> >> Aki >> >>> On 30 July 2018 at 20:43 David Mehler wrote: >>> >>> >>> Hello, >>> >>> What acme implementation do you use for your letsencrypt certificates? >>> If it's acme.sh how do you get both rsa and ecc certificates? What >>> configuration options are you using in your configuration of services >>> to allow access to both rsa and ecc? >>> >>> Thanks. >>> Dave. >>> >>> >>> On 7/30/18, David Mehler wrote: Hello, The client in question is the latest version of AquaMail running on android. Thanks. Dave. On 7/30/18, Aki Tuomi wrote: > You should, in practice, enable both. This gives best client > compability. > It > is possible you have clients that cannot understand ECC certificates? > You > can use ssl_alt_cert to provide RSA cert too. > > Aki > >> On 30 July 2018 at 20:05 David Mehler wrote: >> >> >> Hi, >> >> Thanks, good news is that worked. Bad news is it all looks good which >> means I do not know hwhy my remote clients can't get their email, >> looked like from the logs it was that. >> >> Would 143 be better or 993 for the external clients? >> >> Thanks. >> Dave. >> >> >> On 7/30/18, Aki Tuomi wrote: On 30 July 2018 at 19:16 David Mehler wrote: Hello, Does dovecot 2.3.x have any issues recognizing or using certificates that are ECC and wildcard? I'm trying to switch my letsencrypt implementation from acme-client which does not support either of those capabilities to acme.sh which does. Since then external clients checking their email has not worked. A manual telnet to mail.example.com 993 gives a connected message but then nothing no greeting or capabilities. The certificate is for example.com with an alt name of *.example.com if that's not right let me know, i'm not sure about that one, connecting to the web sites of these pages seems noticeably slower, I'm wondering if both of these issues aren't key related? Thanks. Dave. >>> These both should be fine. >>> >>> Port 993 is TLS encrypted, you should use openssl s_client -connect >>> server:993 >>> >>> Aki >>>
2.3.2.1 - ssl_alt_key revealed with dovecot -n
Seems like a minor cosmetic bug with [ dovecot -n ] ssl_alt_key =
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?
>> 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
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,
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
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?
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?
>> 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?
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?
