mailing list archives
SSL certificate verification: "most specific"
From: David Fifield <david () bamsoftware com>
Date: Sat, 14 Nov 2009 15:39:28 -0700
I just committed some new code and tests for Ncat SSL certificate
verification. The code had been lax with respect to this paragraph from
If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated
and Certification Authorities are encouraged to use the dNSName
Ncat used to check the Common Name even if there were dNSNames and none
of them matched, and it would match against the first Common Name that
appeared in the certificate, not the "most specific" one. These are now
The "most specific" terminology is a problem. It's used in several
standards, but I haven't been able to find a definition of it anywhere.
I implemented code that follows this definition, which I think is
Wildcard patterns are always less specific than non-wildcard
patterns. If both patterns are wildcard or both are non-wildcard,
the one with more name components is more specific. If two names
have the same number of components, the one that comes later in the
certificate is more specific.
The reason later patterns are preferred is that I remember reading
somewhere that names are supposed to be arranged in order of increasing
specificity, but I can't remember where I saw that.
Here's an example from the test program. If a certificate contains these
Common Names in this order,
they would be, from most specific to least specific,
Comments on this are welcome.
It should be noted that RFC 2818 is not the only place that defines how
the data in a certificate are to be interpreted. For instance, some
protocols disallow wildcards entirely. I believe this behavior is mostly
correct for HTTPS, but it won't be for all protocols. By "mostly
correct" here I mean it's correct in every respect except where we have
chosen to be more strict.
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/
- SSL certificate verification: "most specific" David Fifield (Nov 14)