Problems with new server build and v1 to v2

1. Caddy version (caddy version):


2. How I run Caddy:

batch file

a. System environment:

Windows 10

b. Command:

caddy run

c. Service/unit/compose file:

d. My complete Caddyfile or JSON config: 

reverse_proxy /ombi/*
reverse_proxy /sonarr/*

3. The problem I’m having:

Built new server and copied v1 caddyfile across but am running into issues where it is stuck on trying to solve http-01 challenge when changing to v2. v1 doesn’t work either.

4. Error messages and/or full log output:

C:\CaddyV2>caddy run
2021/04/29 11:48:20.503 ←[34mINFO←[0m   using adjacent Caddyfile
2021/04/29 11:48:20.509 ←[34mINFO←[0m   admin   admin endpoint started  {"address": "tcp/localhost:2019", "enforce_origin": false, "origins": ["localhost:2019", "[::1]:2019", ""]}
2021/04/29 11:48:20.509 ←[34mINFO←[0m   tls.cache.maintenance   started background certificate maintenance      {"cache": "0xc00034e690"}
2021/04/29 11:48:20.509 ←[34mINFO←[0m   http    server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS {"server_name": "srv0", "https_port": 443}
2021/04/29 11:48:20.509 ←[34mINFO←[0m   http    enabling automatic HTTP->HTTPS redirects        {"server_name": "srv0"}
2021/04/29 11:48:20.510 ←[34mINFO←[0m   http    enabling automatic TLS certificate management   {"domains": [""]}
2021/04/29 11:48:20.510 ←[34mINFO←[0m   tls     cleaned up storage units
2021/04/29 11:48:20.510 ←[34mINFO←[0m   autosaved config        {"file": "C:\\Users\\Connor\\AppData\\Roaming\\Caddy\\autosave.json"}
2021/04/29 11:48:20.510 ←[34mINFO←[0m   serving initial configuration
2021/04/29 11:48:20.522 ←[34mINFO←[0m   tls.obtain      acquiring lock  {"identifier": ""}
2021/04/29 11:48:20.523 ←[34mINFO←[0m   tls.obtain      lock acquired   {"identifier": ""}
2021/04/29 11:48:20.532 ←[34mINFO←[0m   tls.issuance.acme       waiting on internal rate limiter        {"identifiers": [""]}
2021/04/29 11:48:20.532 ←[34mINFO←[0m   tls.issuance.acme       done waiting on internal rate limiter   {"identifiers": [""]}
2021/04/29 11:48:21.516 ←[34mINFO←[0m   tls.issuance.acme       waiting on internal rate limiter        {"identifiers": [""]}
2021/04/29 11:48:21.517 ←[34mINFO←[0m   tls.issuance.acme       done waiting on internal rate limiter   {"identifiers": [""]}
2021/04/29 11:48:23.143 ←[34mINFO←[0m   tls.issuance.acme.acme_client   trying to solve challenge       {"identifier": "", "challenge_type": "http-01", "ca": ""}

5. What I already tried:

Tried v1 which used to work but fails on rate limit, I have waited a week but still the same issue, maybe I didn’t wait a full week and tripped the limit again? Sorry for lack of information I am not well versed in this stuff. I would appreciate any help :slight_smile:

6. Links to relevant resources:

Are you sure Caddy is publicly accessible on ports 80 and 443? Are your ports forwarded correctly? Is Windows’ firewall preventing connections from reaching Caddy?

I’ve port forwarded on the router and opened up both TCP and UDP on the firewall for both 80 and 443.

This also appeared in the log which didn’t appear before, maybe this offers more insight?

2021/04/29 12:31:14.088 ←[31mERROR←[0m  tls.issuance.acme.acme_client   validating authorization        {"identifier": "", "error": "authorization failed: HTTP 403 urn:ietf:params:acme:error:unauthorized - Invalid response from [2606:4700:3032::ac43:d47b]: \"<!DOCTYPE html>\\n<!--[if lt IE 7]> <html class=\\\"no-js ie6 oldie\\\" lang=\\\"en-US\\\"> <![endif]-->\\n<!--[if IE 7]>    <html class=\\\"no-js \"", "order": "", "attempt": 2, "max_attempts": 3}

Yeah - that means something between Let’s Encrypt and your server is intercepting the request. Are you using something like Cloudflare, or some other CDN?

As you mention Cloudflare I was reading another one of your replies on a similar thread, turned the clouds to grey so it’s DNS only and its working! Apologies for being so daft, does this setup still give me similar protection to what the CDN offers anyways?

No, a CDN like Cloudflare will help protect you against DDoS attacks and make your site load faster to a global audience. However, many people argue that not using a CDN in between is more secure because the TLS certificate presented to the client is the same one as issued by the origin server, i.e. no middleman decrypting the connection and then (maybe) re-encrypting it to your site.

You can still get a TLS certificate behind a CDN or other proxy with the ACME DNS challenge.