Thunderbird can't connect to Dovecot (bad certificate: SSL alert number 42)
Hi folks,
on a Rocky Linux 8.6 based home server I run Dovecot with an account that I use as an archive. Archive means, that from different Thunderbird instances I connect to that Dovecot via IMAPS to move emails there, that I want to keep. Since some days from all Thunderbird instances I can no longer connect to that Dovecot account. In /var/log/maillog of the server I see
Sep 14 06:39:54 server3 dovecot[2033173]: imap-login: Disconnected: Connection closed: SSL_accept() failed: error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate: SSL alert number 42 (no auth attempts in 0 secs): user=<>, rip=192.168.177.105, lip=192.168.177.13, TLS handshaking: SSL_accept() failed: error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate: SSL alert number 42, session=<dL1luJvokK3AqLFp>
I found that Openssl alert number 42 might be a problem with the SSL certificate (which certificate?) but also might be an expired SSL certificate (which certificate?). As on the Dovecot installation I work with a self signed certificat. I created a new self signed certificate yesterday with an expiry not before year 2032. That did not help, I see the same messages when I try to connect from Thunderbird.
Just to see how Thunderbird is involved in the problem I installed Claws-Mail. From Claws-Mail I do NOT have those problems, I can access to Dovecot via IMAPS as expected.
I do not understand why all my Thunderbird installations can no longer access Dovecot via IMAPS. This worked fine for about 18 months. I can't prove but I think on beginning of month it worked fine. Something happened meanwhile.
If there is a problem with an SSL certificate (bad certificate: SSL alert number 42), which certificate makes the problem? The certificate used by Dovecot or some certificate used in Thunderbird?
About installation:
cat /etc/redhat-release
Rocky Linux release 8.6 (Green Obsidian)
dovecot --version
2.3.16 (7e2e900c1a)
sudo dovecot -n
# 2.3.16 (7e2e900c1a): /etc/dovecot/dovecot.conf
# OS: Linux 4.18.0-372.19.1.el8_6.x86_64 x86_64 Rocky Linux
release 8.6 (Green Obsidian)
# Hostname: .......
auth_debug = yes
auth_mechanisms = plain login
auth_verbose = yes
first_valid_uid = 1000
mail_debug = yes
mail_gid = vmail
mail_location = maildir:~/Maildir
mail_privileged_group = vmail
mail_uid = vmail
mbox_write_locks = fcntl
namespace {
inbox = yes
location =
mailbox Archives {
special_use = \Archive
}
prefix = INBOX/
separator = /
type = private
}
passdb {
args = scheme=CRYPT username_format=%u /etc/dovecot/users
driver = passwd-file
}
protocols = imap
service imap-login {
inet_listener imap {
port = 0
}
}
ssl = required
ssl_cert = </etc/dovecot/......crt
ssl_cipher_list = PROFILE=SYSTEM
ssl_key = # hidden, use -P to show it
userdb {
args = username_format=%u /etc/dovecot/users
driver = passwd-file
}
verbose_proctitle = yesI used the following command to recreate the SSL certificate for Dovecot:
sudo openssl req -x509 -nodes -days 3650 -newkey rsa:4096
-keyout /etc/dovecot/......key -out /etc/dovecot/......crtAnd with the command
openssl s_client -crlf -connect .....:993I can successfully connect to Dovecot and "simulate" a minimal IMAP-Session:
* OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE
IDLE LITERAL+ AUTH=PLAIN AUTH=LOGIN] Dovecot ready
a login meikel.archive@..... topsecret
a OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE
IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS
THREAD=ORDEREDSUBJECT MULTIAPPEND URL-PARTIAL CATENATE
UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED
I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES
WITHIN CONTEXT=SEARCH LIST-STATUS BINARY MOVE
SNIPPET=FUZZY PREVIEW=FUZZY LITERAL+ NOTIFY
SPECIAL-USE] Logged in
a logout
* BYE Logging out
a OK Logout completed (0.001 + 0.000 secs).
closedI have the problem with different Thunderbird installations on various operating systems (Windows 10, Fedora Linux 36 XFCE).
Regards,
Meikel
Am 14.09.22 um 13:14 schrieb Meikel:
Hi folks,
on a Rocky Linux 8.6 based home server I run Dovecot with an account that I use as an archive. Archive means, that from different Thunderbird instances I connect to that Dovecot via IMAPS to move emails there, that I want to keep. Since some days from all Thunderbird instances I can no longer connect to that Dovecot account. In /var/log/maillog of the server I see
Sep 14 06:39:54 server3 dovecot[2033173]: imap-login: Disconnected: Connection closed: SSL_accept() failed: error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate: SSL alert number 42 (no auth attempts in 0 secs): user=<>, rip=192.168.177.105, lip=192.168.177.13, TLS handshaking: SSL_accept() failed: error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate: SSL alert number 42, session=<dL1luJvokK3AqLFp>
I found that Openssl alert number 42 might be a problem with the SSL certificate (which certificate?) but also might be an expired SSL certificate (which certificate?). As on the Dovecot installation I work with a self signed certificat. I created a new self signed certificate yesterday with an expiry not before year 2032. That did not help, I see the same messages when I try to connect from Thunderbird.
Just to see how Thunderbird is involved in the problem I installed Claws-Mail. From Claws-Mail I do NOT have those problems, I can access to Dovecot via IMAPS as expected.
I do not understand why all my Thunderbird installations can no longer access Dovecot via IMAPS. This worked fine for about 18 months. I can't prove but I think on beginning of month it worked fine. Something happened meanwhile.
If there is a problem with an SSL certificate (bad certificate: SSL alert number 42), which certificate makes the problem? The certificate used by Dovecot or some certificate used in Thunderbird?
... I have the problem with different Thunderbird installations on various operating systems (Windows 10, Fedora Linux 36 XFCE).
Regards,
Meikel
Is this a self signed certificate? In the past I had issues with Firefox and self signed certificates on my servers. They worked in Chromium but not Firefox. Mozilla is a bit more niggling about certificates - I'd expect the same engine in Thunderbird. I had an issue with the X509v3 extension in my certificate and one day Firefox didn't accept these certificates any longer.
If this is the case you can either create new certificates or - if this is a workaround for you - accept the certificate in Thunderbird (you might have to import it manually into Thunderbird first and adopt its trust level). I don't like the latter as it needs to be done on every client and might break trust in future.
-- Cheers spi
Hello
Sound to me, as if Thunderbird does not know the CA used to (self) sign that server certificate. As it does not know and trust that server certifikate for sending email, it disconnects with that generic error. Thunderbird has its own trusted CA store, therefore not using the one from the OS (as Claw-Mail does).
Kind regards, Christian Mack
Am 14.09.22 um 13:14 schrieb Meikel:
Hi folks,
on a Rocky Linux 8.6 based home server I run Dovecot with an account that I use as an archive. Archive means, that from different Thunderbird instances I connect to that Dovecot via IMAPS to move emails there, that I want to keep. Since some days from all Thunderbird instances I can no longer connect to that Dovecot account. In /var/log/maillog of the server I see
Sep 14 06:39:54 server3 dovecot[2033173]: imap-login: Disconnected: Connection closed: SSL_accept() failed: error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate: SSL alert number 42 (no auth attempts in 0 secs): user=<>, rip=192.168.177.105, lip=192.168.177.13, TLS handshaking: SSL_accept() failed: error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate: SSL alert number 42, session=<dL1luJvokK3AqLFp>
I found that Openssl alert number 42 might be a problem with the SSL certificate (which certificate?) but also might be an expired SSL certificate (which certificate?). As on the Dovecot installation I work with a self signed certificat. I created a new self signed certificate yesterday with an expiry not before year 2032. That did not help, I see the same messages when I try to connect from Thunderbird.
Just to see how Thunderbird is involved in the problem I installed Claws-Mail. From Claws-Mail I do NOT have those problems, I can access to Dovecot via IMAPS as expected.
I do not understand why all my Thunderbird installations can no longer access Dovecot via IMAPS. This worked fine for about 18 months. I can't prove but I think on beginning of month it worked fine. Something happened meanwhile.
If there is a problem with an SSL certificate (bad certificate: SSL alert number 42), which certificate makes the problem? The certificate used by Dovecot or some certificate used in Thunderbird?
About installation:
cat /etc/redhat-release Rocky Linux release 8.6 (Green Obsidian)
dovecot --version 2.3.16 (7e2e900c1a)
sudo dovecot -n # 2.3.16 (7e2e900c1a): /etc/dovecot/dovecot.conf # OS: Linux 4.18.0-372.19.1.el8_6.x86_64 x86_64 Rocky Linux release 8.6 (Green Obsidian) # Hostname: ....... auth_debug = yes auth_mechanisms = plain login auth_verbose = yes first_valid_uid = 1000 mail_debug = yes mail_gid = vmail mail_location = maildir:~/Maildir mail_privileged_group = vmail mail_uid = vmail mbox_write_locks = fcntl namespace { inbox = yes location = mailbox Archives { special_use = \Archive } prefix = INBOX/ separator = / type = private } passdb { args = scheme=CRYPT username_format=%u /etc/dovecot/users driver = passwd-file } protocols = imap service imap-login { inet_listener imap { port = 0 } } ssl = required ssl_cert = </etc/dovecot/......crt ssl_cipher_list = PROFILE=SYSTEM ssl_key = # hidden, use -P to show it userdb { args = username_format=%u /etc/dovecot/users driver = passwd-file } verbose_proctitle = yes
I used the following command to recreate the SSL certificate for Dovecot:
sudo openssl req -x509 -nodes -days 3650 -newkey rsa:4096 -keyout /etc/dovecot/......key -out /etc/dovecot/......crt
And with the command
openssl s_client -crlf -connect .....:993
I can successfully connect to Dovecot and "simulate" a minimal IMAP-Session:
* OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ AUTH=PLAIN AUTH=LOGIN] Dovecot ready a login meikel.archive@..... topsecret a OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS BINARY MOVE SNIPPET=FUZZY PREVIEW=FUZZY LITERAL+ NOTIFY SPECIAL-USE] Logged in a logout * BYE Logging out a OK Logout completed (0.001 + 0.000 secs). closed
I have the problem with different Thunderbird installations on various operating systems (Windows 10, Fedora Linux 36 XFCE).
Regards,
Meikel
-- Christian Mack Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung IT-Dienste Forschung, Lehre, Infrastruktur 78457 Konstanz +49 7531 88-4416
Hello.
Am 14.09.2022 um 13:59 schrieb Christian Mack:
Sound to me, as if Thunderbird does not know the CA used to (self) sign that server certificate.
Following the documentation at
https://community.letsencrypt.org/t/simple-guide-using-lets-encrypt-ssl-cert...
I configured
ssl_cert = </etc/letsencrypt/live/...../fullchain.pem ssl_key = </etc/letsencrypt/live/...../privkey.pem
to my Let's Encrypt SSL certificates and did a restart of Dovecont and at least for one installation of Thunderbird it seems to work again now. For the other installations I need to check later at home, but the problem seems to be resolved.
Regards,
Meikel
I just ran into something similar with the latest version of TB. I updated our SSL cert for Dovecot but TB could not access my email over port 993. I clicked on file then get new messages for all accounts. TB popped up a warning that the cert had an invalid/incorrect hostname and if I should allow the exception. I allowed the exception which worked and TB is fine now. I only did this because my ssl cert is a wildcard for the domain but does not explicitly list the hostname.
Mark
On 9/14/2022 8:23 AM, Meikel wrote:
Hello.
Am 14.09.2022 um 13:59 schrieb Christian Mack:
Sound to me, as if Thunderbird does not know the CA used to (self) sign that server certificate.
Following the documentation at
https://community.letsencrypt.org/t/simple-guide-using-lets-encrypt-ssl-cert...
I configured
ssl_cert = </etc/letsencrypt/live/...../fullchain.pem ssl_key = </etc/letsencrypt/live/...../privkey.pem
to my Let's Encrypt SSL certificates and did a restart of Dovecont and at least for one installation of Thunderbird it seems to work again now. For the other installations I need to check later at home, but the problem seems to be resolved.
Regards,
Meikel
Hi,
I had the same issue on TB102. Self-Signed certificates rejected despite having the CA installed correctly as authority. Turns out out that that TB now wants extension "Subject Alt Names". Added that and all works now. Seems another Google pressed issue being introduced (my Chromium had same issues and rejected certs before I added SAN).
Thanks and regards
Goetz R Schultz
---------------->8----------------
Quis custodiet ipsos custodes?
/"
\ / ASCII Ribbon Campaign
X against HTML e-mail
/
----------------8<----------------
On 14/09/2022 13:39, Mark Stevens wrote:
I just ran into something similar with the latest version of TB. I updated our SSL cert for Dovecot but TB could not access my email over port 993. I clicked on file then get new messages for all accounts. TB popped up a warning that the cert had an invalid/incorrect hostname and if I should allow the exception. I allowed the exception which worked and TB is fine now. I only did this because my ssl cert is a wildcard for the domain but does not explicitly list the hostname.
Mark
On 9/14/2022 8:23 AM, Meikel wrote:
Hello.
Am 14.09.2022 um 13:59 schrieb Christian Mack:
Sound to me, as if Thunderbird does not know the CA used to (self) sign that server certificate.
Following the documentation at
https://community.letsencrypt.org/t/simple-guide-using-lets-encrypt-ssl-cert...
I configured
ssl_cert = </etc/letsencrypt/live/...../fullchain.pem ssl_key = </etc/letsencrypt/live/...../privkey.pem
to my Let's Encrypt SSL certificates and did a restart of Dovecont and at least for one installation of Thunderbird it seems to work again now. For the other installations I need to check later at home, but the problem seems to be resolved.
Regards,
Meikel
---------------------------->8------------------------------
/"
\ / ASCII Ribbon Campaign
X against HTML e-mail
/ \
This message is transmitted on 100% recycled electrons.
---------------------------->8------------------------------ Unsigned message - no responsibillity that content is not altered
On 2022-09-14, Goetz Schultz <dovecot.expire1225@suelze.de> wrote:
I had the same issue on TB102. Self-Signed certificates rejected despite having the CA installed correctly as authority. Turns out out that that TB now wants extension "Subject Alt Names". Added that and all works now. Seems another Google pressed issue being introduced (my Chromium had same issues and rejected certs before I added SAN).
It's not just a "Google pressed issue".
The CA/Browser Forum baseline requirements say that certificates must include subjectAlternativeName. This doesn't strictly apply to non-browser applications but it does mean that all CA-issued certs can be relied upon to have SAN.
RFC 6125 6.4.4 says that clients must not check CN if the identifiers used in subjectAlternativeName are present. So for certs following the baseline requirements, checking CN is redundant. It also says that clients *may* check CN but it's not required.
There are differences in handling of name constraints between certs using just CN and those using SAN. Name constraints don't really work for certs using CN (by adding dc= components to the Subject, you can comply with the directoryNameconstraints that apply to Subject while providing a CN that is not in the expected domain). The dNSName constraint applicable to SAN doesn't have this problem.
So there's a good reason to avoid using CN when checking the name: it gives defence against a CA or sub-CA with a trusted but constrained root certificate that goes rogue.
Practically this means you need to make sure that if you use self- signed or internal CA certificates you include subjectAlternativeName otherwise they won't work with some client software. If you use public CA-signed certs you typically don't need to do this yourself because the CA adds SAN if missing from the CSR (their only other option is to reject issuance).
On 18/09/2022 11:09, Stuart Henderson wrote:
On 2022-09-14, Goetz Schultz <dovecot.expire1225@suelze.de> wrote:
I had the same issue on TB102. Self-Signed certificates rejected despite having the CA installed correctly as authority. Turns out out that that TB now wants extension "Subject Alt Names". Added that and all works now. Seems another Google pressed issue being introduced (my Chromium had same issues and rejected certs before I added SAN).
It's not just a "Google pressed issue".
Seems I was a hasty in blaming .....
[..]
Practically this means you need to make sure that if you use self- signed or internal CA certificates you include subjectAlternativeName otherwise they won't work with some client software. If you use public CA-signed certs you typically don't need to do this yourself because the CA adds SAN if missing from the CSR (their only other option is to reject issuance).
Thanks for the elaboration. I have it now under control to sign certs that have a SAN in the CSR.
Thanks and regards
Goetz R Schultz
---------------->8----------------
Quis custodiet ipsos custodes?
/"
\ / ASCII Ribbon Campaign
X against HTML e-mail
/
----------------8<----------------
---------------------------->8------------------------------
/"
\ / ASCII Ribbon Campaign
X against HTML e-mail
/ \
This message is transmitted on 100% recycled electrons.
---------------------------->8------------------------------ Unsigned message - no responsibillity that content is not altered
On Sun, 18 Sept 2022 at 12:53, Goetz Schultz <dovecot.expire1225@suelze.de> wrote:
On 18/09/2022 11:09, Stuart Henderson wrote:
On 2022-09-14, Goetz Schultz <dovecot.expire1225@suelze.de> wrote:
I had the same issue on TB102. Self-Signed certificates rejected despite having the CA installed correctly as authority. Turns out out that that TB now wants extension "Subject Alt Names". Added that and all works now. Seems another Google pressed issue being introduced (my Chromium had same issues and rejected certs before I added SAN).
It's not just a "Google pressed issue".
Seems I was a hasty in blaming .....
Not necessarily... The CA Browser Forum ad[a|o]pted this partly because Google started showing visible warnings in the Chrome Browser when the CN was not replicated in the SAN field.
Regards
Simon
Dnia 18.09.2022 o godz. 10:09:34 Stuart Henderson pisze:
The CA/Browser Forum baseline requirements say that certificates must include subjectAlternativeName. This doesn't strictly apply to non-browser applications but it does mean that all CA-issued certs can be relied upon to have SAN.
RFC 6125 6.4.4 says that clients must not check CN if the identifiers used in subjectAlternativeName are present. So for certs following the baseline requirements, checking CN is redundant. It also says that clients *may* check CN but it's not required.
There are differences in handling of name constraints between certs using just CN and those using SAN. Name constraints don't really work for certs using CN (by adding dc= components to the Subject, you can comply with the directoryNameconstraints that apply to Subject while providing a CN that is not in the expected domain). The dNSName constraint applicable to SAN doesn't have this problem.
So there's a good reason to avoid using CN when checking the name: it gives defence against a CA or sub-CA with a trusted but constrained root certificate that goes rogue.
Practically this means you need to make sure that if you use self- signed or internal CA certificates you include subjectAlternativeName otherwise they won't work with some client software. If you use public CA-signed certs you typically don't need to do this yourself because the CA adds SAN if missing from the CSR (their only other option is to reject issuance).
I have a question regarding this: I always understood (maybe wrong) SAN as literally *alternate* DNS names for the server in addition to its basic, "canonical" DNS name, which was specified in the CN.
For example if the server is example.com, but it also can be accessed as www.example.com (and both names have A records resolving to the same IP adddress), I put example.com into CN and www.example.com into SAN.
From what you have written above, I cannot figure out if this is correct, or maybe should I put both names example.com and www.example.com into SAN (in addition to example.com being in CN)?
Regards, Jaroslaw Rafa raj@rafa.eu.org
"In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub."
Le 18/09/2022 à 18:33, Jaroslaw Rafa a écrit : ...
For example if the server is example.com, but it also can be accessed as www.example.com (and both names have A records resolving to the same IP adddress), I put example.com into CN and www.example.com into SAN.
From what you have written above, I cannot figure out if this is correct, or maybe should I put both names example.com and www.example.com into SAN (in addition to example.com being in CN)? Per spec, example.com AND www.example.com should be into SAN.
Emmanuel.
On Sun, 18 Sept 2022 at 18:34, Jaroslaw Rafa <raj@rafa.eu.org> wrote:
Dnia 18.09.2022 o godz. 10:09:34 Stuart Henderson pisze:
The CA/Browser Forum baseline requirements say that certificates must include subjectAlternativeName. This doesn't strictly apply to non-browser applications but it does mean that all CA-issued certs can be relied upon to have SAN.
RFC 6125 6.4.4 says that clients must not check CN if the identifiers used in subjectAlternativeName are present. So for certs following the baseline requirements, checking CN is redundant. It also says that clients *may* check CN but it's not required.
There are differences in handling of name constraints between certs using just CN and those using SAN. Name constraints don't really work for certs using CN (by adding dc= components to the Subject, you can comply with the directoryNameconstraints that apply to Subject while providing a CN that is not in the expected domain). The dNSName constraint applicable to SAN doesn't have this problem.
So there's a good reason to avoid using CN when checking the name: it gives defence against a CA or sub-CA with a trusted but constrained root certificate that goes rogue.
Practically this means you need to make sure that if you use self- signed or internal CA certificates you include subjectAlternativeName otherwise they won't work with some client software. If you use public CA-signed certs you typically don't need to do this yourself because the CA adds SAN if missing from the CSR (their only other option is to reject issuance).
I have a question regarding this: I always understood (maybe wrong) SAN as literally *alternate* DNS names for the server in addition to its basic, "canonical" DNS name, which was specified in the CN.
For example if the server is example.com, but it also can be accessed as www.example.com (and both names have A records resolving to the same IP adddress), I put example.com into CN and www.example.com into SAN.
From what you have written above, I cannot figure out if this is correct, or maybe should I put both names example.com and www.example.com into SAN (in addition to example.com being in CN)?
As per my previous reply, the CN must now be replicated/duplicated in the SAN.
So in you example a valid .csr now contains: CN = example.com SAN.1 = example.com SAN.2 = www.example.com etc.
Of course you could also have:
CN = www.example.com SAN.1 = www.example.com SAN.2 = example.com
Regards
Simon
cert had an invalid/incorrect hostname
fyi,
https://kb.mozillazine.org/Files_and_folders_in_the_profile_-_Thunderbird
...
cert_override.txt
This is an optional file used to store a security exception. It appears to store the host name , thus preventing you from creating a security exception for a rotating SMTP server.
...for ref,
Firefox: How to audit & reset the list of trusted servers/CAs
https://access.redhat.com/solutions/1549043Hello,
I switched from self-created SSL certificates to SSL certificates from Let's Encrypt. For that I configured
ssl_cert = </etc/letsencrypt/live/...../fullchain.pem ssl_key = </etc/letsencrypt/live/...../privkey.pem
and did a restart of Dovecot. That solved the problem.
Regards,
Meikel
participants (10)
-
Christian Mack
-
Emmanuel Fusté
-
Goetz Schultz
-
Jaroslaw Rafa
-
Mark Stevens
-
Meikel
-
PGNet Dev
-
Simon B
-
spi
-
Stuart Henderson