SSL errors after certificate renewal

Stuart Henderson stu.lists at spacehopper.org
Wed Sep 8 09:53:20 EEST 2021


On 2021-09-07, Amol Kulkarni <amolk112k at gmail.com> wrote:
> 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.

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.



More information about the dovecot mailing list