I have try LE on October 2016 and use Icedove 45.6.0. I can't found any certificate of LE in certificate manager -> authorities

On 20.02.2017 15:43, chaouche yacine wrote:

Hello Basti. Maybe you tried LE too early when it was not universally accepted as a trusted CA ?

On Monday, February 20, 2017 2:22 PM, basti <basti@unix-solution.de> wrote:

Hello, I had the same problem. LE is not in the CA list.

Best Regards,

Hello, I have fixed my problem. I had used the wrong cert-file. ssl_cert = </.../cert.pem before I try "fullchain.pem"

On 20.02.2017 17:35, chaouche yacine wrote:

Bast, the way I understand it is that Let's Encrypt is not a Root Certificate Authority, it's an intermediate. The root CA of Let's Encrypt is " DST_Root_CA_X3.crt", you should find it in /etc/ssl/certs/. I have sucessfully installed a Let's Encrypt certificate on a debian machine by Octobre 2016th too and it worked just fine.

-- Yassine.

On 2017.02.17. 22:31, Bastian Sebode wrote:

Hey Robert,

thanks for your reply.

Am 17.02.2017 um 19:28 schrieb Robert L Mathews:

...

Looking 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, chain.pem contains your cert + immediate? By default certbot in chain.pem includes only itermediate cert's and if you wan't everything, it's included in fullchain.

-- KSB

Hey.

Thanks again for your help. I took the "dovecot -n" while the StartSSL Certificate was active, so the chain.pem was correct.

Finally I found the issue! :-) But I still have no idea why the problem happens with Thunderbird.

I used dehydrated to fetch the certificates from Let's Encrypt and as I said, it works for most clients pretty well. (Tried: Mulberry, Claws Mail, Outlook 2010, Android (HTC), iPhone, ...) Also it works perfectly with all my HTTPS-Services

Whatever, Thunderbird didn't like that cert saying "bad certificate" (SSL Alert 42).

Now I fetched the cert with Certbot and it works. Really strange though!

I checked for any obvious differences between the certificates and private keys, but couldn't find any.

So my solution will be to use certbot instead of dehydrated... :-/

Worst thing is, that a Microsoft Blog article (https://blogs.msdn.microsoft.com/kaushal/2012/10/05/ssltls-alert-protocol-th...) led me to the right direction.... ;-)

42 bad_certificate "There is a problem with the certificate, for example, a certificate is corrupt, or a certificate contains signatures that cannot be verified."

Peace Bastian

Am 17.02.2017 um 21:58 schrieb Aki Tuomi:

Usually with LE, the filename is fullchain.pem, not chain.pem.

Can you please doublecheck this?

Also, try

openssl s_client -connect hostname:143 -starttls imap

Aki

...

On February 17, 2017 at 10:31 PM Bastian Sebode <b.sebode@linet-services.de> wrote:

Hey Robert,

thanks for your reply.

Am 17.02.2017 um 19:28 schrieb Robert L Mathews:

...

Looking 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?

Yes, unfortunately I'm sure that everything has the right order. As you can see in the trace, both certificates (mine and the intermediate) get transferred to the client on connection.

...

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==".

Tried that, but without success. But your usage doesn't seem right to me. The parameters are not called ssl_cert and ssl_key for nothing. ;-) Normally you don't want your private key to have any other permissions than 600.

...

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?

Tried this before. I set all SSL specific settings exactly like my friend where it works without a problem. But it doesn't work for me.

Thanks anyway for your effort! Bastian

Bastian Sebode Fachinformatiker Systemintegration

LINET Services GmbH | Cyriaksring 10a | 38118 Braunschweig Tel. 0531-180508-0 | Fax 0531-180508-29 | http://www.linet-services.de

LINET in den sozialen Netzwerken: www.twitter.com/linetservices | www.facebook.com/linetservices Wissenswertes aus der IT-Welt: www.linet-services.de/blog/

Geschäftsführung: Timo Springmann, Mirko Savic und Moritz Bunkus HR B 9170 Amtsgericht Braunschweig

USt-IdNr. DE 259 526 516

-- Bastian Sebode Fachinformatiker Systemintegration

LINET Services GmbH | Cyriaksring 10a | 38118 Braunschweig Tel. 0531-180508-0 | Fax 0531-180508-29 | http://www.linet-services.de

LINET in den sozialen Netzwerken: www.twitter.com/linetservices | www.facebook.com/linetservices Wissenswertes aus der IT-Welt: www.linet-services.de/blog/

Geschäftsführung: Timo Springmann, Mirko Savic und Moritz Bunkus HR B 9170 Amtsgericht Braunschweig

USt-IdNr. DE 259 526 516

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-...

-- Yassine

On Friday, February 17, 2017 7:29 PM, Robert L Mathews <lists@tigertech.com> wrote:

On 2/17/17 8:58 AM, Bastian Sebode wrote:

I uploaded two Wireshark tracefiles, further logs and dovecot -n

Looking 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 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

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/

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.

I use dehydrated (with Cloudflare DNS challenges) and as far as I know, it seems to generate a new private key every time. All newly generated certs are generated with the timestamp in the filenames and the soft links updated to point to the latest timestamped files. I have 4 domains each with an average of 70 alt names, so Let’s Encrypt is saving me money. I simply run the dehydrated script every week in a cron job to regenerate the certs (if there is less than 30 days until the current cert is set to expire) and rotate in any new certs.

Of course, I run my sites using Docker and it is very easy to automate renewing certs. Note that I had the dehydrated script fail occasionally (mostly with 500 Server Busy errors for the Let’s Encrypt ACME server that sometimes cause me to have to wait a week before the script will succeed).

Automating cert renewal and cert rotation into production using Let’s Encrypt and Docker is a huge win for me, and has taken the pain out of manually doing this once a year for each domain (and paying high fees for the privilege). And using the DNS-01 challenge type means that I can easily generate certs for my mail domain (that doesn’t have a web server). In fact, using Cloudflare DNS is free so even DNS for my mail domain doesn’t cost anything.

Kevin

On Feb 19, 2017, at 2:00 AM, Michael A. Peters <mpeters@domblogger.net> wrote:

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.

On 02/19/2017 08:39 PM, Michael A. Peters wrote:

Every time I change the private key -

A) I have to make a TLSA record for the new key

You're actually expected to pin the CA in your TLSA record, not your own key.

https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-r...

http://www.internetsociety.org/deploy360/blog/2016/01/lets-encrypt-certifica...

https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certific...

I had the privilege of being auto-yelled at by Viktor Dukhovni over forgetting to adjust my TLSA after changing certificates for SMTP. I would however prefer to automate the process of pushing new TLSA records, waiting out twice the TTL and then pushing the certificate. Going through this every time would ensure I have valid records every time, without having to worry about the CA key changing. This is on my to-do list, for SMTP, XMPP, IMAP etc.

On 02/20/2017 01:32 AM, chaouche yacine wrote:

What is the motivation behind using a new pair of keys and CSR ?

Every now and then, a bug in the OpenSSL API is found that leaked the private key under certain conditions.

By replacing the private key once a year with a new one, you are at lower risk of having a private key that is exposed by such a bug even if the bug isn't published and only a few know about it.

heartbleed was one such bug, DROWN was another.

Obviously when a bug of that type is found and reported and your server was potentially vulnerable you change right away - but when you use the same private key for a long time, you risk a scenario where the NSA knew about it, you stopped using the protocol or cipher before it became public, it becomes public several years later but you aren't worried because you haven't run that protocol or cipher suite in quite some time

• yet the NSA already has your private key from years ago.

That's why I always generate new private key once a year.

It just reduces exploitable exposure in the unlikely but possible scenario that the private key was compromised and I did not know it.

That's also why I only allow ciphers that use forward secrecy for connections from mail clients.

On 19 Feb 2017, at 00:00, Michael A. Peters <mpeters@domblogger.net> wrote:

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.

Since renewal is entirely automatic, when certs expire is meaningless. There is no need to check unless a cert has NOT renewed, which you are notified of so you have time to figure out what you broke.

-- Apple broke AppleScripting signatures in Mail.app, so no random signatures.