On Thu, Jul 03, 2014 at 08:34:16PM +0200, Jakob Bohm wrote:
> >>For X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS:
> >>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.
>
> So without the bit, a certificate can specify that it applies to
> "*www.example.com" and match servers "onewww.example.com",
> "twowww.example.com" etc. but not "onepay.example.com", while with
> the bit, the only acceptable certificates are those issued to
> exactly "*.example.com" or each of "onewww.example.com" and
> "twowww.example.com"
>
> Did I get that right?
Yes, with the "or each of" cases matching only the corresponding
reference identity specified by the caller.
> >>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.
>
> So you mean if ".example.com" is passed as the "hostname to match"
> argument to X509_VERIFY_PARAM_set1_host() or X509_check_host(), then
> it will accept any certificate issued to www.example.com,
> mail.example.com, internal.mail.example.com, *.example.com or
> *.mail.example.com, as just a few examples?
Yes.
> By the way does ".example.com" also match the bare "example.com"?
No, it does not. However, once can call X509_check_host() multiple
times with different arguments. On the "master" branch, one can also
specify multiple names via X509_VERIFY_PARAM_set1_host() and
X509_VERIFY_PARAM_add1_host().
> >Applications that process EV certs can disable wildcards in name checks
> >via the appropriate flag.
>
> The common case is that an application accepts both EV and non-EV certs
> during the TLS (etc.) handshake, then informs the user (via a color or
> icon) if the negotiated cert is EV or not.
The EV CAs have been strong-armed against their will to not sell
wildcard certs, so the application need not bother disabling
wildcards for this case.
> Thus to be a meaningful audited replacement for each application coding
> its own certificate verification logic, the API introduced in OpenSSL
> needs to handle that scenario, since it is the most common case.
I am not convinced this is worth the effort. What would be more useful
is a property one can query that returns the name that matched. I'll
probably add that when I get a chance.
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
