4 ms·

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://

by pfg 11y ago

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 https://twitter.com/letsencrypt/status/689919523164721152

sandGorgon 11y ago
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 ?
- pfg 11y ago
  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.
  - sandGorgon 11y ago
    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.
    - pfg 11y ago
      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.
    - serge2k 11y ago
      How is that a circular dependency?
- joshstrange 11y ago
  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-companion https://github.com/JrCs/docker-letsencrypt-nginx-proxy-compa...
- finnn 11y ago
  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
- DanielDent 11y ago
  I have an nginx Letsencrypt integration example which might be helpful to you: https://github.com/DanielDent/docker-nginx-ssl-proxy 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.
  - sandGorgon 11y ago
    This is awesome. Thanks for packaging it!! Does the DNS based validation make this better in any way?
    - DanielDent 11y ago
      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.

by pfg 11y ago

sandGorgon 11y ago

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 ?

pfg 11y ago
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.
- sandGorgon 11y ago
  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.
  - pfg 11y ago
    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.
  - serge2k 11y ago
    How is that a circular dependency?
joshstrange 11y ago
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-companion https://github.com/JrCs/docker-letsencrypt-nginx-proxy-compa...
finnn 11y ago
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
DanielDent 11y ago
I have an nginx Letsencrypt integration example which might be helpful to you: https://github.com/DanielDent/docker-nginx-ssl-proxy 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.
- sandGorgon 11y ago
  This is awesome. Thanks for packaging it!! Does the DNS based validation make this better in any way?
  - DanielDent 11y ago
    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.