Mar 03 03:09:03 ncloud01 caddy[14964]: 2019/03/03 03:09:03 [INFO] [example.com] acme: use tls-alpn-01 solver
Mar 03 03:09:03 ncloud01 caddy[14964]: 2019/03/03 03:09:03 [INFO] [example.com] acme: Trying to solve TLS-ALPN-01
Mar 03 03:09:19 ncloud01 caddy[14964]: 2019/03/03 03:09:19 [example.com] failed to obtain certificate: acme: Error -> One or more domains had a problem:
Mar 03 03:09:19 ncloud01 caddy[14964]: [example.com] acme: error: 400 :: urn:ietf:params:acme:error:connection :: Timeout during connect (likely firewall problem), url:
i’ve verified that the host can reach out to the acme servers, but for some reason it’s not getting the certs.
That’s only one half of it. The ACME servers have to be able to reach back out, independently, and connect to your server (via the public DNS, to ensure that your server is in fact serving on that public domain).
Timeout during connect means that the ACME server did a lookup for the domain you requested, attempted to connect, but never got a response. No response means they can’t get a challenge token back, can’t verify you own the domain, and can’t issue a certificate.
The ACME server’s most important function is validating that you own or control the domain you’re requesting a certificate for.
One method, the fastest and simplest one, is to have your server answer a challenge when the ACME server attempts to connect to the host indicated by public domain name system.
If it can’t connect, it can’t use this method.
The other way to prove ownership / control is to add a TXT record to the domain. This doesn’t require public access to the server, but it does require a compatible DNS provider and some extra Caddy configuration.