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.html