Hi all! Im afraid i need some help but let me show you the things i am having troubles with:
Target: Run caddy to reverse proxy domain.nl, plex.domain.nl and nextcloud.domain.nl to different local servers/services.
Background: Pfsense server, ubuntu VM running the services (say 192.168.1.100). At this time i got my pfesnse forwarding port 80 and 443 to 192.168.1.100 port 81 and 444 (to keep my primary services online while i figure this out, attached to the domain.nl). I link my domain.nl to that still running service, bound to that domain only locally running on 81/444 to keep 80 and 443 open to test caddy.
Problem: Setting up Caddy using this tutorial. Error displayed on my terminal (after typing: sudo caddy -host domain.nl) :
2019/05/30 16:02:26 [INFO] [domain.nl] acme: Trying to solve TLS-ALPN-01
2019/05/30 16:02:40 [INFO] Unable to deactivated authorizations: https://acme-v02.api.letsencrypt.org/acme/authz/dB0itSeoZDtNC_LGc8CPGACfhFqN82ne3bEMhGQ4x-U
2019/05/30 16:02:40 [domain.nl] failed to obtain certificate: acme: Error ā One or more domains had a problem:
[domain.nl] acme: error: 400 :: urn:ietf:params:acme:error:connection :: Timeout during connect (likely firewall problem), url:
What i tried so far:
Another brand new VM of ubuntu 18 LTS; same error
Different domain name i have
tested openness of ports ( nc -zw3 domain.nl 80 && echo āopenedā || echo āclosedā aswell for 443, both showing opened).
Double checked my domain.nl is pointed towards my external IP
How can i resolve this?! Kinda at despair at this moment. Is this because i already binded domain.nl to my nextcloud snap (which is still working now on ports 81 & 444?
Any help would be really appreciated! Thanks in advance
From a quick test, it looks like domain.nl is currently served by Apache server. Doesnāt explain why LetsEncrypt got a timeout, though, I connected just fine. Youād need make sure your edge router is forwarding packets to the Caddy host.
Domain.nl is not really the domain im attempting to use and besides; after i am doing testing/configuring i reroute the ports to my nextcloud instance to keep it in the air in the meantime i am trying to figure this out.
It still bugs me i cant get this working. Ports 80 and 443 are perfectly open for my nextcloud instance (when forwarded to 81 and 444 for nextcloud) but when i switch them to forward to 80/443; caddy gets the acme 400 errorā¦
Curl results:
HTTP/1.1 200 OK
Server: Caddy
Date: Sat, 01 Jun 2019 11:19:59 GMT
And for port 443:
curl: (52) Empty reply from server
Ran them from my internal network; i dont know how to use that command on my android phone.
Another notable thing is that i have a pfsense router. Got DNS rebind checks disabled since iāve read somewhere that this might cause issues. My DNS servers are 1.1.1.1 and 1.0.0.1. But as you say, it works fine if i forward to port 444 and 81 to keep my nextcloud alive.
Today i also checked if i can receive some certificates through the acme package, worked without a problem.
Hopefully you have some other leads!
NB: I got to say: With your suggestion i realised to check if port 80 wasnt bound/used by another program. Found nginx running so purged that since i dont use it. Still no succes after this though.
Whatever port 443 is forwarded to, itās not reaching Caddy (assuming you ran Caddy properly on port 443 for this test).
Caddy, via acme-go/lego, will always attempt to validate via TLS-ALPN challenges, which happen over 443. Iād wager if you ran Caddy with the -disable-tls-alpn-challenge flag, which causes it to fall back to the HTTP challenge on port 80 (which youāve tested as working), Caddy would successfully requisition a certificateā¦ But you probably still wouldnāt be able to access the HTTPS page.
Iām honestly stumped, that seems almost impossible. If you can get:
from a cURL from an external network, thatās everything Caddy needs to solve a HTTP challenge right there. Weāre talking about a basic HTTP request, working fine, thatās essentially the entire mechanism LetsEncrypt uses.
There are no DNS settings to consider. Not even Cloudflareās MITM interferes with a HTTP challenge. There just needs to be an A record at the end of the line that points to your host.
Getting a working HTTP response when cURLing your domain, but having LetsEncrypt time out, would require that your system is somehow interfering specifically with requests from LetsEncrypt IPs.
