Untitled attachment

@tykling The main problem I have with DNS-01 though is that it's slow as fuck so if you have a distributed cluster of webservers and need to dynamically issue certificates you can just cheat by allowing any server automatically respond to any HTTP-01 challenge without them needing to be aware a challenge was issued. This setup assumes you have a method for servers to automatically find certificates on some kind of shared storage.

Here's my Caddy solution for it:

(acme_standalone) { # ACME http-01 challenge sends a request to /.well-known/acme-challenge/TOKEN # and expects the server to have created a file at that location with the contents # being a string of TOKEN.THUMBPRINT to validate the challenge. # # We are operating in a multi-node cluster and really want to do the http-01 style # ACME validation, so we can use this regex trick to forge a valid response to any possible # challenge from any node that receives the request. This is much faster than dns-01 challenges. # # The thumbprint is derived from the account key that the ACME client has generated at first run. # Our account name is our email defined at the top of this config. # With Caddy this key file would normally be located at: # $THE_CADDY_DATA_DIR/acme/acme-v02.api.letsencrypt.org-directory/users/USERNAME/USERNAME.key # # The same key is used for all providers, so this is compatible with LetsEncrypt, ZeroSSL, etc. # # We are using an extension for Caddy that stores the Caddy data in an S3 bucket, so the key # can be found there and you can use a script in the ops git repo to get the thumbprint. # # Due to the fact that we're storing the production Caddy data in S3 it is unlikely you will # need to generate a new thumbprint, but that is how you would retrace these steps. @achallenge { path_regexp ch ^/\.well-known/acme-challenge/([-_a-zA-Z0-9]+)$ } respond @achallenge "{re.ch.1}.REDACTED_THUMBPRINT_HERE" }

Public

Notices where this attachment appears