Not yet, because Let's Encrypt doesn't provide wildcard certificates as of now. This may change in the near future, though.
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.
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.
An 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].
If 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").
I 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.
It 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.
It'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.
If 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.
The best part is, the cert you use to log in to your account itself expires after a year. So if you don't renew it in time you lose the ability to log in and issue a new certificate for your site, right at around the time your site's certificate expires.
They specifically tell you that you need to back up your login-cert or you will lose access.
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.
The rest of the connected world has determined that username and password, supplemented by OTP methods or some other multifactor authentication, is enough.
Having a login cert is fine if the "user" is an organisation. It is a broken model for individuals or small businesses.
Well, Let's Encrypt models is based on automated confirmation of domain ownership (or to be more accurate, control rather than ownership). Automated software proves that the entity who is asking for a cert for a.example.com really does have control over a.example.com, because they were able to make a change on the host that a.example.com refers to. And based on this, issues the cert to the entity.
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.
Wouldn't they just need to verify control of the domain, instead of a single host on the domain? If I control example.com, it's fair to believe I can control all hosts on the domain.
How do you verify control of a domain? Their current mechanisms verify control of a _host_ pointed to by a hostname, not of a domain. They'd need different mechanisms to verify control of a domain.
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.
You could verify ownership of the DNS config for the domain. It's not all that uncommon to verify ownership of a domain for various services by sticking something in a TXT record on that domain (or on a specially-named subdomain). LetsEncrypt could do something similar to verify top-level ownership. After all, if I have control over the DNS zone, then I trivially have control of any host on the domain too (just point the DNS at my own server).
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 used to use them. You have to set up an account with a client certificate, which is a pain, then be manually approved. The free certs are for personal use only so they will deny you if they think you will be using it for business of any sort.
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.