Hacker News Reader

Comment by falcolas | Hacker News Reader

Anything too much higher than "free" is probably going to be too high once Let's Encrypt implements DNS based validation.

Of course, it does look like they support wildcard certs, so it probably won't be cheap.

EDIT: Removed EV reference, these are DV only.

View on HN

Let's encrypt turned on DNS validation a few days ago https://twitter.com/letsencrypt/status/689919523164721152

Hadn't seen that, thanks for the link!

DNS validation landed in production yesterday[1]! \o/

The official client doesn't support it yet though; you'll have to use alternative clients.

[1]: https://twitter.com/letsencrypt/status/689919523164721152

how does this work ? one of the big challenges with letsencrypt was that I'm unable to bake it in my Docker images. I had a circular dependency - where my nginx wont start without my certificate and letsencrypt needs nginx to be running to serve the temp file that it creates.

does this solve that ? Am I now able to bake letsencrypt in my docker images ?

I'm not familiar enough with docker to comment on what the best solution would be. That being said, instinctively I would say that a certificate is something that should be provided to docker instances as part of the configuration and not acquired whenever you launch a new instance (you would run into rate limits quite fast).

With DNS-based validation you have to create a TXT record on your domain with a random token. If you can automate creation of TXT records from your setup, that would be an option to solve the challenge. The rate limit issue still applies.

This is the same problem of circular dependency then. Does the random token stay alive for longer than 90 days? Then this might still work.

IIRC authorizations (solved challenges) expire after 10 months, so you could get up to 13 months of certificate coverage out of one solved challenge. The official client doesn't support this yet, it will request a new challenge token on every run.

How is that a circular dependency?

You might want to take a look at this, not sure if it will work for you though: https://github.com/JrCs/docker-letsencrypt-nginx-proxy-compa...

I have an ansible role that deploys letsencrypt certificates. It's not perfect, but currently the flow is: check if nginx is running. if it's running, use the webroot authenticator. if it's not, use the standalone authenticator.

This creates issues come renewal time, but a few tweaks to the renewal config (/etc/letsencrypt/renewal/your.domain.conf) fixes that

I have an nginx Letsencrypt integration example which might be helpful to you:

https://github.com/DanielDent/docker-nginx-ssl-proxy

My solution is to simply include a self-signed dummy keypair that gets replaced by the letsencrypt keys when they get issued.

An alternative approach would be to remove the SSL listener entirely until the certificate is issued.

This is awesome. Thanks for packaging it!!

Does the DNS based validation make this better in any way?

You are welcome :). Glad you like it.

I assume you mean Let's Encrypt's newly announced DNS validation approach to issuance? I think that would only add unnecessary complexity here.

There are other setups where that will be nice to have, but I don't think this is one of them.

It launched yesterday :-) https://alexgaynor.net/2016/jan/20/announcing-letsencrypt-aw... is some tooling I wrote for use on AWS.

Very cool, I was working on basically the same thing[1]. What do you think will happen to your project now that this exists from Amazon?

[1] https://github.com/ubergeek42/lambda-letsencrypt/

The DV certs are free (including wildcard certs)!

And that's the benefit compared to Let's Encrypt, which doesn't have wildcard certs (yet).

Reply on news.ycombinator.com