Yes I see that . What specifically ? From my server running Caddy I can outbound on 80 and 443 … and that server running Caddy receives inbound on 80 and 443. Like I said - other services SSH (22) and WOL (9) and RDP (3389) all take inbound traffic that has been port-forwarded in the router.
So I will put that in the Caddyfile, would you like the auto_https off or commented out ?
And then curl to my address… you can use the IP or the domain name.
Caddy only needs to be able to make requests to ACME CAs to set up Automatic HTTPS – that’s its only outbound concern.
The main concern is that ports 80 and 443 need to be open for inbound connections, because those are the ports necessary to for the ACME HTTP and TLS-ALPN challenges, i.e. the HTTP and HTTPS ports respectively.
See the list below, ports 80 and 443 are well-known ports for HTTP and HTTPS:
auto_https off is only relevant if your config actually meets the activation requirements as listed in the Automatic HTTPS docs. A site block with :80 does not meet the activation requirements, so you do not need that. auto_https off basically means “ignore the activation requirements and just never activate Automatic HTTPS features”
1 Like
ok - the Caddyfile is ready. No global options, only quoted “:80” , as above, is in there… to get to 80 send to emupay.me:9992
1 Like
Thanks, always great to test a live setup.
Curl is hanging:
$ curl -v "emupay.me:9992"
* Trying 194.124.229.155:9992...
Definitely some sort of network misconfiguration, like a closed port or something dropping packets.
1 Like
so when it receives something on 80 , it will not try to redirect it to 443/https ??? Thats good to know !! That was the reason I was using auto_https off … to prevent it from trying to redirect it (as I assumed it would fail ). But you are saying even when not using that option it still will not even try to redirect it … even it received the traffic on port 80.
Correction: when Caddy is configured to use the HTTP port (80 by default), it will not redirect to HTTPS, since you explicitly configured HTTP. That’s explained in the post above by Francis and our docs.
Only add something to a config if you need it.
Related to my correction of your statement above, receiving traffic on a port is different from being configured to use a port.
By default, Caddy will redirect requests received on the HTTP port to the HTTPS port, but if you explicitly configure to use HTTP, those redirects won’t happen.
1 Like
BUT when I change the Caddyfile back to original state, it serves up the “Caddy works!” page.
I think it gets the incoming request ( on port 80 ) and then tries to redirect it to https… That why I turned off the option before … But am told that the option makes no difference
You think, or you’re sure? Because my request definitely isn’t even connecting to anything. You’ve got some network misconfiguration somewhere with your ISP or your home network.
You cannot reliably test your edge configuration from within your network unless you understand exactly how your router works. Some do what’s called hairpin NAT, for example, which won’t even send your traffic to the outside world if its destination is inside your own network. An easy test is to turn off your phone’s WiFi and try loading your site over your cell data connection. I bet it will time out. If so, that’s the first thing you need to fix (and it has nothing to do with Caddy).
Makes no difference in your case because there’s nothing in your config that would activate automatic HTTPS.
1 Like
its almost 3am here and I need to work in the morning … Sorry my wording is bad as it is late. I will check it tomorrow. But - like this - with no change to the router/network etc, and the unchanged Caddyfile (pristine after installation) , I get the “Caddy works!” page in a browser pointing to : ` http://…:9992 … That say to me that the Caddy server gets the traffic ( on port 80 ) and replies , and the reply gets all the way to the external web browser.
IF the auto -ssl is not going to ever work - surely I can load in certs manually ? Do I really need to toss out Caddy ? I hope not… good night 
Yes
Are you making these requests from inside your home network, or from outside?
The difference is very significant.
None of the problems you’ve had are problems with Caddy. They’re problems with your networking situation.
2 Likes
From outside.
That is - from outside - I can show the “Caddy Works!” in a browser (pointing to port 9992 ) … But nothing I have tried will show a page of my own html or a curl response from outside…
And how do you know you’re connecting from outside your home network? Are you using your cell phone over cellular/LTE? Are you physically in a different location on a different internet connection? Are you remotely controlling some other machine from which you’re testing the requests?
Because when Matt and I try to make requests to emupay.me:9992, we can’t connect.
Please be as specific as possible. We’re going in circles here because we’re unclear on a lot of details of your setup that aren’t being clearly explained.
Post your current config at every step, the logs you’re seeing, etc.
2 Likes
[Mon Jul 19] root@batopi: /etc/caddy$ cat Caddyfile
# The Ca3ddyfile is an easy way to configure your Caddy web server.
:80 {
}
[Mon Jul 19] root@batopi: /etc/caddy$
try this: http://194.124.229.155:9992 ← edited typo is fixed
By the way - I really appreciate your help… I mean it is really amazing ! and I thank you for every minute you are helping me solve my problems here. I cannot say in words how happy and appreciative I am about it… just ty, ty, ty ! (ps I know my language not always so clear and I am sorry about that). I already tried for hours/days of fighting this… and only with your help in last 24 hours do I feel I make some progress 
That one was unreachable (IP ending in 144) but a similar IP found via DNS for emupay.me got a 200 OK response:
~
➜ curl -kIL http://194.124.229.144:9992
curl: (7) Failed to connect to 194.124.229.144 port 9992: Network is unreachable
~ took 7s 606ms
➜ dig emupay.me
; <<>> DiG 9.10.6 <<>> emupay.me
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54885
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;emupay.me. IN A
;; ANSWER SECTION:
emupay.me. 299 IN A 194.124.229.155
;; Query time: 108 msec
;; SERVER: 192.168.0.3#53(192.168.0.3)
;; WHEN: Mon Jul 19 15:30:17 AEST 2021
;; MSG SIZE rcvd: 54
~
➜ curl -kIL http://194.124.229.155:9992
HTTP/1.1 200 OK
Server: Caddy
Date: Mon, 19 Jul 2021 05:30:26 GMT
2 Likes
sorry - typo - last number is 155
PING emupay.me (194.124.229.155) 56(84) bytes of data.
This forum has limited me to send a reply - but still allows me to edit - sorry .
wait - I will put something in there - website of my son… wait… oh my lunch break almost over.… sorry brain slow today with under 3 hours sleep. I really can only thank you ! so much ! 
Matthew Fay thank you again ! can you please just show a Caddyfile that will put up a html page in place of the “Caddy works!” ?? This one (below) do not work…
:80 {
root * /var/www
file_server
}
Assuming that your external port 9992 is forwarded to your Caddy host port 80, I am ostensibly seeing the expected configured behaviour for a given Caddyfile:
:80 {
}
Specifically, 200 OK over HTTP with no response body, regardless of Host.
~
➜ curl -i http://194.124.229.155:9992
HTTP/1.1 200 OK
Server: Caddy
Date: Mon, 19 Jul 2021 05:34:20 GMT
Content-Length: 0
~
➜ curl -i http://emupay.me:9992
HTTP/1.1 200 OK
Server: Caddy
Date: Mon, 19 Jul 2021 05:34:28 GMT
Content-Length: 0
2 Likes
Huge thanks to Francis and Matt and also Matthew for replying… and explaining things 
Now have a website showing from external (not just “Caddy Works!” page). It is successfully return results from curl -v http://x.x.x.x:9992 and also from curl -v http://emupay.me:9992
I understand about 443 (incoming) it is used in a validation step by LetsEncrypt to (auto) issue a certificate. As I will not ever have 443 incoming, today I already manually got a certificate from LetsEncrypt (using dns challenge) . I also changed so https runs on 8443 on the caddy server and also 8443 from the outside - btw 8443 is becoming a second standard for https anyway…
So now one last step - it to have Caddy use my (manually obtained) certs. I am gettign a crazy permissions error…
{
http_port 80
https_port 8443
}
# The Caddyfile - to configure your Caddy web server.
:80 {
root * /var/www/html
file_server
}
emupay.me {
# tls /etc/letsencrypt/live/emupay.me/fullchain.pem /etc/letsencrypt/live/emupay.me/privkey.pem
}
As I have commented the tls line - Caddy start up without error… But if I remove that, it does not start updue to "permissions error: - log below… caddy user is in sudoers and root group. those pem files are read by everyone (owner,group,world)
Jul 19 09:43:27 batopi caddy[1606]: caddy.HomeDir=/var/lib/caddy
Jul 19 09:43:27 batopi caddy[1606]: caddy.AppDataDir=/var/lib/caddy/.local/share/caddy
Jul 19 09:43:27 batopi caddy[1606]: caddy.AppConfigDir=/var/lib/caddy/.config/caddy
Jul 19 09:43:27 batopi caddy[1606]: caddy.ConfigAutosavePath=/var/lib/caddy/.config/caddy/autosave.json
Jul 19 09:43:27 batopi caddy[1606]: caddy.Version=v2.4.3 h1:Y1FaV2N4WO3rBqxSYA8UZsZTQdN+PwcoOcAiZTM8C0I=
Jul 19 09:43:27 batopi caddy[1606]: runtime.GOOS=linux
Jul 19 09:43:27 batopi caddy[1606]: runtime.GOARCH=arm64
Jul 19 09:43:27 batopi caddy[1606]: runtime.Compiler=gc
Jul 19 09:43:27 batopi caddy[1606]: runtime.NumCPU=6
Jul 19 09:43:27 batopi caddy[1606]: runtime.GOMAXPROCS=6
Jul 19 09:43:27 batopi caddy[1606]: runtime.Version=go1.16.5
Jul 19 09:43:27 batopi caddy[1606]: os.Getwd=/
Jul 19 09:43:27 batopi caddy[1606]: LANG=C.UTF-8
Jul 19 09:43:27 batopi caddy[1606]: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Jul 19 09:43:27 batopi caddy[1606]: NOTIFY_SOCKET=/run/systemd/notify
Jul 19 09:43:27 batopi caddy[1606]: HOME=/var/lib/caddy
Jul 19 09:43:27 batopi caddy[1606]: LOGNAME=caddy
Jul 19 09:43:27 batopi caddy[1606]: USER=caddy
Jul 19 09:43:27 batopi caddy[1606]: INVOCATION_ID=bdf2733ce7284f08b0bfeb773e261b4c
Jul 19 09:43:27 batopi caddy[1606]: JOURNAL_STREAM=8:25060
Jul 19 09:43:27 batopi caddy[1606]: {"level":"info","ts":1626702207.116829,"msg":"using provided configuration","config_file":"/etc/caddy/Caddyfile","config_adapter":""}
Jul 19 09:43:27 batopi caddy[1606]: {"level":"warn","ts":1626702207.1187446,"msg":"input is not formatted with 'caddy fmt'","adapter":"caddyfile","file":"/etc/caddy/Caddyfile","line":2}
Jul 19 09:43:27 batopi caddy[1606]: {"level":"info","ts":1626702207.1211638,"logger":"admin","msg":"admin endpoint started","address":"tcp/localhost:2019","enforce_origin":false,"origins":["localhost:2019","[::1]:2019","127.0.0.1:2019"]}
Jul 19 09:43:27 batopi caddy[1606]: {"level":"info","ts":1626702207.1222875,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0x40003fd2d0"}
Jul 19 09:43:27 batopi caddy[1606]: {"level":"info","ts":1626702207.1223507,"logger":"tls.cache.maintenance","msg":"stopped background certificate maintenance","cache":"0x40003fd2d0"}
Jul 19 09:43:27 batopi caddy[1606]: run: loading initial config: loading new config: loading http app module: provision http: getting tls app: loading tls app module: provision tls: loading certificates: open /etc/letsencrypt/live/emupay.me/fullchain.pem: permission denied
Jul 19 09:43:27 batopi systemd[1]: Started Caddy.
Jul 19 09:43:27 batopi systemd[1]: caddy.service: Main process exited, code=exited, status=1/FAILURE
Jul 19 09:43:27 batopi systemd[1]: caddy.service: Failed with result 'exit-code'.
(END)
You can have Caddy automate this process instead of using a separate tool:
Not really. Browsers will always treat https:// as being port 443 by default, unless you specify the port.
Sure, it’s commonly used in situations where 443 can’t be used for networking reasons, but that doesn’t make it a standard.
Does your distro have SELinux or something? There could be something else preventing file access.
If you’re going the DNS challenge route, I strongly recommend configuring Caddy to use the DNS challenge instead (need to grab a build of Caddy with the appropriate DNS module for your DNS provider).
1 Like
I got the certificate manually. Using this:
certbot certonly --server https://acme-v02.api.letsencrypt.org/directory --manual --preferred-challenge dns --email some@email.foo --domains emupay.me
My distro (dietpi) does not have SELinux or anything similar… The message is crazy. I can log in as caddy and read (even edit ) the PEM files. I can log in as the most basic user and read those PEM files… Even the message says “permissions” I really doubt that tells the full story. As I said “caddy” user is in sudoers and root groups. And caddy user definetly can read those PEM files.
I noticed that LetsEncrypt stores the PEM files in /etc/letsencrypt/archive/emupay.me/ and only puts a symlink in /etc/letsencrypt/live/emupay.me . But I tried both of those file locations in the TLS options, and I get the same message for both locations… Any ideas?? My only thought is to COPY the 2 PEM files into a folder where caddy looks for certs… But that seems a bit rough … I don’t know ?