Server Verification of Own Certificates / CN/SAN Exposure on Certificates

[tdotclare]

Currently, the .commonName & .subjectAlternativeNames methods on NIOSSLCertificate are internal only, which prevents their use for verifying a provided certificate is "valid" in the sense of matching expected responding hostname(s) for a server.

I realize making those methods more robust for public use may beyond the scope of what NIOSSL should handle, but it would be nice if there was some sort of convenience when initializing a TLSConfiguration for server use that verifies the provided certificate chain will correctly map to specified, expected server names.

EG, something like

Extension TLSConfiguration {
    public func validFor(serverNames: [String]) -> [String] {
        // Takes an array of DNS names ["www.domain.com","admin.domain.com", etc]
        // and checks if cn/san of certificate chain adequately present those names,
        // returning either an empty array if all provided serverNames are matched
        // by the chain, or a non-empty array of non-representable serverNames
    }

[Lukasa]

The CN/SAN methods aren't exposed because NIOSSL is aggressively refusing to be a general-purpose crypto library, and that includes X.509 😉 I'm also reluctant to expose the CN/SAN fields because of the risk that someone will badly reinvent the IdentityVerification code we painstakingly wrote.

In general, we can definitely validate that they're ok, but there is some difficulty in determining what this interface should look like. For example: should we be validating that we can construct a valid cert chain too? Should we be checking expiry dates? Basic constraints? How much validation should we do on a cert before we allow you to load it into your server process?

Some of this is not even really possible to do in a way that makes sense: whether your server can construct a valid cert chain for your leaf certificate is in some ways entirely unrelated to whether or not a client can. It'd also surprise you to have to install your root CAs in the NIOSSL process in order to serve a leaf cert.

Because of that ambiguity I'm disinclined to make TLSConfiguration do this. We could do something on NIOSSLCertificate though, maybe subjectAlternativeNamesCoverHostname which does a good job of clearly communicating the scope of the validation.