I am new to caddy ( and Docker ) and I am hoping to get some insight to troubleshoot why my SSL is not working.
My goal is to self host some containers such as Vaultwarden and Home Assistant.
Currently I am trying to determine that I have an active SSL certificate. I can navigate to the ‘certificates’ folder and see a cert for my domain, but no access from the outside. If I perform a wget it seems that I am not getting seeing a SSL
What’s in your Caddy container’s logs? That’s what we’re looking for.
Are you sure your server is accessible publicly? It needs to be reachable on ports 80 and 443 from the outside to solve the ACME HTTP and TLS-ALPN challenges. Is this running in your home network, or on a VPS?
Thank you again for your input. Being that I am so new do docker, I question what I feel sould be OK and what is not.
From the Ubuntu server, I hope that this is what you are requesting:
root@docker-server:/opt/caddy# curl -vL http://r3.o.lencr.org
* Trying 18.104.22.168:80...
* Connected to r3.o.lencr.org (22.214.171.124) port 80 (#0)
> GET / HTTP/1.1
> Host: r3.o.lencr.org
> User-Agent: curl/7.81.0
> Accept: */*
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: nginx
< Content-Length: 0
< Cache-Control: max-age=14819
< Expires: Wed, 18 Oct 2023 04:24:28 GMT
< Date: Wed, 18 Oct 2023 00:17:29 GMT
< Connection: keep-alive
* Connection #0 to host r3.o.lencr.org left intact
Now what I dont know, is can I get to the ‘instance’ of the caddy container? I had selected tty and rebuilt the container, but it seems that I cant create a console session to test from the actual container
That is the domain, I did not change / redact any data except email and the public IP. I built a new subdomain from duck dns, and as you see in the logs, it looks to connect and pull down a cert. I have these files in the certificate folder: losttest.duckdns.org.crt losttest.duckdns.org.json losttest.duckdns.org.key, so I have to presume that the cert was successful.
I also have tried to connect from cell on data, just in case there were any issues with hairpen nat, but unfortunately same results.
I have access from the outside to different VM on a different server with same FW configurations. The only difference is this case is the docker (on a VM). I have verified that there is no UFW running on the docker’s host, and I would think that pulling down a cert confirm that.
I am stumped, but as a noob to docker and caddy I would expect that a bit. I had the same results trying to run ngnix proxy manager, so I looked into caddy. Honestly I like the simplicity that caddy has to offer, so I hope to understand this more and concur the basic
My guess for next steps is I need to look into tcpdump or setting up some iptables to see if I can see any traffic from the outside make it in. I have to think that it is, as I have seen in logging from the bots rattling my door with previous setups.
I have figured it out. Additionally, I will provide myself with the dunce cap award for the week.
Being that I was testing and learning docker and reverse proxies, I had also learned an additional valuable lesson. If you have more then one domain that is pointing to the same public IP using the same ports, that will not work.
If I understand correctly, the cert worked being that it would use port 80, but once traffic was redirected to 443 that would point to another server, hence the name change and would break.
I appreciate your attention and hanging in there. I am sure that there are others that have set up this ‘trap’ and maybe one day, I can help someone else.
That definitely can work, but you need to configure Caddy to handle each of those domains.
I don’t understand. How would it redirect to a different server? Were you port forwarding 80 and 443 to different machines? The HTTP->HTTPS redirects in Caddy reuse the same domain, and domains will resolve to the same IP regardless of the port being connected to (because there’s no such thing as ports in DNS, that’s a separate layer).
Yes, I was forwarding only port 443 to a machine, as well as port 80, 443 pointing to the machine running docker / caddy. As as soon as I disabled the other port forward, boom, caddy was happy. I believe that ‘if’ I have both 80 and 443 pointing to the first machine, I would have never received a cert ( assuming I am understanding this ).
I agree that I can use caddy to get the service back over to the previous machine. That will be my next step.