On Tue, Apr 19, 2022 at 03:25:03PM -0700, Hal Murray wrote:
> man X509_check_host says:
>If set, X509_CHECK_FLAG_SINGLE_LABEL_SUBDOMAINS restricts name values
>which start with ".", that would otherwise match any sub-domain in the
>peer certificate, to only match direct child sub-domains. Thus, for
>instance, with this flag set a name of ".example.com" would match a
>peer certificate with a DNS name of "www.example.com", but would not
>match a peer certificate with a DNS name of "www.sub.example.com"; this
>flag only applies to X509_check_host.
>
> I haven't see the idea of ".example.com" being special in any of the RFCs
> I've
> been looking at. Can somebody give me a lesson in this area?
You perhaps did not notice that this describes syntax in "reference
identifiers" (arguments to SSL_set1_host(3), ...), rather "presented
identifiers" (contents of the peer certificate).
As such these a local matter (API detail) that lies outside any RFC.
A verifier than asks for a specific hostname is not affected by this
feature. But a verifier that asks OpenSSL to verify ".example.com"
against a certificate is specifying a "fuzzy" match.
> Is there any way to turn it off totally while still allowing * type wildcards?
This is an apples/oranges dichotomy. "*" wildcards are "presented
identifiers" in the certificate.
If the documentation is not sufficiently clear (too subtle) on this
point, would you like to suggest some text to clarify the documentation?
A pull request?
--
Viktor.
