Yes, if anything else is listening on 443, then Caddy can’t listen on 443. You can configure Caddy to listen on other ports instead, of course.
Sorry I should have been more clear with my question. Will it cause any problems with OMV or my home NAS by taking that port away from OMV?
How would I configure Caddy to listen to a different port for HTTPS?
You should consult the OMV documentation and see what configuration options it provides to allow changing the port it listens on.
You could probably have Caddy reverse proxy to OMV once it listens on a different port.
I am web searching every where I can IOT find an answer. I feel so close to finally having this up and running. I spent the first two weeks trying to get the Caddy docker working in OMV and finally gave up on that. now here I am unable to get a simple web page to load.
I’ll see what I can find in the OMV forums about disabling port 443.
Ok I still haven’t had much luck. I ran the code Matt provided:
setcap cap_net_bind_service=+ep $(which caddy)
And the first time I ran
netstat -tulpn | grep 443
It didn’t find anything. Now when I run it it says
tcp6 0 0 :::443 :::* LISTEN -
I do believe tcp6 is OMV since netstat says
tcp6 0 0 192.168.1.29:81 which is my Pi’s IP address and OMV is set to port 81.
I’m just not sure where else to go with getting this to work. My Caddyfile has the following:
localhost
respond “hello World”
But when I type localhost or 127.0.0.1 into the web browser I get connection errors. I am not too familiar with port forwarding but I went into my Orbi router and set it the only way that made sense to me.
Any other ideas how I can see Hello World in my web browser?
Did you leave Caddy running in your terminal while you loaded it up in the browser?
I did. I also used the start command. Here’s what ‘run’ says:
pi@raspberrypi:~ $ sudo caddy run --config /srv/dev-disk-by-label-HomeDrive/“config files”/Caddyfile
2020/05/08 00:15:12.131 INFO using provided configuration {“config_file”: “/srv/dev-disk-by-label-HomeDrive/config files/Caddyfile”, “config_adapter”: “”}
2020/05/08 00:15:12.135 INFO admin admin endpoint started {“address”: “tcp/localhost:2019”, “enforce_origin”: false, “origins”: [“localhost:2019”, “[::1]:2019”, “127.0.0.1:2019”]}
2020/05/08 00:15:12.135 INFO http server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS {“server_name”: “srv0”, “https_port”: 443}
2020/05/08 00:15:12.135 INFO http enabling automatic HTTP->HTTPS redirects {“server_name”: “srv0”}
2020/05/07 20:15:12 [INFO][cache:0x23f82c0] Started certificate maintenance routine
2020/05/08 00:15:12.139 INFO tls setting internal issuer for automation policy that has only internal subjects but no issuer configured {“subjects”: [“localhost”]}
2020/05/08 00:15:12.141 INFO tls cleaned up storage units
2020/05/08 00:15:12.305 INFO pki.ca.local root certificate is already trusted by system {“path”: “storage:pki/authorities/local/root.crt”}
2020/05/08 00:15:12.306 INFO http enabling automatic TLS certificate management {“domains”: [“localhost”]}
2020/05/07 20:15:12 [WARNING] Stapling OCSP: no OCSP stapling for [localhost]: no OCSP server specified in certificate
2020/05/08 00:15:12.310 INFO autosaved config {“file”: “/root/.config/caddy/autosave.json”}
2020/05/08 00:15:12.310 INFO serving initial configuration
And here’s what my browser says when I type localhost:
What’s your current Caddyfile, right now?
It won’t be serving on port 2015.
It’ll be on port 80, which will redirect to port 443. (Those are the default ports)
If your Caddyfile started with localhost:2015, you would go to port 80, and be redirected to https://localhost:2015 instead.
Just having localhost in the Caddyfile should be all I need though, correct?
Yes, that’s all you need.
But if you just have localhost, you need to navigate to http://localhost in your browser, not http://localhost:2015.
Yup I did it without 2015. It automatically adds the 2015 onto it in the www bar after I hit enter. All I type is localhost and I’ve tried it with 127.0.0.1.
I’ve also tried it with localhost:80 localhost:443 127.0.0.1:80 127.0.0.1:443 127.0.0.1:2015. I have tried so many different variations throughout the day. I have made sure Caddy was actually running while doing it also. I’ve changed the localhost in Caddyfile to my duckdns and tried typing that into the browser also.
Sounds like your browser has a permanent redirect cached for localhost:80 → localhost:2015.
Try in another browser, or try https://localhost directly.
I tried my Chrome browser on the laptop a couple times and got errors. I just tried from my phone also.
I should be able to get there from my phone I would assume.
Which computer does Caddy run on?
Both localhost and 127.0.0.1 are loopback addresses. They allow a computer to refer to itself.
So connecting to localhost on your phone would require you to have a web server running on the phone itself.
You need to connect to localhost in a browser open on the computer you’re running Caddy on, i.e. the Pi.
Oh well maybe that’s the problem…my Pi is headless and I’m using Putty from Windows to do stuff to it. I’ve been using my Windows browser to try to access localhost.
So if that is the case and there hasn’t been an issue this whole time except for my lack of knowledge then when I put:
reverse_proxy 127.0.0.1:8096
I should get HTTPS on Jellyfin correct? so far none of my browser tabs (OMV, Portainer, or Jellyfin) are secure even with Caddy running. They all still say the website is not secure and has an exclamation mark instead of a lock.
I might have mis-understood this whole thing with using Caddy. I was under the impression that it would secure my apps/containers/web pages etc if they ran on my server (Pi). I was thinking that any device that tried to access the apps, like Jellyfin which runs on port 8096, would be routed through an https channel and have secure data even from our phones and TV.
Is that wrong? Is it only if accessed from the Pi itself?
It’s not wrong. Caddy can do all these things.
But only if you access them through Caddy.
Imagine Caddy like a layer in front of your service.
If you go around the side (i.e. access your service directly), naturally, you’re not doing it over HTTPS. You’re going straight to the source and nothing changes.
If you put Caddy in the middle, then Caddy can be secure - it can give your browser a HTTPS connection - and then it can connect to the real service in the background, behind the curtain to to speak.
With Caddy in play, reverse proxying to all your apps, you can basically forget that direct access to those apps exist. You only ever talk to Caddy. That’s the idea, anyway.
If you wanna be really nifty, you can firewall the Pi to completely disable direct access to those apps from outside, so you can only access them (nice and securely) through Caddy.
Yes, when you browse to https://MyDNS.duckdns.org. If you go to 127.0.0.1:8096 directly, you’re bypassing Caddy, and its HTTPS, to connect directly to the source.
Lets try something simple. Instead of localhost at the head of your Caddyfile, what’s the IP address of your Pi? Use that as the site label, instead. Then try to browse to that IP address in your browser, e.g. http://192.168.0.10.
3 Likes
Hello,
The issue was you were connecting your own localhost, not the Pi localhost.
I guess you have a proxy config on your Edge browser (that redirection to localhost:2015). But anyway, you solved the caddy issue.
And also, directives separator is an underscore (file_server instead of file-server).
Have fun!
2 Likes