[ygjb-dupe]

>Perhaps reasonably priced wildcard and/or EV certs, while leaving regular certs at the "free" price level?

IDK, wildcard certs encourage really bad practices, and I don't see the LE team liking the idea of issuing them.

EV certs means a significant increase in costs to actually go through the processes required (audits, etc) so that browsers will accept them, and then the increased costs of doing due diligence when issuing certs. Unless they want to grow in that direction, it seems like a poor business choice.

Yes, it means they run the risk of going insolvent; despite the fanfare, and the pace at which they have moved themselves into a critical niche on the web, they are still an open source project, and are supported by sponsorships and donations.

I expect that there are some significant players that would invest to keep them around, but it can be hard to continue to making an impact when you subsist off of crumbs.

Anyone who's career depends on FOSS should at least read https://files.puzzling.org/wayback/pay-for-foss/

[nrook]

Could you elaborate on why wildcard certs are a bad idea? I've heard this from several sources, but I haven't read a breakdown of why people think this.

If I'm running a web application, and want to provide an interface where separate teams sign up and access their version of the app at team-name.your-app.com, what's the alternative? Or is it that this is considered unwise, and I should just put team-name in the URL path instead?

[zeta0134]

The primary issue with wildcard certificates is that it encourages certificate reuse between server environments. Even the act of transferring keys around carries a certain degree of risk. With a wildcard certificate though, say you have a very secure shopping site, and a user run forum:

  - https://checkout.example.com/
  - https://forums.example.com/

Your wildcard certificate for * .example.com covers both domains, and can be shared between both servers. Nice! You've saved a bundle of money on certificates. But there's now a security risk: Say an attacker manages to compromise forums.example.com through some vulnerability in the forum software, and steals the private key for * .example.com. They can now set up their own server hosting checkout.example.com, successfully execute a Man in the Middle attack, and steal sensitive customer data without the end user being any the wiser.

Issuing separate certificates prevents this scenario by enforcing a separation of responsibilities. If each server has its own set of keys, then a security compromise on forums.example.com does not spill over to checkout.example.com, because the key used on one server is useless to impersonate the other. Obviously a key compromise at all is a bad situation, but you want to architecture your environment so that a compromise has the least potential to do damage, and that's the basic argument against wildcard certificates.

[sk5t]

Good writeup. In addition, using discrete certificates makes managing them easier, whether for renewal, squashing SHA-1 and the like, or revocation. It can be a big headache to track down all the places a wildcard cert worms its way into at large, penny-pinching orgs.

[sk5t]

FYI, it is possible to run multiple certificates on one IP+port if your SSL clients support SNI. Nowadays that's not too crazy an assumption, and creating on-demand certs is doable; integrating this with your service and managing renewal might be a pretty advanced task though.

In other words, a web app with custom subdomains is probably a reasonable use case for wildcart certs, for now.