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 {
>>
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 [
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 {
>
> 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
>
>>> 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 |
>> 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
> 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
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.
Seems like a minor cosmetic bug with [ dovecot -n ]
ssl_alt_key =
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
>>
>>> 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
>> 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
>>
> 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.
>>> 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
>> 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
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
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
>> 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 ->
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 [
19 matches
Mail list logo
