error 42 ssl certificate expired
Dovecot Team,
I need a little help. I came in this morning and it seems like the SSL Certificates expired for dovecot (on an internal mail server) and nobody can move email into their folders on this server. In Thunderbird they just see in the status bar: HISTORY: checking mail server capabilities...
In /var/log/maillog:
Apr 12 09:02:26 mario2 dovecot: imap-login: Disconnected (no auth
attempts in 0 secs): user=<>, rip=10.5.1.85, lip=10.5.1.17, TLS:
SSL_read() failed: error:14094412:SSL routines:ssl3_read_bytes:sslv3
alert bad certificate: SSL alert number 42, session=
I have tried:
-Restarting Dovecot -Restarting the whole mail server -Re-creating the .pem files, first moving the old files in /etc/pki/dovecot/certs and /etc/pki/dovecot/private from dovecot.pem to dovecot-old.pem, - Re-creating a new dovecot.pem using the mkcert.sh script in the doc folder in /usr/share/doc/dovecot-2.2.36/, - restarting dovecot - changing the cert values in dovecot-openssl.cnf
I also tried creating new .crt and key files using this tutorial: https://msol.io/blog/tech/create-a-self-signed-ssl-certificate-with-openssl/
I need some assistance, thank you for your help.
Chris
-- Christopher Wensink IS Administrator Five Star Plastics, Inc 1339 Continental Drive Eau Claire, WI 54701 Office: 715-831-1682 Mobile: 715-563-3112 Fax: 715-831-6075 cwensink@five-star-plastics.com www.five-star-plastics.com
On 12/04/2021 17:13 Christopher Wensink cwensink@five-star-plastics.com wrote:
Dovecot Team,
I need a little help. I came in this morning and it seems like the SSL Certificates expired for dovecot (on an internal mail server) and nobody can move email into their folders on this server. In Thunderbird they just see in the status bar: HISTORY: checking mail server capabilities...
In /var/log/maillog:
Apr 12 09:02:26 mario2 dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=10.5.1.85, lip=10.5.1.17, TLS: SSL_read() failed: error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate: SSL alert number 42, session=
I have tried:
-Restarting Dovecot -Restarting the whole mail server -Re-creating the .pem files, first moving the old files in /etc/pki/dovecot/certs and /etc/pki/dovecot/private from dovecot.pem to dovecot-old.pem, - Re-creating a new dovecot.pem using the mkcert.sh script in the doc folder in /usr/share/doc/dovecot-2.2.36/, - restarting dovecot - changing the cert values in dovecot-openssl.cnf
I also tried creating new .crt and key files using this tutorial: https://msol.io/blog/tech/create-a-self-signed-ssl-certificate-with-openssl/
I need some assistance, thank you for your help.
Chris
Please use real certs if possible. Otherwise you need to install the used CA certificate, or the self-signed certificate, to all the clients. Or reset the exception there, and then tell all your users to redo the exception. Using real certs is easier.
Aki
I confirm that the solution in Thunderbird, was they had to click on the account's inbox, then click get messages, then click the confirm security exception button on the server identity pop-up, and that fixes the issue. I could see that under Tools > Options > Certificates for the server section had a self-signed certificate which is active for 1 year, so once the new cert is generated then everyone has to just confirm the exception of the new self-signed certificate. It's an easy fix once you know the solution.
Thanks for your help Aki.
In our case this is an internally used Dovecot Mail server that's used for mail storage only, not for sending out new email and it's not the default email account to receive new messages. The server never touches the public internet, only inside the LAN traffic. In this situation are CA authority certificates worth the expense? Just curious on what everyone's opinion is of Digital Certs signed by certificate authorities that are only used inside the LAN. Thoughts?
On 4/12/2021 9:59 AM, Aki Tuomi wrote:
On 12/04/2021 17:13 Christopher Wensink cwensink@five-star-plastics.com wrote:
Dovecot Team,
I need a little help. I came in this morning and it seems like the SSL Certificates expired for dovecot (on an internal mail server) and nobody can move email into their folders on this server. In Thunderbird they just see in the status bar: HISTORY: checking mail server capabilities...
In /var/log/maillog:
Apr 12 09:02:26 mario2 dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=10.5.1.85, lip=10.5.1.17, TLS: SSL_read() failed: error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate: SSL alert number 42, session=
I have tried:
-Restarting Dovecot -Restarting the whole mail server -Re-creating the .pem files, first moving the old files in /etc/pki/dovecot/certs and /etc/pki/dovecot/private from dovecot.pem to dovecot-old.pem, - Re-creating a new dovecot.pem using the mkcert.sh script in the doc folder in /usr/share/doc/dovecot-2.2.36/, - restarting dovecot - changing the cert values in dovecot-openssl.cnf
I also tried creating new .crt and key files using this tutorial: https://msol.io/blog/tech/create-a-self-signed-ssl-certificate-with-openssl/
I need some assistance, thank you for your help.
Chris Please use real certs if possible. Otherwise you need to install the used CA certificate, or the self-signed certificate, to all the clients. Or reset the exception there, and then tell all your users to redo the exception. Using real certs is easier.
Aki
-- Christopher Wensink IS Administrator Five Star Plastics, Inc 1339 Continental Drive Eau Claire, WI 54701 Office: 715-831-1682 Mobile: 715-563-3112 Fax: 715-831-6075 cwensink@five-star-plastics.com www.five-star-plastics.com
Hi,
In our case this is an internally used Dovecot Mail server that's used for … certificates worth the expense? Just curious on what everyone's opinion is of Digital Certs signed by certificate authorities that are only used inside the LAN. Thoughts?
Aki is right. On the long run it's easier to use "offcial" certs. Since the advent of Let's encrypt it is cheap.
Of course, getting a certificate from Let's Encrypt for an internal service isn't as easy as for a public HTTP server, but it is possible.
(We use a dedicated machine, requesting certs for all our internal services, employing the DNS challenge with Let's Encrypt. From this dedicated machine then we deploy the certs into our internal infrastructure using https://gitea.schlittermann.de/heiko/cert-proxy.git)
I also tried creating new .crt and key files using this tutorial: https://msol.io/blog/tech/create-a-self-signed-ssl-certificate-with-openssl/
No need to use tech blogs. Use "man req" and brain.
openssl req -x509 -new \
-out ssl.pem \
-keyout ssl.pem -newkey rsa:4096 -nodes \
-subj /CN=example.com -days 365
(or two distinct files for crt and key).-- Heiko
Hi,
I got news: dovecot is the one that is broken, i got setup all other stuff updated to latest BUT not dovecot, and i got working system.
if I upgrade dovecot, the installation breaks. I'm using letencrypt's certs.
The version that is good is 2.3.7.2 (3c910f64b)
Heiko Schlittermann kirjoitti 12.4.2021 klo 23:20:
Hi,
In our case this is an internally used Dovecot Mail server that's used for … certificates worth the expense? Just curious on what everyone's opinion is of Digital Certs signed by certificate authorities that are only used inside the LAN. Thoughts? Aki is right. On the long run it's easier to use "offcial" certs. Since the advent of Let's encrypt it is cheap.
Of course, getting a certificate from Let's Encrypt for an internal service isn't as easy as for a public HTTP server, but it is possible.
(We use a dedicated machine, requesting certs for all our internal services, employing the DNS challenge with Let's Encrypt. From this dedicated machine then we deploy the certs into our internal infrastructure using https://gitea.schlittermann.de/heiko/cert-proxy.git)
I also tried creating new .crt and key files using this tutorial: https://msol.io/blog/tech/create-a-self-signed-ssl-certificate-with-openssl/ No need to use tech blogs. Use "man req" and brain.
openssl req -x509 -new \ -out ssl.pem \ -keyout ssl.pem -newkey rsa:4096 -nodes \ -subj /CN=example.com -days 365 (or two distinct files for crt and key).
Uh. You are practically proposing that all versions after 2.3.7.2 would be serving expired SSL certs, due to some bug? It that was the case, then I would believe we would've been inundated with bug reports for the past year or so. Installation probably breaks because you are using expired cert, from wrong path.
Doublecheck output of doveconf -nP and openssl x509 -text to make sure you are indeed using correct, non-expired certificate.
Aki
On 13/04/2021 07:16 gmail ljakku77@gmail.com wrote:
Hi,
I got news: dovecot is the one that is broken, i got setup all other stuff updated to latest BUT not dovecot, and i got working system.
if I upgrade dovecot, the installation breaks. I'm using letencrypt's certs.
The version that is good is 2.3.7.2 (3c910f64b)
Heiko Schlittermann kirjoitti 12.4.2021 klo 23:20:
Hi,
In our case this is an internally used Dovecot Mail server that's used for … certificates worth the expense? Just curious on what everyone's opinion is of Digital Certs signed by certificate authorities that are only used inside the LAN. Thoughts? Aki is right. On the long run it's easier to use "offcial" certs. Since the advent of Let's encrypt it is cheap.
Of course, getting a certificate from Let's Encrypt for an internal service isn't as easy as for a public HTTP server, but it is possible.
(We use a dedicated machine, requesting certs for all our internal services, employing the DNS challenge with Let's Encrypt. From this dedicated machine then we deploy the certs into our internal infrastructure using https://gitea.schlittermann.de/heiko/cert-proxy.git)
I also tried creating new .crt and key files using this tutorial: https://msol.io/blog/tech/create-a-self-signed-ssl-certificate-with-openssl/ No need to use tech blogs. Use "man req" and brain.
openssl req -x509 -new \ -out ssl.pem \ -keyout ssl.pem -newkey rsa:4096 -nodes \ -subj /CN=example.com -days 365 (or two distinct files for crt and key).
I got forcibly renewed my certs.
dovecot -nP:
# 2.3.7.2 (3c910f64b): /etc/dovecot/dovecot.conf # Pigeonhole version 0.5.7.2 () # OS: Linux 5.9.0-rc5-lja-tv+ x86_64 Ubuntu 20.04.2 LTS # Hostname: superman.sillywalk.org auth_debug = yes auth_debug_passwords = yes auth_mechanisms = plain login auth_username_format = %Ln auth_verbose = yes auth_verbose_passwords = plain debug_log_path = /var/log/dovecot-debug.log info_log_path = /var/log/dovecot-info.log log_path = /var/log/dovecot.log mail_debug = yes mail_location = maildir:~/Maildir/ mbox_write_locks = fcntl namespace inbox { inbox = yes location = mailbox Drafts { special_use = \Drafts } mailbox Junk { special_use = \Junk } mailbox Sent { special_use = \Sent } mailbox "Sent Messages" { special_use = \Sent } mailbox Trash { special_use = \Trash } prefix = } passdb { driver = pam } protocols = imap pop3 lmtp service auth { unix_listener /var/spool/postfix/private/auth { group = mail mode = 0660 user = postfix } } service lmtp { unix_listener /var/spool/postfix/private/dovecot-lmtp { group = mail mode = 0660 user = postfix } } ssl_cert =
local_name paxsudos.com { ssl_cert =
local_name lja.fi { ssl_cert =
The certs are working fine and are up to date. (Apache2 with same certs for domains works ok)
I not know howto use openssl x509 -text command, if i run it like
echo "" | openssl x509 -text
I get loads of errors.
My distro:
Distributor ID: Ubuntu Description: Ubuntu 20.04.2 LTS Release: 20.04 Codename: focal
Aki Tuomi kirjoitti 13.4.2021 klo 7:40:
Uh. You are practically proposing that all versions after 2.3.7.2 would be serving expired SSL certs, due to some bug? It that was the case, then I would believe we would've been inundated with bug reports for the past year or so. Installation probably breaks because you are using expired cert, from wrong path.
Doublecheck output of
doveconf -nPandopenssl x509 -textto make sure you are indeed using correct, non-expired certificate.Aki
On 13/04/2021 07:16 gmail ljakku77@gmail.com wrote:
Hi,
I got news: dovecot is the one that is broken, i got setup all other stuff updated to latest BUT not dovecot, and i got working system.
if I upgrade dovecot, the installation breaks. I'm using letencrypt's certs.
The version that is good is 2.3.7.2 (3c910f64b)
Heiko Schlittermann kirjoitti 12.4.2021 klo 23:20:
Hi,
In our case this is an internally used Dovecot Mail server that's used for … certificates worth the expense? Just curious on what everyone's opinion is of Digital Certs signed by certificate authorities that are only used inside the LAN. Thoughts? Aki is right. On the long run it's easier to use "offcial" certs. Since the advent of Let's encrypt it is cheap.
Of course, getting a certificate from Let's Encrypt for an internal service isn't as easy as for a public HTTP server, but it is possible.
(We use a dedicated machine, requesting certs for all our internal services, employing the DNS challenge with Let's Encrypt. From this dedicated machine then we deploy the certs into our internal infrastructure using https://gitea.schlittermann.de/heiko/cert-proxy.git)
I also tried creating new .crt and key files using this tutorial: https://msol.io/blog/tech/create-a-self-signed-ssl-certificate-with-openssl/ No need to use tech blogs. Use "man req" and brain.
openssl req -x509 -new \ -out ssl.pem \ -keyout ssl.pem -newkey rsa:4096 -nodes \ -subj /CN=example.com -days 365 (or two distinct files for crt and key).
To me it seems you are serving a valid cert, i checked with openssl s_client -connect host:443 -servername domain
Not sure why you have all those local_name blocks there when the cert you are offering covers all your names already.
Aki
On 13/04/2021 07:59 gmail ljakku77@gmail.com wrote:
I got forcibly renewed my certs.
dovecot -nP:
# 2.3.7.2 (3c910f64b): /etc/dovecot/dovecot.conf # Pigeonhole version 0.5.7.2 () # OS: Linux 5.9.0-rc5-lja-tv+ x86_64 Ubuntu 20.04.2 LTS # Hostname: superman.sillywalk.org auth_debug = yes auth_debug_passwords = yes auth_mechanisms = plain login auth_username_format = %Ln auth_verbose = yes auth_verbose_passwords = plain debug_log_path = /var/log/dovecot-debug.log info_log_path = /var/log/dovecot-info.log log_path = /var/log/dovecot.log mail_debug = yes mail_location = maildir:~/Maildir/ mbox_write_locks = fcntl namespace inbox { inbox = yes location = mailbox Drafts { special_use = \Drafts } mailbox Junk { special_use = \Junk } mailbox Sent { special_use = \Sent } mailbox "Sent Messages" { special_use = \Sent } mailbox Trash { special_use = \Trash } prefix = } passdb { driver = pam } protocols = imap pop3 lmtp service auth { unix_listener /var/spool/postfix/private/auth { group = mail mode = 0660 user = postfix } } service lmtp { unix_listener /var/spool/postfix/private/dovecot-lmtp { group = mail mode = 0660 user = postfix } } ssl_cert =
local_name paxsudos.com { ssl_cert =
local_name lja.fi { ssl_cert =
The certs are working fine and are up to date. (Apache2 with same certs for domains works ok)
I not know howto use openssl x509 -text command, if i run it like
echo "" | openssl x509 -text
I get loads of errors.
My distro:
Distributor ID: Ubuntu Description: Ubuntu 20.04.2 LTS Release: 20.04 Codename: focal
Aki Tuomi kirjoitti 13.4.2021 klo 7:40:
Uh. You are practically proposing that all versions after 2.3.7.2 would be serving expired SSL certs, due to some bug? It that was the case, then I would believe we would've been inundated with bug reports for the past year or so. Installation probably breaks because you are using expired cert, from wrong path.
Doublecheck output of
doveconf -nPandopenssl x509 -textto make sure you are indeed using correct, non-expired certificate.Aki
On 13/04/2021 07:16 gmail ljakku77@gmail.com wrote:
Hi,
I got news: dovecot is the one that is broken, i got setup all other stuff updated to latest BUT not dovecot, and i got working system.
if I upgrade dovecot, the installation breaks. I'm using letencrypt's certs.
The version that is good is 2.3.7.2 (3c910f64b)
Heiko Schlittermann kirjoitti 12.4.2021 klo 23:20:
Hi,
In our case this is an internally used Dovecot Mail server that's used for … certificates worth the expense? Just curious on what everyone's opinion is of Digital Certs signed by certificate authorities that are only used inside the LAN. Thoughts? Aki is right. On the long run it's easier to use "offcial" certs. Since the advent of Let's encrypt it is cheap.
Of course, getting a certificate from Let's Encrypt for an internal service isn't as easy as for a public HTTP server, but it is possible.
(We use a dedicated machine, requesting certs for all our internal services, employing the DNS challenge with Let's Encrypt. From this dedicated machine then we deploy the certs into our internal infrastructure using https://gitea.schlittermann.de/heiko/cert-proxy.git)
> I also tried creating new .crt and key files using this tutorial: > https://msol.io/blog/tech/create-a-self-signed-ssl-certificate-with-openssl/ No need to use tech blogs. Use "man req" and brain.
openssl req -x509 -new \ -out ssl.pem \ -keyout ssl.pem -newkey rsa:4096 -nodes \ -subj /CN=example.com -days 365 (or two distinct files for crt and key).
gmail ljakku77@gmail.com (Di 13 Apr 2021 06:16:38 CEST):
Hi,
I got news: dovecot is the one that is broken, i got setup all other stuff updated to latest BUT not dovecot, and i got working system.
Are you referring to the original topic of this thread? Or is this a new issue?
I'm asking, because your address doesn't match the OP's address and somehow the information you're presenting doesn't fit the OP's information (Self signed certs vs LE certs)
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann-- SCHLITTERMANN.de ---------------------------- internet & unix support - Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} - gnupg encrypted messages are welcome --------------- key ID: F69376CE -
participants (4)
-
Aki Tuomi
-
Christopher Wensink
-
gmail
-
Heiko Schlittermann