The patch doesn't seem to support wildcards in alternative names. Is that on purpose?
Not really, we just did not have any use case for them, but it seems that RFC 5280 does not disallow them:
" Finally, the semantics of subject alternative names that include
wildcard characters (e.g., as a placeholder for a set of names) are
not addressed by this specification. Applications with specific
requirements MAY use such names, but they must define the semantics."
I've added support for them in the next iteration of the patch attached to this email.
It would be good to add a little helper function that does the NULL-check, straight comparison, and wildcard check, for a single name. And then use that for the Common Name and all the Alternatives. That'll ensure that all the same rules apply whether the name is the Common Name or an Alternative (assuming that the rules are supposed to be the same; I don't know if that's true).
Thanks, common code has been moved into a separate new function.
Another question is how should we treat the certificates with no CN and non-empty SAN?
Current code just bails out right after finding no CN section present , but the RFC (5280) says:
"
Further, if the only subject identity included in the certificate is
an alternative name form (e.g., an electronic mail address), then the
subject distinguished name MUST be empty (an empty sequence), and the
subjectAltName extension MUST be present.
"
which to me sounds like the possibility of coming across such certificates in the wild, although I personally see little use in them.
