Exposing 443 and 80 for DNS Challenge?

1. Caddy version (caddy version): 2.4.6

2. How I run Caddy:

Synology environment as reverse proxy to allow web traffic from the internet to connect via jmstash.duckdns.org:8080 to internal IP

a. System environment:

Docker on Synology DSM7

b. Command:

c. Service/unit/compose file:

only changes from docker hub (other than mapping folders and config file) is  2019/tcp  443/tcp  80/tcp

d. My complete Caddyfile or JSON config:

    acme_ca https://acme.zerossl.com/v2/DV90
    email   softlord@pobox.com




3. The problem I’m having:

Do i really need to keep port 80 and port 443 of my router open to the internet indefinitely in order for SSL to work? I’m concerned about the security implications. It’s quite possibly i’m thinking about this totally wrong.

4. Error messages and/or full log output:

2022/01/26 04:51:08.548 ERROR tls.obtain could not get certificate from issuer {“identifier”: “jmstash.duckdns.org”, “issuer”: “acme.zerossl.com-v2-DV90”, “error”: “[jmstash.duckdns.org] solving challenges: [jmstash.duckdns.org] authorization took too long (order=https://acme.zerossl.com/v2/DV90/order/SOV3FR0yUE9KSx8K_L0nAQ) (ca=https://acme.zerossl.com/v2/DV90)”}

5. What I already tried:

6. Links to relevant resources:

Those ports are needed for the ACME HTTP and TLS-ALPN challenges (80 and 443 respectively), not for the DNS challenge.

The DNS challenge is special, it works by having the ACME CA do a DNS query to look for a TXT type record on your DNS zone, and requires building Caddy with the DNS plugin for your appropriate DNS provider.

The benefit of the DNS challenge is that it allows you to get wildcard certs (if you need it, most people don’t), and it allows you to get certificates even when ports 80/443 are not accessible (i.e. your ISP blocks those ports, or you’re not able to get a public static IP to reach your server).

There’s no inherent security concerns in keeping ports 80/443 open, though. It’s Caddy’s job to handle incoming connections on those ports. You can read this article to get a better idea of how it looks for home networking:

The other benefit of exclusively using ports 80/443 for your webserver needs, is that browsers default to those ports (for HTTP and HTTPS respectively, Caddy will always just redirect HTTP requests back to the HTTPS port). If you use non-standard ports like 8080 then you have to actually type that port number in your browser’s address bar. Annoying.

1 Like

OK so…

Synology uses ports 80 and 443 for its own web servers. What I would like to do is have Caddy (hosted on my NAS, receive https queries from my DuckDNS domain and pass them along to a web-based server located at …

Am I correct in interpreting your response as that the correct way to get this done is:

  • Punch firewall holes 80/443 and point them at the Synology box where Caddy is hosted (not sure how to do this since Caddy lives on a server that already uses those for something else… Maybe in the dockerfile?..this is a bunch of levels of abstraction and making my brain hurt (which is not Caddys fault, certainly)
  • Revise Caddyfile to read:

And the verification/TLS certificate will be addressed without additional ports needing to be opened, etc?

You should be able to switch the ports Synology uses to something else, and have Caddy proxy to it instead. But I’ve never used Synology so I don’t know how easy it is to do that.

You could run Caddy on a different machine if you have one available, to avoid that problem. Caddy is pretty lightweight, most anything would do, even a raspberry pi would probably be sufficient for most proxying tasks.

But yes, you’d port forward 80 and 443 to wherever Caddy is running.

reverse_proxy (with an underscore), but yeah.

If you have more than one app/service to proxy to, then you could use subdomains for each one, something like this:

app1.jmstash.duckdns.org {
	reverse_proxy app1:8080

app2.jmstash.duckdns.org {
	reverse_proxy app2:8080

Yeah, only ports 80 and 443 need to be open for ACME HTTP and/or TLS-ALPN challenges, and for clients outside of your network to connect to Caddy.

1 Like

OK, now the log shows

"2022/01/26 05:58:19.214 ←[31mERROR←[0m tls.issuance.acme looking up info for HTTP challenge {"host": "jmstash.duckdns.org", "error": "no information found to solve challenge for identifier: jmstash.duckdns.org"}"

Looks like from Caddy v2 reverse proxy config for server already running on 443 that enabling tls_insecure_skip_verify is the way to go?

OK I managed to get it working. What ended up being the problem was that I’d generated .key and .crt files for the duckdns site and kept them in the web host directory so the site for which Caddy was a proxy was using a different key/crt combo than Caddy itself.

Deleting the old keys and copying the .key and .crt files from %AppData%\Caddy\Certificates\Local\ over to the other server directory did the trick. Hooray!

Thanks again for your help.

1 Like

This topic was automatically closed after 30 days. New replies are no longer allowed.