On Thu, Jul 03, 2014 at 12:35:23AM -0400, Jeffrey Walton wrote:
>
> I guess what I am asking: what is the default behavior. Its not clear
> from the basic description.
For each flag bit, the opposite behaviour to that obtained by
setting the bit is the default when the bit is zero.
> *****
> For X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS:
>
> If set, X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS suppresses support
> for ``*'' as wildcard pattern in labels that have a prefix or
> suffix, such as: ``www*''
> or ``*www''; this only aplies to X509_check_host.
>
> Is that the "leftmost" rule? I.e., a wildcard must be at the leftmost label?
>
No, it is exactly what is described. When the bit is clear such partial
wildcards are allowed.
> What is the purpose of allowing a leading dot for a hostname? I.e.,
> why is ".example.com" allowed?
It allows the verifier to specify a parent domain, rather than a
particular host. Any host in that domain or sub-domain matches.
> A leading dot does not appear to be a valid hostname nor a well formed
> FQDN. I don't recall reading about it in the RFCs or the CA/B Forums
> (RFCs 5280, 6125 or CA/B Baseline Requirements). I would expect a
> certificate with it to be rejected as malformed.
This name is NOT in the certificate. It is a fuzzy reference identity.
> Is there an intersection with EV OIDs? Or is it out of scope for host
> name matching?
EV is about whether the certificate is trusted by browsers. It
has nothing to do with namechecks.
> According to the CA/B EV Guide, wildcards are not
> allowed in EV certificates. So I would expect a wilcarded cert to be
> rejected as malformed if its an EV certificate.
Applications that process EV certs can disable wildcards in name checks
via the appropriate flag.
> Would it be possible to receive the reason for a failure? For example,
> I would consider a DNS name in the CN as a soft failure that I could
> recover from (both the RFC and CA/B Forums have deprecated the
> practice, but its still frequently encountered). But a wildcard match
> with trickery, such as a DNS name of "*.com", would be a hard failure
> that I would not attempt to recover from.
The specified reference identity either matches or not.
> As another example, Java will fail a cert for overlapping DNS names in
> Subject Alt Names of a certificate, like having both "*.com" and
> "www.*.com" or having both "*.com" and "example.com"
Don't trust CAs that generate malformed certs. OpenSSL does not
support "*.com", there must be at least two labels after the
wildcard. OpenSSL does not support "www.*.com.au", the wildcard
must be in the left-most label.
> So maybe something like the following, where `reason` is an optional
> bitmask that is valid *if* the function fails.
>
> int X509_check_host(X509 *, const unsigned char *name,
> size_t namelen, unsigned int flags, int* reason);
This is too complex an interface. You specify how matching is to
be done, and then it either works or does not. Keep in mind that
you should not explicitly use X509_check_host() if at all possible.
Instead use X509_VERIFY_PARAM_set1_host(), then name checks are
performed as needed. The verify callback is called with an error status
if the fail.
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
