Nmap Development mailing list archives
SSL certificate verification: "most specific"
From: David Fifield <david () bamsoftware com>
Date: Sat, 14 Nov 2009 15:39:28 -0700
Hi, I just committed some new code and tests for Ncat SSL certificate verification. The code had been lax with respect to this paragraph from RFC 2818: 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 instead. 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 both fixed. 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 reasonable: 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, a.com *.b.com sub.c.com sub.d.com *.sub.e.com *.sub.f.com sub.sub.g.com they would be, from most specific to least specific, sub.sub.g.com sub.d.com sub.c.com a.com *.sub.f.com *.sub.e.com *.b.com 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. David Fifield _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- SSL certificate verification: "most specific" David Fifield (Nov 14)