On Mon, 19 Jan 2004, Peter Sylvester wrote:

> Hm, the actual code in curl was "almost" good.
>
> - check, whether there is a match in any of the subjetaltnames,
> - if no match found, check whether commonname, it happens just
> the the openssl routine to 'lookup' an entry does not give the
> most specific, but the least specific one.

I'm sorry, but I feel I need to ask a few more questions to fully grasp this!
My general x.509 cluelessness might show through here! Also, I'm a bit curious
on why this hasn't been revealed/fixed before...

Can you tell me a site/certificate that shows this issue in real life?

Further, what does "most specific" and "least specific" mean in this context?
In the stunnel.pem certificate you use two Common Names, but both of them are
valid names for the server, aren't they?

What could be a reason to include two names (or more) if only one of them is
ever checked/verified/used by connecting clients?

Allow me to quote from a section on the stunnel.org site regarding the use of
several Common Name fields in certificates
(http://www.stunnel.org/examples/mult_cannonical.html by Victor Danilchenko):

  There are two major styles: canonical Netscape implementation
  using globbing expressions (for more gory details, see
  http://home.netscape.com/eng/security/ssl_2.0_certificate.html), which
  uses only one CN field but permits multiple values to be specified in it
  using wildcards and various other techniques; and MS-style
  implementation, which uses multiple fields without globbing.

... now, I'm not in a position where I can judge if this the correct way or
not, but I think this expresses my concern.

(There are also lots of sites that say that you should use multiple
certificates if you need multiple common names, like this one:
http://www.verisign.com/products/onsite/ssl/balancing.html)

> The 'little bit) more interesting case is to use

> j =
> ASN1_STRING_to_UTF8(&peer_CN,X509_NAME_ENTRY_get_data(X509_NAME_get_entry(name,i)))
> ;
>
> to get the value, since it converts from all kinds of string
> representations, in particular BMPstring (two octets). i have seen wild card
> common names with BMPstrings.

Yes, this is no doubt a very good fix as the current use of
X509_NAME_get_text_by_NID() might return data that won't match just because of
its formatting.

> > Is that IP address then stored as a string or as binary like the
> > subjectAltName field does it? If it is a plain string, we don't have do to
> > anything different...
>
> A string liek: "127.0.0.1", one would ned the same logic for parsing as with
> ip addresses in URLs.

Currently, it will work if the site has the IP address in the Common Name
field (as a string) and you access the site using IP adress in the URL field
to curl.

-- 
    Daniel Stenberg -- http://curl.haxx.se/ -- http://daniel.haxx.se/
   [[ Do not send mails to this email address. They won't reach me. ]]
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn