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

[Stuart Henderson]

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).