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