curl-library
Re: SSL certificates
Date: Wed, 13 Nov 2002 10:13:58 +1100
On Wed, 13 Nov 2002 05:00 am, Philippe Raoult wrote:
> Indeed it's the same issue. I already have a patch but I'm waiting for
> Cris's answer about the protocol before submitting it to the list.
I've only had time for a little research so far,so I'd suggest the following:
* It's safe enough to go ahead and do a patch for wildcard certificates
("*.example.com") - they're fairly well understood (even if not 100%
standard) and are available from some CA's (like Thawte).
* To be safe, it should be a real 'domain level' match:
foo.example.com == *.example.com
foo.bar.example.com != *.example.com
foo.example.com.au != *.example.com # important!
* To be fully 'conformant', there's this wrinkle:
foo.example.com == f*.example.com
bar.example.com != f*.example.com
foo.bar.example.com != f*.example.com
These rules are as specified in RFC 2818 - 3.1 Server Identity (attached
below).
* Theoretically, we should also look at the subjectAltName(s) (in preference
to the CN) if available.
On the more thorny issue - many browsers I tried do accept a certificates for
a CN 'domain' that is above than the actual web site URL name (without any
wildcard symbols!):
foo.example.com == example.com
foo.bar.example.com == example.com
This seems inherently broken (like, why would you buy a $400 wildcard cert for
"*.example.com" when you could buy a $50 one for "example.com" and use it for
more hosts! I'd steer clear of this until we know what's going on.
I thought I found the code in mozilla which appears to implement this check (a
simple subroutine to do a name comparison), and it says "foo.example.com !=
example.com" (but does allow "foo.example.com==*.example.com"). This routine
also agrees with me that "foo.example.com != example.com", yet my running
mozilla does accept this for SSL. More digging needed.
Cris
--- RFC 2818 - 3.1 Server Identity 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. Matching is performed using the matching rules specified by [RFC2459]. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.) Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com. In some cases, the URI is specified as an IP address rather than a hostname. In this case, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP in the URI. If the hostname does not match the identity in the certificate, user oriented clients MUST either notify the user (clients MAY give the user the opportunity to continue with the connection in any case) or terminate the connection with a bad certificate error. Automated clients MUST log the error to an appropriate audit log (if available) and SHOULD terminate the connection (with a bad certificate error). Automated clients MAY provide a configuration setting that disables this check, but MUST provide a setting which enables it. ------------------------------------------------------- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd522.htmlReceived on 2002-11-13