I'd love to see this paired with your https://gethttpsforfree.com/ which was very easy and pleasant to use (loved the: This website is static, so it can be saved and loaded locally. Just right-click and "Save Page As.."! at the bottom of the page).
I guess this tool is what's needed next to get the auto-renewal crontab
Fun fact. There's really nothing stopping you from using a PGP/smartcard/HSM keypairs for the ACME account key. Would love to see someone adapt this or another client to use a yubikey or other hardware key.
Also along these lines is https://github.com/kuba/simp_le , which is quite a lot larger than acme-tiny, but still much closer to something I'd want to stick in a crontab.
Indeed. However, it's important to note that even if someone does MITM letsencrypt.org, they only see your public key and CSR. The private keys never get sent over the wire, so you don't risk leaking your private keys. However, a MITM could issue you a fake certificate that doesn't chain back to the Let's Encrypt root. This risk isn't any more than the way most CAs do it now (they email you the signed certificate).
I don't see the point in verifying that I'm connecting to Let's Encrypt. If I am not connecting to Let's Encrypt then the cert I get back won't show as being issued by them.
I think this is a nice option. I gave it a try —and read the source code. :)
I opted for acmetool[1] though, which albeit much larger (and thus much more difficult to verify), is easier to use [2].
The more impressive option I've seen is caddy server [3] which sets up everything automatically. You start the server and it automatically requests certificates, serves your content (static, fcgi, proxy etc) through TLS and redirects plain traffic to SSL. You don't even need to know what let's encrypt or ssl is. It has a bug though, every time you start the server it requests a new certificate, so after a few restarts you will get your domain temporarily banned from let's encrypt.
> It has a bug though, every time you start the server it requests a new certificate, so after a few restarts you will get your domain temporarily banned from let's encrypt.
There is a bug in the case of a failure in which it doesn't write the successfully-obtained certs to disk, but that will be fixed in the next patch release. Caddy does reuse certificates if it already obtained them before; it persists them to the disk for next time.
Thank you for the clarification and your work on caddy! I really like it and recommend it.
Indeed, the bug affects an edge case, but due to caddy being relatively new (thus you have many new users) and let's encrypt being very new, I think this edge case will be a bit more common for the next few days/weeks. :)
I went from a blank slate on lets encrypt, to deployed SSL cert in less than an hour. Most of the time was spent discovering that 1) acme-tiny requires Python 2.7 or above to be installed and 2) you need to create the .well-known/acme-challenge/ directory structure manually.
I think it would be better to let 2.6 wither on the vine. Everyone is supposed to be migrating to 3.x. Supporting defunct 2.x series with new code doesn't help matters. Anyone so glacially stuck that they can't upgrade to 2.7 has more security issues than lack of HTTPS.
Agreed. 2.6 is was EOLed over 2 years ago and is consequently already missing significant security patches (e.g. CVE-2014-1912). I think it's unnecessary and maybe even unwise to support it, especially for a security-critical application.
I used it as well yesterday and it worked very well! The only thing that could be probably explained better is how to set up file permissions for the renew script, I had to do this by trial and error. An example of few commands implementing best practice would be nice.
Yep, I wrote both. The difference is that letsencrypt-nosudo doesn't have access to your private user account key, so you need to manually sign the requests. Acme-tiny does have access to your private user account key, so it signs the requests for you.
I was getting a lot of requests to automate letsencrypt-nosudo, so I did with this client rather than starting to ask for private keys in letsencrypt-nosudo.
Great approach. You rarely see people these days willing to push a new project to solve a similar problem rather than changing the old one to suit some feature request demand.
The script is great, but on that decision alone you really deserve a slow clap.
After trying a few other Clients, which all were too complicated to get to work on my ancient Debian, i sucessfully used this one. I only needed to patch some sting formatting (replace {} with {0}, {1} etc). And install argparse from pip.
Debian stable (jessie) and oldstable (wheezy) both have python 2.7, which supports the {} syntax. Why are you still running Debian oldoldstable (squeeze) or older? The standard security support ended long ago, and even the LTS security support ends in February 2016.
This implies you are using Python 2.6; note other comments about the lack of certificate verification. Consider generating the signing request on your own PC instead, but note you should still generate the keys on the server.
The problem with security is that whilst it may not appear to matter, lots of little holes can add up to one big one. For example, MITM implies you can't trust the data you're getting back...
Someone else here points out that a MITM to Let's Encrypt could cause you to host someone else's ownership challenge for the domain, thus the attacker could use you to prove the attacker controls your domain name.
I have just used this script and it worked great. I used the lets encrypt normal client and it felt very bloated for me: virtual env, docker, tons of dependences. I hope lets encrypt folks put their client on a diet.
With the current CA scheme you'll always have to trust someone at some point. I think trusting the EFF with not collaborating with the NSA is a pretty good bet.
Doesn't matter. TLS with vanilla PKI isn't a defence against the NSA, it's a defence against your CC number or password being pilfered by a dodgy hotspot operator...or from your ISP injecting ads in to your webpages.
Anyone who thinks LetsEncrypt is a backlash wrt the Snowden revelations is deluded. A race to the bottom for DV certs was as inevitable as mass online piracy was once the cost of broadband filesharing went to zero.
This is awesome! I have had a Let's Encrypt private beta email sitting in my email for a while, but didn't want to install the client because it has so many dependencies.
Are you sure it does all the proper SSL verification, that is, what versions of Python is it safe to use this with given the likes of PEP 476?
This uses the default ssl verification in whatever version of python you have. Even though all API requests use public key signing (so nothing really private is ever sent), if you're worried about someone MITM the API requests to letsencrypt.org, please use python 2.7.9+.
I guess this tool is what's needed next to get the auto-renewal crontab