Hacker News Reader

I agree that wildcards aren't great if they're being passed around an organization to avoid registering a few extra certs, but they are very useful in a few circumstances such as sandstorm.io: every app session uses a different subdomain to prevent cookie leakage, and registering that many certs would overwhelm LE. I'd imagine there are other cases out there involving automatically created subdomains that will benefit.

Like I said. There are uses for wildcard certs I'm just arguing against the fact they're used en masse. People should be perfectly aware of the ramifications and sandbox appropriately. (*.tennant.sandstorm.io or whatever.)

Everyone keeps saying SaaS is the reason for the use of wildcard certs and I would absolutely argue the point that multi-tennancies weakest tenet is the fact that if you get compromised the scale can be broad. Why intentionally weaken that system? LE can handle thousands of domain creations a minute, they've been very forthcoming with lifting limits for people on domain creation.

The downside is your server sites which need a little overhead for vhost creation but that could be automated with less than a day of ops work.

I believe a while ago the sandstorm people spoke to LE who advised that it wasn't a good idea.

I'll stand by the assertion that vhosts are probably still better off with a wildcard cert if it's the difference between a single server using a single cert vs a single server holding thousands of certs. In a node compromise it's the same either way. If different servers are serving different subdomains then sure, subdomain certs are the better way to go.

Storing that many certificates is a total waste of engineering. (On both LE's and the SaaS's side.)

I'll probably finally self-host Sandstorm once I can get a wildcart cert from Let's Encrypt.

Was this the main issue stopping you? Wildcard certs are only 45 USD per year.

$45 a year from who? I didn't see anything that cheap from anywhere mildly reputable. And yeah, main reason.

AlphaSSL, Google $42 wildcard

Garrison host, ssl2buy

There are legitimate use cases: for instance, a multi-tenant app that designates tenant by subdomain.

Couldn't you have a cert per sub domain? If you're using Let's encrypt, you almost certainly have automated renewal in place, so you could allocate a cert when you give them a subdomain

You can only put 100 domains on a Let's Encrypt cert, so if you're a site like Tumblr that's going to be a whole bunch (hundreds of thousands or millions of certs) of mayhem.

You can contact Let's Encrypt to get those limits lifted I believe?

That's not going to help.

Every time someone adds a domain to Tumblr, they'd have to re-do the certbot challenges for all 50 MILLION domains.

Plus, all 50 million domains are listed IN the certificate. It'd be megabytes worth of additional data for every visitor to Tumblr.

*.tumblr.com makes a lot more sense.

I agree with the case for using a wildcard, but just to play devil's advocate - why can't they take the CloudFlare approach?

Generate a cert for 100 of your client's domains, use that cert across those domains. Cut your 50m domains down to 500,000 certificates. Serving the right certificate for the right domain is a simple enough task.

As new tumblr domains are registered, generate more certs in batches of 100 domains.

I doubt anyone would ever seriously suggest putting millions of SANs on a single certificate, but 100 isn't too farfetched.

This seems to be how wordpress.com does it.

They appear to have a wildcard for the *.wordpress.com subdomains, though.

Absolutely. I use a wildcard for this and doing a cert for each sub would just be a lot of hassle and potential for things to go wrong with no security benefit.

I use kubernetes-lego for this and it's all automatic, zero hassle.

That is a good solution for kube thanks for the reference.

My situation is a bit different: hosting a bunch of subs on the same servers.

With one wildcard I have one server conf with one cert and use the hostname to rewrite each request to the correct directory.

If I did a cert for each sub the nginx conf would need 1000's of server config blocks each with its own cert. I haven't tested, so maybe nginx would handle this just fine, but it is easier to just go with a single wildcard and not worry about it.

As far as I can tell there is no security advantage to having multiple certs instead of one wildcard since I would have all the certs on the same server anyway but if anyone knows of any I would be happy to hear.

I would argue that they're useful but not mandatory. Is having separate certs really that big of a deal? Operational overhead with LE is next to none and if you're scared of hitting limits you can contact LE to have the limits increased.

Requesting a new certificate per user is another step that can go wrong, and contacting LE for limit increases is a barrier.

Isn't it less of a barrier than cert creation pre-LE? and you do it once.

Pre-LE you'd use an other authority that provided wildcard certificates. That's what they're for after all, why would you want to hack your way around them?

For the cases you mention, I mostly agree. Wildcard certs are critical for many SaaS use cases though, where you need a cert for each customer on a product domain: company1.example.com, company2.example.com, etc.

I would argue that they're useful but not mandatory.

Is having separate certs really that big of a deal? Operational overhead with LE is next to none and if you're scared of hitting limits you can contact LE to have the limits increased.

I don't think it's fair to say the operational overhead would be next to none. As it stands right now, most services that use per-user subdomains get wildcard certificates. Let's assume that wouldn't be an option for a service like tumblr, which has per-user subdomains. They have ~350 million users, that's not really practical to maintain. And that's just one big site, there are plenty of others. This would not just overwhelm the issuance capacity of most CAs, but it would also be a problem for many other components of the Web PKI, like Certificate Transparency log servers, which have so far only needed to handle a total of ~450 million certificates (many of which are duplicates that have been logged to multiple servers).

There's certainly a place for wildcard certificates, but I definitely agree that they should be used sparingly.

This is great advice, and, honestly, an issue I had not given enough thought. So, thanks.

I've often (always?) fallen into the trap of "Let's just use a wildcard. Setting these things up is a pain in the ass!"

This is definitely true, and single-domain or SAN certificates should continue to be the first option administrators consider when deploying TLS. Wildcards make sense for things where the number of subdomains is unmanageable and where each of those subdomains share the same attack vector (i.e. are handled by the same load balancer, etc.)

The fact that validation for wildcard certificates is limited to the DNS challenge will hopefully ensure that most users will continue to use non-wildcards, as the other challenges are significantly easier to automate.

But wildcards are useful when you have 2 or three front-end load balancers. They are only replicated twice, which is reasonable IMHO.

A big part of that was cost. A wildcard certificate can be used to lower costs if a company has hundreds of sub-domains.

But now, with the full LE offer of services, cost is no longer an issue, and all you mention should be easily automated via scripts.

For those concerned with others in their organization obtaining/using wildcards unsafely: set a CAA record prohibiting wildcard issuance from any CA and be done with it.