Expose X509SubjectAlternativeNameExtension (or a reasonable facsimilie thereof)

[bartonjs]

Users who want to inspect Subject Alternative Names do so by parsing the output of X509Extension.Format, which is not consistent across cultures or operating systems.

One possible approach is just expose GeneralName and be transparent about the SEQUENCE. But what most scenarios probably want is something more like cert.MatchesHost(string) (so there's at least a consistent interpretation of wildcard matching); which would then likely also make sense on the rich type of the extension. (The problem with MatchesHost is that there are various interpretations for CN fallback, wildcard matching, et cetera; and specifying a lot of flags may not be what anyone wants, either).

[vcsjones]

Thinking about this a bit more, I think an API with this API surface is a good place to start a discussion:

namespace System.Security.Cryptography.X509Certificates {
    public class X509Certificate2 {
        public bool IsMatchForHostName(string hostName, bool ignoreCommonName = false) => throw null;
    }
}

I think this is probably the API that a lot of folks want. Implementing wildcard matching yourself has a lot more sharp edges than one might think, and I think this API should help solve that as well.

I do think there should be a flag for including or excluding matching the CN. I would propose these rules:

• ignoreCommonName = true
  • Uses the SAN of the certificate only. A certificate with no SAN returns false.
• ignoreCommonName = false
  • If the certificate has both the SAN extension and the CN, only the SAN is used. If the SAN extension is missing entirely, then fallback to CN.

Things get weird with IP addresses, so I would consider we try to parse the hostName as an IP address, if it fails, we only consider dNSName. If it succeeds, we use iPAddress in the SAN.

There are some browsers out there that will match an IP address in a dNSName (incorrectly), I don't think we should preserve this behavior here.

Things I am not sure about with my proposal

1. I don't like the ignoreCommonName parameter name given that it can still be ignored if there is a SAN.
2. For ignoreCommonName = false" above, I considered making it work more like a union of the names rather than a fallback, however I believe most browsers do it the way I proposed initially (Chrome flat out ignores the CN entirely and FF will ignore the CN if there is a SAN).

I also considered making the ignoreCommonName an enum instead like:

public enum CertificateMatchOptions {
    SubjectAlternativeNameOnly,
    SubjectAlternativeNameOrCommonName,
    SubjectAlternativeNameFallbackToCommonName
}

So that we can offer more flexibility there, but:

specifying a lot of flags may not be what anyone wants,

Is something I agree with as well.

[bartonjs]

The substance of this request is fulfilled in the API proposal in #22699 (X509Certificate2.MatchesHostname)