Open tdotclare opened 4 years ago
The CN/SAN methods aren't exposed because NIOSSL is aggressively refusing to be a general-purpose crypto library, and that includes X.509 :wink: 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.
Currently, the
.commonName
&.subjectAlternativeNames
methods onNIOSSLCertificate
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