> > > +# server certificate where SAN contains in-label wildcards which are > > > allowed by > > > +# RFC 6125 > > > > It is worth noting that per the RFC, a client MAY allow in-label > > wildcards (this is not a MUST or even a SHOULD). Additionally, > > various software does not allow or support this (for example, libtls > > and hence ftp(1)).
The purpose of this test is not to check a hostname against the in-label wildcard SAN. It is instead to show that the whole certificate is treated as invalid simply by having an in-label wildcard SAN, no matter if this specific SAN would actually be used to verify a hostname. This is in my opinion the wrong behavior. From my understanding the verification should succeed if there is a SAN matching the hostname. Any SAN which does not match the hostname should be ignored. I'm comfortable with having a strict hostname check which disallows partial wildcards. I'm not comfortable with treating the whole certificate invalid just because it has a partial wildcard in a SAN which gets not actually used. SAN are not specific to TLS but are a general property of certificates. Which SAN are allowed in a certificate should therefore follow RFC 5280 section "4.2.1.6. Subject Alternative Name". It should not be based on which algorithm will be used for hostname validation in the context of TLS. Regards, Steffen
