Seems wrong to me too, Robert. If you put your private key inside your certificate, won't it be sent to the client along with it ? Bastian, are you using an old version of thunderbird ? googling for "SSL alert number 42" gave me two results indicating a bug in thunderbird versions 31,32 and 33. You can check these links if you wish : * http://www.dovecot.org/list/dovecot/2014-July/097133.html * http://unix.stackexchange.com/questions/123367/thunderbird-fails-to-connect-to-dovecot-and-postfix -- Yassine On Friday, February 17, 2017 7:29 PM, Robert L Mathews <lists at tigertech.com> wrote: On 2/17/17 8:58 AM, Bastian Sebode wrote:> I uploaded two Wireshark tracefiles, further logs and dovecot -nLooking at your dovecot -n, you're using two different files here: ssl_cert = </etc/ssl/sebode-online.de/chain.pem ssl_key = </etc/ssl/sebode-online.de/key.pem Are you sure these two files match, and contain the right things in the right order? We use a single PEM file as input for both of these parameters, and that PEM file contains, in this order: -----BEGIN RSA PRIVATE KEY----- ... -----BEGIN CERTIFICATE----- ... -----BEGIN CERTIFICATE----- ... where the first BEGIN CERTIFICATE is the specific hostname one, and the second BEGIN CERTIFICATE is the Let's Encrypt X3 intermediate certificate that ends with "DNFu0Qg==". You're also manually specifying these non-default parameters: ssl_cipher_list = ... ssl_prefer_server_ciphers = yes ssl_protocols = !SSLv2 !SSLv3 For testing, I would simplify. Does it work without any of those three things set? -- Robert L Mathews, Tiger Technologies, http://www.tigertech.net/
On 2017-02-17 22:38, chaouche yacine wrote:> Seems wrong to me too, Robert. If you put your private key inside your > certificate, won't it be sent to the client along with it ?This is one way of supplying cert + key to a daemon and no, the key is not sent to the client. While it is normaly true that one doesn't want the key to have access rights other than 0600, with dovecot as the file owner of the key+cert+intermediate .pem file the access rights can be set to 0600. -- Christian Kivalo
On 2/17/2017 2:38 PM, chaouche yacine wrote:> Seems wrong to me too, Robert. If you put your private key inside your certificate, won't it be sent to the client along with it ?The private key should not be sent to the connecting client, even if it is contained in the same place as the certificate(s). If that data *is* sent to the client, that's a bug, probably in the SSL library (usually openssl). I am not using letsencrypt for my personal install, but my certificate provider does use one intermediate, just like letsencrypt does. I have the server certificate, the intermediate certificate, and the private key all in the same file, and my dovecot config contains these lines, both referring to that file: ssl_cert_file = /etc/ssl/certs/local/imap.REDACTED.com.pem ssl_key_file = /etc/ssl/certs/local/imap.REDACTED.com.pem This file is owned by root and has 600 permissions. Because root permissions are required in order to bind to port numbers below 1024, dovecot typically will initially start as root, then drop permissions as required. hostname:/etc/ssl/certs/local# ls -al imap.REDACTED.com.pem -rw------- 1 root root 6266 Jan 6 20:47 imap.REDACTED.com.pem Thanks, Shawn
Interesting. Is there any particular benefit in having only one file for both certificate and private key ? I find that putting private key in a separate file feels more secure. Bastian, how could two identical certificates be processed differently by Thunderbid ? how did you check the differences between the two ? did you use "diff" ? did you compare the output of openssl x509 commands ? what method did you choose ? -- Yassine.
On 2/17/17 1:38 PM, chaouche yacine wrote:> Seems wrong to me too, Robert. If you put your private key inside > your certificate, won't it be sent to the client along with it ?No; any SSL software that uses the file will extract the parts it needs from it and convert them to its internal format for future use. It never literally sends the file contents anywhere. It's common and often recommended for a PEM file to contain everything needed; see, for example, the bottom section of: https://www.digicert.com/ssl-support/pem-ssl-creation.htm Doing this avoids the key and certificate files getting out of sync later. -- Robert L Mathews, Tiger Technologies, http://www.tigertech.net/
On 02/18/2017 10:24 PM, Robert L Mathews wrote:> On 2/17/17 1:38 PM, chaouche yacine wrote: > >> Seems wrong to me too, Robert. If you put your private key inside >> your certificate, won't it be sent to the client along with it ? > > No; any SSL software that uses the file will extract the parts it needs > from it and convert them to its internal format for future use. It never > literally sends the file contents anywhere. > > It's common and often recommended for a PEM file to contain everything > needed; see, for example, the bottom section of: > > https://www.digicert.com/ssl-support/pem-ssl-creation.htm > > Doing this avoids the key and certificate files getting out of sync later. >I don't use Let's Encrypt but to avoid them getting out of sync, I simply put a time stamp in the filename, e.g. /etc/pki/tls/private/deviant.email-20160427.key /etc/pki/tls/certs/deviant.email-20160427.crt I never re-use a private key, when a cert expires I always generate a new private key with a new CSR. That's one of the reasons I don't like Let's Encrypt, with one year certs it is easier to look at the certs and see what is going to expire in the coming month needing a new private key. Let's Encrypt does 3 month certs and re-uses the private key when it generates a new cert. I'm sure it probably could be scripted to use a new private key every time but then I have to have to update the TLSA record frequently (and you have to have the new fingerprint TLSA record in DNS before you start using it) and that would be a hassle. I'm sure it probably could also be scripted to use a new private key every fourth time, too. But for me its just easier to have certs that last a year and I can easily visually see what is going to need my action.