dovecot - Sep 2022 - Thunderbird can't connect to Dovecot (bad certificate: SSL alert number 42)

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-certs-with-dovecot/2921
>>
>>
>> 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 at 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).