FYI, if you don't want to install all the dependencies of the official letsencrypt client, I made a <200 line python script that automates issuing and renewing certificates. Love the Let's Encrypt project, but really don't want to install all those dependencies on my server just to get a free cert.
No worries! Every time I see a Let's Encrypt thread on HN, there's always complaining about having to trust the official client with root access, webserver configs, dependencies, or whatever. So I made my clients (letsencrypt-nosudo, gethttpsforfree.com, acme-tiny) to shut those people up. My clients are not intended to serve the wider Let's Encrypt target audience, who probably don't know what a CSR is. But for those who do, I made clients that don't ask for the access/trust that the official client needs to serve its target audience.
It was really easy to setup automatic renewals, running as an ordinary user. sudo access for reloading apache is the only privileged operation necessary. Great job!
Maybe you can consider getting someone at Let's Encrypt review diafygi's acme-tiny code and, if approved, propose it as an alternative on the Let's Encrypt site. This will be very useful for users who get turned off by the root requirement or the number of dependencies.
Great! I did some work packaging the official Let's Encrypt client for GNU Guix and the dependency graph (complete with circular dependencies in all of the Zope mess) is absurdly huge. Definitely going to give this a try.
Most people shouldn't need both cert.pem and fullchain.pem, because fullchain.pem is "full" because it also contains a copy of cert.pem (unlike chain.pem, which doesn't). (I chose these names for the structure of Let's Encrypt's certificate storage.)
Until the CA system is completely abolished, this appears to works great with LE -- free certificates and a guarantee that no other CA can impersonate you.
The ACME protocol could conceivably be extended to update SRV records along with the certificate for some DNS providers.
1. DNSSEC uses a lot of 1024-bit RSA signatures (those are relatively weak)
2. You can't monitor the certificates that CA's issue because anyone issue their own certificates.
The first issue seems valid, but fixable. The second is a weird thing to complain about because it is the entire point of DANE!
Fixable but very unlikely to be fixed anytime sone. Plus the tons of technical issues that make it even more of a problem to use and maintain. To make it viable it would probably have to start over.
Remedial question, for the unfamiliar folks: how do I establish a bootstrap trust w/DNSSEC? Does it require backwards-incompatible changes at the root?
Let's Encrypt's closed beta is no longer accepting new applicants [0], but they are launching the public beta in just under 2 hours (6PM GMT/10AM PST)[1] at the time of this writing.
This might be a dumb question, after I auto-generate all those ssl certs, how am I going to certify it at some CA? so that all browser will not pop up a warning page when the ssl-site is accessed? What's the key difference between letsencrypt and self-signed ssl certificate?
The certificates that Let's Encrypt issues are cross-signed by IdenTrust (a real CA) so browsers should trust the certificate you get from Let's Encrypt. NOTE: just like with other TLS certs, you will need to include the Let's Encrypt intermediate certificate in your webserver config so that it can be chained back to IdenTrust.
https://github.com/diafygi/acme-tiny