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

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

On 18/09/2022 11:09, Stuart Henderson wrote:
> 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".
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

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 at 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."