Let’s encrypt automation on Debian | Hacker News Reader

Let’s encrypt automation on Debian

eblog.damia.net

100 pointsnereid66629 comments

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.

https://github.com/diafygi/acme-tiny

Head of Let's Encrypt here. I don't love the number of dependencies for our client either, we're going to work to reduce them.

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.

Thanks for making Let's Encrypt and ACME!

And thanks for writing acme-tiny!

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.

This is my recommended client as well. Easy to use, easy to script, completely automatic. Well done.

Very useful. Thx!

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

For anyone that wants to do this w/ nginx, you can add this location configuration to any "server" block for the challenge portion:

        location /.well-known/acme-challenge/ {
		alias		/var/www/acme-webroot/.well-known/acme-challenge/;
	}

Then use this this tool from mozilla to get a configuration for installing the cert: https://mozilla.github.io/server-side-tls/ssl-config-generat...

I really hope letsencrypt doesn't delay the real solution - DANE.

I was not familiar with DANE:

https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...

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.

It's not a good solution.

https://www.imperialviolet.org/2015/01/17/notdane.html

The TL;DR of that is:

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.

I'm not holding my breath.

DANE certainly is not the real solution. The solution is to deploy HPKP and require CT in the future.

HPKP is entirely complementary to DANE.

Remedial question, for the unfamiliar folks: how do I establish a bootstrap trust w/DNSSEC? Does it require backwards-incompatible changes at the root?

The short story is that it's part of the root now, which is something resolvers ship with.

Isn't Let's Encrypt supposed to launch the open beta today? Let's hope it actually happens...

You can sign up for the private beta and get access pretty quickly: https://docs.google.com/a/allaboutapps.at/forms/d/15Ucm4A20y...

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.

[0]: https://community.letsencrypt.org/t/beta-program-announcemen...

[1]: https://letsencrypt.status.io/pages/maintenance/55957a99e800...

I signed up for a few domains early on and they were enabled, I signed up for two more two days ago but haven't heard back yet.

Perhaps because the private beta was closed two days ago: https://community.letsencrypt.org/t/beta-program-announcemen...

I doubt they're even going to approve any more in the next hour and a half before they flip it to the public beta.

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.

EDIT: IdenTrust, not Entrust, sorry!

Let's Encrypt is cross-signed by IdenTrust, not Entrust.

Letsencrypt is a trusted CA. https://letsencrypt.org/2015/10/19/lets-encrypt-is-trusted.h...

Reply on news.ycombinator.com