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