SSL errors after certificate renewal
Hello,
After I replaced my certificate with a new one yesterday, I'm seeing some ssl related errors. There are successful pop/imap logins using SSL also. So I think the certificate in itself is fine. No user has complained as yet, so I don't know for sure. However the count of errors has surely increased after installing the new certificate. There are 2 errors seen : dovecot: imap-login: Disconnected (no auth attempts in 1 secs): user=<>, rip=, lip =, TLS handshaking: SSL_accept() failed: error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate unknown: SSL alert number 46, session=<9m0AnVnL 2pHf4hso>
dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=, lip =, TLS: SSL_read() failed: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate: SSL alert number 42, session=<ww/b6VfLmeR7yTog>
Kindly help with some pointers.
Thanks and Regards, Amol
You'd need to include alot more information if you're looking for resolution.
- How are you renewing your certs. Are you re-keying when you renew?
- What is your ssl_cert? Is it a single cert or a chain?
I'd set ssl_min_protocol = TLSv1.1 at the very least, probably TLSv1.2 if your users clients can handle it
If you're looking for pointers, I'd try googling the errors.
https://serverfault.com/questions/806141/is-the-alert-ssl3-read-bytessslv3-a... https://community.letsencrypt.org/t/mobile-clients-ssl-alert-number-46/12460...
On 9/7/21 2:24 PM, Marc wrote:
-- Ben Burk BURK.TECH System Administrator
On 07.09.21 19:25, Amol Kulkarni wrote:
These log messages indicate that it was the client who stopped doing the full login procedure. My first guess would be that a majority of those clients want their user/admin to confirm trust in the new server cert before they "leak" authentication tokens (user+auth) to it.
On 07.09.21 21:16, N wrote:
Separate subject, but couldn't help but notice, SSL3 is being used?
SSLv3 and at least the earlier versions of TLS share a lot of underlying cryptalgorithms, so the log messages (from double-used code) still *say* "SSL3". (If you want to be *sure*, run a scanner like sslyze against the server.)
Regards,
Jochen Bern Systemingenieur
Binect GmbH
On 2021-09-07, Amol Kulkarni <amolk112k@gmail.com> wrote:
If you mention the hostname we can check the actual problem, otherwise we have to guess.
Certificates are usually issued from an intermediate, not directly from a CA. Servers need to be configured to send that intermediate. Some (mostly GUI) clients will fetch a missing intermediate automatically but most mail clients won't.
The most common problem associated with changing cert is to forget to include the intermediate in the server config. Check with this:
openssl s_client -starttls imap -servername $hostname -connect $hostname:143
The chain should normally look something like this for a letsencrypt cert; other CAs will usually also have 3 entries but the names will differ
Certificate chain 0 s:/CN=$hostname i:/C=US/O=Let's Encrypt/CN=R3 1 s:/C=US/O=Let's Encrypt/CN=R3 i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1 2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1 i:/O=Digital Signature Trust Co./CN=DST Root CA X3
The final "i" line needs to be in the root CA store on the client machine.
The file used for "ssl_cert" in Dovecot (and same for most other services) needs to contain both the server certificate and the intermediate. Commercial CAs usually provide this in a zip or similar file with the cert. ACME clients for letsencrypt etc will usually download it automatically or can be configured to do so (certbot writes both to a "fullchain.pem" file which can be used directly).
If that doesn't help, post the hostname for a proper analysis.
participants (8)
-
Aki Tuomi
-
Amol Kulkarni
-
Ben Burk
-
Jochen Bern
-
Marc
-
N
-
Steve Dondley
-
Stuart Henderson