[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: patch SSL certificate warning

From: Malcolm Rowe <malcolm-svn-dev_at_farside.org.uk>
Date: 2007-09-07 00:57:23 CEST

On Fri, Sep 07, 2007 at 09:35:32AM +1200, Matt Bodley wrote:
> It is widely accepted that *.domain.com means xxx.domain.com, but not so
> clear that this also means yyy.xxx.domain.com, but in my view, this is the
> same as it follows DNS delegation in both instances (of the implied/inherent
> trust that is dictated by DNS).

RFC 2595 (which deals with TLS for IMAP and POP3, and was, I believe one
of the first RFCs to deal with wildcards) simply reads (in 2.4):

     - A "*" wildcard character MAY be used as the left-most name
     component in the certificate. For example, *.example.com would
     match a.example.com, foo.example.com, etc. but would not match

So that's not clear either way. RFC 2818 (which deals with TLS for
HTTP) reads (in 3.1):

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

Which is pretty clear as _not_ allowing this behaviour. I understand
that RFC 4513 also mandates this approach for LDAP.

It also appears that the current Firefox behaviour is considered a bug:

So, while it _might_ arguably make things more complex to keep with the
current behaviour (but perhaps no more than the widely-understood case
where a certificate for *.example.com doesn't match http://example.com),
it seems like it would be a mistake to make a change away from the
current RFC-compliant behaviour.


  • application/pgp-signature attachment: stored
Received on Fri Sep 7 00:54:17 2007

This is an archived mail posted to the Subversion Dev mailing list.