X509 certificates can be easily found by target hostname #59870
Description
Given an X509Certificate2Collection and a host identifier, it should be easy to find certificates that would match that hostname under the TLS host matching rules.
There are a different aspects or interpretations to this problem:
- Should the matching include wildcard evaluation? (Probably yes)
- Should the matching consider name constraints by the CAs? (We probably need more tests here before we can have an informed opinion)
- Depending on how things are reported, maybe we need both a "using just this cert" fast interpretation and a "using the chain" slow interpretation.
- Should the matching include "the target looks like an IP Address, match
san/[@type=ipAddress]? ("Yes" if wildcard is yes, since that is matching what SslStream would do. "Probably yes" irrespective) - Should there be options for most of these things?
- Should there be an option for "only test in the SAN extension?" (with no Subject/CN fallback)?
- Should we make it easier to ask if a cert is valid for a purpose?
- Should that have an option of "require EKU"? (Yeah, probably, since things like RFC3161 claim enforcement of that)
- Should we make an accelerator for TLS-Server-purpose+this host?
- The original thought that prompted this was a new find type for X509Certificate2Collection.Find... so... maybe 😄.
sslServerOptions.ServerCertificateSelectionCallback =
(sender, hostName) => _cuMy.Certificates.First(c => c.IsValidForTls(hostName);Though that's possibly over-specialization on the instance. _cuMy.Certificates.Find(X509FindType.FindTlsServerCertificate, hostName, validOnly: whatever).First() might be more reasonable (note that both examples are bad in practice because of how much finalization they create)
This might just be the X509Certificate2::IsMatchForHostName from #28771 plus a similar X509Certificate2::IsValidForPurpose(oid, bool requireEku), and possibly the ease of use unifier as a collection Find option.