4 ms·
An argument can be made that Let's Encrypt doesn't need wildcard certificates since new certs can be generated automatically every time a subdomain is added.
by mastax 11y ago
An argument can be made that Let's Encrypt doesn't need wildcard certificates since new certs can be generated automatically every time a subdomain is added.
- toomuchtodo 11y agoTrue! But wildcards make cert management so much easier. If I have a handful of subdomains, that's fine. If I have thousands, I want a wildcard cert.
- chipperyman573 11y agoIt would be relatively easy to write a simple bash script to automate it. Granted, it might take a bit of time to generate a few thousand certs, but it wouldn't take more than a day if you only have a thousand or so.
- dingaling 11y agoIt's not just creating the certs that is the challenge but also managing them; back-up, revocation, re-testing after expiry and across different development environments etc And from the client perspective is makes pinning much easier. I'm not a fan of one-wildcard-to-rule-them either but keeping active certs to a handful through the judicious use of wildcards is a real boon.
- Natanael_L 11y agoIf you use the Cloudflare style delegation of SSL authentication signing to a trusted auth server, it can be simplified. The individual servers only holds the public cert and a private internal secret, one server holds your certificate private keys. That server would be used to keep track of your domains and certificate status and which servers are authorized to work with which domains, etc... Also easier to backup.
- vetrom 11y agoArguably though wildcard certs are a bad hack on security, as it binds multiple distinct endpoints to a given keypair. Given the occasional implementation weakness, and key recoveries, I would much rather bind only one key to a name.
- robryk 11y agoAn interesting usecase of wildcard certs: when I do not want to publish the hostnames I am using. Sandstorm[1] uses unpredictable hostnames as one mitigation against various cross-origin attacks -- if the attacker doesn't know the domain of the app, he can't try to use XSRF against it[2]. [1] https://sandstorm.io https://sandstorm.io [2] https://docs.sandstorm.io/en/latest/using/security-practices/#client-sandboxing https://docs.sandstorm.io/en/latest/using/security-practices...
- icebraining 11y agoIf you are willing to only accept SNI enabled clients (the vast majority nowadays), you can achieve the same by having one cert issued per subdomain, then configuring the web server/reverse proxy to use them. There are a few existing Nginx configs for that (search for "nginx dynamic ssl cert").
- schoen 11y agoI think there are other problems for doing this for Sandstorm. One is the delay when starting to use a new hostname (right now Let's Encrypt might take around 20 seconds to issue a new hostname, which may well increase to the originally-predicted one minute eventually), while another is that all Let's Encrypt certificates are published, so if you really want the hostname to be completely unknown to an attacker, the individual Let's Encrypt certs wouldn't work. Anyway, Sandstorm developers told me that they wouldn't plan on using Let's Encrypt while it doesn't offer wildcards, so I think we are missing out on supporting this use case.
- robryk 11y agoCerts are published in certificate transparency logs, which would make the hostnames public.
- discreditable 11y agoAny level of reliance on hostnames being secret seems like a very poor design decision.