Caddy 0.10.14 is a hotfix release for 0.10.13, which was unable to use obtained certificates. All users should upgrade within 30 days.
1 Like
Hi Matt,
I think I ran into the v0.10.13 issue mentioned above so I was happy to see a v0.10.14 release when I checked today so I could retry…however on a site that was previously using our own wildcard certificate (from Digicert) when I try to switch this site on v0.10.14 to get a Let’s Encrypt certificate it appears to be failing in the same way it was before so I’m not sure if this is still related to the past issue.
This is the output I’m seeing out of Caddy in this case:
Activating privacy features… 2018/04/25 16:10:51 [example.com] failed to get certificate: acme: Error 400 - urn:ietf:params:acme:error:connection - Fetching http://example.com/.well-known/acme-challenge/NRjCePtwF_b-LNQBk6MzdZhLhVTXdWdHYLh6dYLZ55M: Timeout after connect (your server may be slow or overloaded)
Activating privacy features… 2018/04/25 16:11:02 [example.com] failed to get certificate: acme: Error 400 - urn:ietf:params:acme:error:connection - Fetching http://example.com/.well-known/acme-challenge/RacwfhnPwsC3nCtHJBsf89Spn12omdYTnDPfp-huQjw: Timeout after connect (your server may be slow or overloaded)
Activating privacy features… 2018/04/25 16:11:13 [example.com] failed to get certificate: acme: Error 400 - urn:ietf:params:acme:error:connection - Fetching http://example.com/.well-known/acme-challenge/FbjTIMTTNaoSHSX34jYo4OHWa9BvmptInnPZaXfLPPg: Timeout after connect (your server may be slow or overloaded)
Once I switch it back to using our own certificate it’s able to complete that Activating privacy features step without any issues, but I’m hoping to try and switch more of our stuff that’s publicly accessible over to Let’s Encrypt where possible.
Is the issue I described above the same as the issue that was fixed in v0.10.14?
No, that’s a different issue. Looks like Let’s Encrypt isn’t able to connect to Caddy. Make sure your DNS and other infrastructure configuration is correct.
Thanks Matt,
I can provide a few more details via PM if needed (I’m not sure if I have the option to actually initiate that to you or not though…haven’t seen that option here in the forum interface).
DNS-wise everything is configured correctly and the domain is accessible publicly and Port 443 is open as well.
The only potentially odd thing is that this host is being configured with the reverse proxy feature to another process running on the same server (it’s an older web application provided by our college ERP provider and it’s SSL features aren’t up to snuff) and while the site doesn’t normally redirect requests (if you provide a direct URL path, which for this older application is pretty much the only way it’s accessed via a specific URL), if you access the site from it’s direct host name (e.g. http://example.com) it does do a weird redirect there to a different hostname (it redirects to an internal hostname rather than to the publicly accessible one), which must be configured elsewhere in that application, but I wouldn’t think that would affect the Let’s Encrypt certificate creation since I would expect that part of the process to live above the reverse proxy functionality and be handled prior to proxying any part of the request (with Caddy focusing on acquiring the certificate correctly before the proxying / odd redirect might occur).
It’s possible this is an edge case sort of situation, but from the way our end is configured I wouldn’t have expected there to be an issue.
I did try out another test earlier today (I had the thought yesterday that maybe the proxying was occurring before the tls bit so I moved the tls line in the configuration up above the proxy definition).
This resulted in a similar error, but the message was a little different:
Timeout during connect (likely firewall problem)