Opened 11 years ago

Last modified 5 years ago

#106 assigned defect

* certificate doesn't handle lockers with dots in their name

Reported by: geofft Owned by: geofft
Priority: major Milestone:
Component: web Keywords:


See, for instance, or

I'm not sure what the good options are here. We could

  • get a few levels of *.*.*.* as alternate subject names from our money-costing cert
  • get a few *.*.*.* certs from MIT, and do SNI
  • fix SSL upstream and wait for it to filter down into browsers in a few months

(Reported by adehnert.)

Change History (9)

comment:1 Changed 11 years ago by geofft

  • Summary changed from * doesn't handle lockers with dots in their name to * certificate doesn't handle lockers with dots in their name

comment:2 Changed 11 years ago by andersk

It turns out that none of those solutions work.

comment:3 Changed 11 years ago by geofft

Okay, how about

  • Amend the RFC (or even just the implementations) to support a cert for ** doing what we want? Or add support for an extra something field to say "This wildcard can cover multiple levels", so it remains a cert with subject name * for backwards-compatibility?
Last edited 5 years ago by andersk (previous) (diff)

comment:4 Changed 11 years ago by andersk

I think the RFC people will say that what we want is our own signed CA with a Name Constraints extension of “”. I bet it’s approximately impossible to buy such a signature from a “real” CA (though I haven’t looked very hard), but maybe we’d have better luck with the MIT CA?

comment:5 Changed 11 years ago by xavid

A less exciting solution would be to give something like to the 6.034 locker and suggest they use that for https.

comment:6 Changed 11 years ago by geofft

  • Owner set to geofft
  • sensitive set to 0
  • Status changed from new to assigned

I shot Eric Rescorla, the RFC's author, this e-mail:

> Hi Eric,
> I'm writing in regards to section 3.1 of RFC 2818, specifically:
> > Names may contain the wildcard
> > character * which is considered to match any single domain name
> > component or component fragment. E.g., * matches but
> > not f*.com matches but not
> I'm wondering what you would recommend for a certificate that would, in 
> fact, match as well as Options that occur to me 
> include a special extension in the certificate indicating that the 
> wildcard in * should be permitted to match multiple components, and 
> issuing a certificate for **
> Because of a lack of direction in RFC 2818, browsers and libraries don't 
> implement a way to let a wildcard certificate match multiple components, 
> and websites and CAs won't come up with a certificate that no browser 
> supports -- see <> 
> for a specific example of this problem.
> Rather than attempting to lobby for an arbitrary choice in my favorite 
> browsers, I'm curious if you have specific recommendations as the RFC 
> author, or if you're aware of other efforts or standards or drafts that 
> address this issue, so we have something on which to base 
> multiple-wildcard support in HTTPS.

Geoffrey Thomas

We'll see where it goes. One possible outcome is that he mentions that he doesn't know any solutions but thinks ** might work (it's analogous to, say, bash's syntax for globbing multiple directories), in which case I have something slightly stronger with which to lobby said favorite browsers. At that point we can get ** as a subjectAltName.

Last edited 5 years ago by andersk (previous) (diff)

comment:7 Changed 11 years ago by geofft

Eric replies, CC'ing IETF applications area director Peter Saint-Andre, who he claims is "working on more general guidance on such issues" and suggesting the *.*.scripts solution. I mentioned that we really want the option this ticket calls "fix SSL upstream", i.e., arbitrary levels, but that *.*.scripts would be a good start.

Last edited 5 years ago by andersk (previous) (diff)

comment:8 Changed 9 years ago by ezyang

  • Priority changed from normal to major


comment:9 Changed 9 years ago by andersk

See also #262 “Mangle locker names that are invalid hostnames and MySQL usernames”.

Note: See TracTickets for help on using tickets.