Thunderbird can't connect to Dovecot (bad certificate: SSL alert number 42)
Simon B
simon.buongiorno at gmail.com
Mon Sep 19 06:58:34 UTC 2022
On Sun, 18 Sept 2022 at 18:34, Jaroslaw Rafa <raj at 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
More information about the dovecot
mailing list