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)ā}
stdout
04:51:08
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.
Synology uses ports 80 and 443 for its own web servers. What I would like to do is have Caddy (hosted on my NAS, 192.168.1.111 receive https queries from my DuckDNS domain and pass them along to a web-based server located at 192.168.1.78:6969 ā¦
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)
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:
"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"}"
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\192.168.1.78 over to the other server directory did the trick. Hooray!