Re: X509_CHECK_FLAG_SINGLE_LABEL_SUBDOMAINS
On Tue, Apr 19, 2022 at 10:07:15PM -0400, Viktor Dukhovni wrote: > 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? Note that paragraph three of the DESCRIPTION reads: When name [bold font] starts with a dot (e.g. ".example.com"), it will be matched by a certificate valid for any sub-domain of name, (see also X509_CHECK_FLAG_SINGLE_LABEL_SUBDOMAINS below). where it should ideally be clear that we're talking about the peer name specified by the application (reference identifier in terms of RFC 6125), not a DNS-ID in the certificate (presented identifier). -- Viktor.
Re: X509_CHECK_FLAG_SINGLE_LABEL_SUBDOMAINS
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.
X509_CHECK_FLAG_SINGLE_LABEL_SUBDOMAINS
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? Is there any way to turn it off totally while still allowing * type wildcards? -- These are my opinions. I hate spam.