On Thu, Feb 16, 2023 at 02:19:52PM -0500, Pierre-Luc Boily wrote: > Yep, I read the documentation. The part "*suppresses support for "*" as > wildcard pattern in labels* " sounds really like that wildcard is not > accepted at all. But I have to admit that I don't know what a "label" is. A label is a single component of a DNS name, which (in presentation form) is a sequence of "." separated labels. > With this flag, only "www.feistyduck.com" and "feistyduck.com" are accepted, No, not only those, also, for example, "ftp.feistyduck.com", "smtp.feistyduck.com", "xyzzy.feistyduck.com", ... are accepted, because they match "*.feistyduck.com". > it seems useless to me to specify "*.feistyduck.com" in the SAN. Not useless, but not recommended. Wildcard and multi-name certificates degrade security. Use a separate hostname for each protected service, and put just one name in the certificate. > Why not just use "www.feistyduck.com" That would be the best choice for a certificate for the web service. But if browsers expect to use either "www.feistyduck.com" or just "feistyduck.com", that'd be one case where both names in the same certificate are OK, provided you don't also use "feistyduck.com" for non-HTTP services, or understand and accept the risk of potential cross-service security issues. > If I understand correctly, if i want a more open certificate that > accept my subdomain, I should use X509_CHECK_FLAG_MULTI_LABEL_WILDCARDS > but then allowing multi-label wildcards can increase the risk of > attack I guess. That flag is not recommended, it goes against standard practice and the issuance policies of public CAs that don't expect the certificates to apply to hosts in subdomains. It could be applicable in closed networks, where clients connect to only a limited set of hosts and trust only CAs that issue certificates knowing that wildcards could be interpreted in a non-standard way. -- Viktor.