Show HN: Acme-tiny, a tiny 200-line Let's Encrypt client | Hacker News Reader

Show HN: Acme-tiny, a tiny 200-line Let's Encrypt client

github.com

280 pointsdiafygi51 comments

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

Both tools are made by the same user.

That's why he said "paired with your"

When I commented `your` was not part of that comment.

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.

Thanks for making this and letsencrypt-nosudo!!! I used letsencrypt-nosudo and it worked like a charm.

Frankly, this kinda thing is what I expected from Let's Encrypt and was bummed when I saw the bloat they ended up shipping.

No, thank you for using https!

This reminds me - whatever happened to Google's Project Vault, after its lead project manager left to work for the government?

http://techcrunch.com/2015/05/29/googles-project-vault-is-a-...

https://recode.net/2015/06/29/famed-security-researcher-mudg...

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.

+1 for that. Guide with auto-renew cronjob here: https://blog.philippheckel.com/2015/12/04/lets-encrypt-5-min...

Please be careful using urllib2, unless you are on Python 2.7.10+ or 3.5+ it does not do HTTPS certificate validation.

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.

So you'll display a challenge on your website issued to someone else. This certifies an attacker's key for your domain.

An authentic connection to LE is literally fundamental.

> An authentic connection to LE is literally fundamental.

Unless you validate the certificate that you get using a pre-installed LE root certificate.

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.

[1] https://github.com/hlandau/acme.t or `go get github.com/hlandau/acme/cmd/acmetool`

[2] acmetool quickstart && acmetool want example.com www.example.com

[3] https://github.com/mholt/caddy

> 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 set this up yesterday and it worked great.

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.

After that it was all smooth sailing.

Would love for feedback on how to make this script python 2.6 compatible! https://github.com/diafygi/acme-tiny/issues/9

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.

Very close to https://github.com/diafygi/letsencrypt-nosudo

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.

From the same author.

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.

It still works and because LTS only ends Februar 2016. never change a running system.

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...

MITM is really absolutely not a Problem here, there is no private data transmitted.

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.

https://news.ycombinator.com/item?id=10678557

Thanks for this, diafygi. I set this up this afternoon with Ansible, and it's working really well. Very nice indeed.

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.

How do we know that Let's Encrypt isn't an NSA/CIA program? Like a way to make it easier for agencies to MITM or something?

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+.

Just stopping by to say thanks. I used this yesterday and it worked great -- simplicity wins.

I miss you Daniel <3

Come visit!

Looks great! Thank you.

oh dear

https://en.wikipedia.org/wiki/Acme_%28text_editor%29

It was named after the protocol: https://github.com/letsencrypt/acme-spec

oh dear

http://acme.cat-v.org/

Let's just skip to the end, shall we? https://en.m.wiktionary.org/wiki/ἀκμή#Ancient_Greek

that's not a piece of software

You're right, it's a Greek word.

Reply on news.ycombinator.com