https://docs.sandstorm.io/en/latest/administering/wildcard/#...

Sandstorm is a platform for personal computing; each person runs their own applications, much like in a PC. Also, applications don't get hostnames; each document (or equivalent) in the application gets its own hostname.

But Sandstorm is designed for sharing and collaboration. For example, you might write a document in Etherpad which you want other people to comment on. It may be tough to get the right certificate into all your friends' and family's browsers.

(Note that Sandstorm actually provides free wildcard certificates if you are OK with using a subdomain of sandcats.io.)

[1]: https://tools.ietf.org/html/rfc6125#section-7.2

Unless something has changed, I could also get bankofamerica.com.banking.io, from LE or many other CAs. The wildcard issue has no effect on this situation.

Tldr: one verification limits another use, while another verification might expose domains that shouldnt be.

I can, today, get a valid certificate for myname.github.io (getting GitHub to serve it is a different issue, but from an MITM, proof of ownership, and CA/Browser Forum standpoint, it's properly assigned.) That's not surprising or weird, and it's exactly how it's supposed to work.

A certificate for myname.github.io does not give me a valid certificate for someone-else.github.io or github.io. Similarly, a certificate for '* .myname.github.io', which can also be procured today from dozens of CAs, doesn't cause panic or change the situation at all. I just can't get it from LetsEncrypt.

If I can only prove control of 'cs.mit.edu', I can get a certificate for '* .cs.mit.edu', but not all of 'mit.edu'. If I can prove ownership of 'mit.edu', I can get a certificate that covers '* .mit.edu'. This is how it should and has always worked. It just doesn't work via LetsEncrypt.

Basically, heavier authority moves right, never left, in wildcard certificates.

(Edit: HN eating asterisks)

I understand that other CA's provide wildcard certs, but frankly I see them as a giant problem. It's bad enough that I only have to have something listening on port 80 to prove that I control a domain. Let's not make it more attractive for people to start fooling Let's Encrypt into getting certs for domains they don't control.

> The CA MUST establish and follow a documented procedure that determines if the wildcard character occurs in the first label position to the left of a "registry-controlled" label or "public suffix" (e.g. "* .com", "* .co.uk", see RFC 6454 Section 8.2 for further explanation).

This basically means that the CA should check the Public Suffix List before they issue a wildcard.

As a 'just in case' measure, most modern browsers also reject certs where the wildcard is directly below something on the PSL.

(sorry for the spaces after the asterisks, HN seemed to like converting big chunks of the post to italics)

The Public Suffix list is an imperfect maintained list. You're relying on Mozilla to maintain it. You also never know if someone is selling names below their own zone. What if Mozilla decides to no longer maintain it? What if the volunteers stop maintaining it?

Maybe the PSL is a good start, but I would rather not rely on it. It's a convenience vs. security balance issue, and I'm leaning towards security.

This argument hasn't been made, or hinted at, by anyone, anywhere in this thread. And $50 isn't the difference between that being possible or not.

> A server MAY consider a client authorized for a wildcard domain if it is authorized for the underlying domain name (without the “*” label).

Although this seems to be gone from https://ietf-wg-acme.github.io/acme/, which I think is the later version.