Also note that free single domain certificates have been available from StartSSL for a very long time, but this didn't destroy the certificate industry.
Also note that free single domain certificates have been available from StartSSL for a very long time, but this didn't destroy the certificate industry.
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.
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.
Given the occasional implementation weakness, and key recoveries, I would much rather bind only one key to a name.
[1] https://sandstorm.io [2] https://docs.sandstorm.io/en/latest/using/security-practices...
There are a few existing Nginx configs for that (search for "nginx dynamic ssl cert").
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.
One year passed, and I checked my backups. Yup, there it was.
If you take security seriously, you should actually read what's on the page instead of clicking "next, next, next" like some driveby malware-installing Windows-installer. And then this shouldn't be an issue.
I guess this is StartSSL's way of not having to deal with people who don't take security as seriously as they do.
StartSSL doesn't take security serious. They'll happily accept breaches to their terms of use, as long as you pay up.
Having a login cert is fine if the "user" is an organisation. It is a broken model for individuals or small businesses.
This level of proof of control is standard for DV certs, although other providers haven't automated it to the extent Let's Encrypt has, at least not with as high-quality software. One hole in this verification of course, is that 'control' may not actually be 'ownership', it could be someone who's hacked the host or DNS. But that's not unique to Let's Encrypt, it's a side issue, proof of control is standard and accepted for verification for DV certs.
So anyway, that kind of automated proof of control is a lot harder to apply to all of *.example.com, not just an individual host a.example.com. There are likely ways to do it well, but it's harder to do and harder to get right. Is probably why Let's Encrypt, at least for now, is not doing it.
If you control the domain `example.com`, sure. if you just control the single host that `example.com` points to, that doesn't neccesarily mean you control the domain, and in fact DNS contortions are needed to even have example.com point to a host.
Another benefit of this is ownership can be validated on an ongoing basis (is the TXT record still there? yup, still valid) without requiring any software to be running on any hosts at that domain. And you can validate a domain without even having an A record if you want (say, if you're getting all your ducks in a row before exposing your server to the world).
I ended up paying $10 on namecheap instead.
At least it used to work like that.