Caddy on local network confusion

1. Output of caddy version:

v2.5.2

2. How I run Caddy:

caddy start

a. System environment:

MacOs Monterey
no docker

b. Command:

I run gunicorn with:

gunicorn main:app --workers 4 --worker-class uvicorn.workers.UvicornWorker --bind 0.0.0.0:9001

d. My complete Caddy config:

localhost
reverse_proxy 127.0.0.1:9001

3. The problem I’m having:

If i curl -v to localhost, i successfully enter my web app (so both reverse proxy to localhost:9001 and https is working.

I have the following relevant questions:

  1. do i have to run both caddy AND gunicorn or i can just use guinicorn through caddy? (i guess the answer is yes based to this
  2. shouldn’t i disable localhost:9001 (gunicorn serving) and keep only the caddy proxy to port 80? If yes, how i can do this?
  3. I’m confused with the SSL. Is the https provided by caddy self signed? So, i have to do another procedure to make this recognized by a client? When it expires?

4. Error messages and/or full log output:

curl -v outputs:

*   Trying 127.0.0.1:80...
* Connected to localhost (127.0.0.1) port 80 (#0)
> GET / HTTP/1.1
> Host: localhost
> User-Agent: curl/7.79.1
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 308 Permanent Redirect
< Connection: close
< Location: https://localhost/
< Server: Caddy
< Date: Wed, 14 Sep 2022 09:34:46 GMT
< Content-Length: 0
< 
* Closing connection 0

Yes, Caddy can’t embed gunicorn within itself, and Caddy has no uWSGI (or other python protocol) support currently. I’m not aware of any transport implementations in Go, otherwise we’d consider including it. We don’t have the expertise to implement it (we don’t use Python ourselves).

Keep in mind the link you posted is for Caddy v1, which is no longer supported (hence why the repo is archived).

No, Caddy needs a way to send the request along to gunicorn. In production, you’ll just need to make sure that gunicorn isn’t accessible from the public, i.e. don’t expose port 9001 in your firewall/router config.

Kinda yes, Caddy will set up its own internal certificate authority which signs the certificates. Caddy will attempt to install its root in your system’s trust store, so clients will trust it. That root CA signs intermediates which sign the leaf certificates that your clients actually see. The leaf certs have short lifetimes (12h by default) but the root has a 10 year lifetime. The docs explain some of this

thnx for the info. I ready the automatic https documentation page, but still things are unclear to me.

So, i understand that i have to use Caddy’s certificates for its internal certificate authority.
Then, because caddy install it to system’s root trust store clients will trust it automatically. So, if i proxy localhost:443 to localhost:9001 (my gunicorn server) i will not have to transfer the certificate and read it by the browser right? But, i guess if i try to enter from another client in the local network, i’ll have to accept “manually” the certificate.

Now, i tried this Caddyfile:

localhost:443 {
     reverse_proxy 127.0.0.1:9001
     tls internal
}

And in my localhost browser i get a warning page, accept the risk etc, and get this (But i successfully receive servers response):

And when i try to enter from another client in the same network, i get:

What is wrong with my setup?

Only clients on the same machine as Caddy is running on.

Every client which wants to connect to Caddy (when it’s serving a cert signed by its internal CA) must also trust Caddy’s root cert to do so without errors/warnings.

:443 is redundant here, because Caddy is HTTPS by default (which is port 443).

Technically this is also redundant because when you specify localhost, Caddy will implicitly enable its internal issuer for that domain name.

Caddy only has a certificate for localhost with that config, so if you try to connect with an IP address, it won’t be able to serve any certificate that makes sense.

Setting up the internal issuer for LAN is… complicated. I think this is probably not something for the faint of heart, especially if you don’t have a good grasp of PKI. You’d need to make sure you have a DNS resolver in your LAN to set up a domain name that resolves to your LAN IP address, etc.

I’m not sure what your goal is here. Best if you explain what exactly you’re trying to do, otherwise we’re delving into XY problem - Wikipedia territory.

2 Likes

Only clients on the same machine as Caddy is running on.

Every client which wants to connect to Caddy (when it’s serving a cert signed by its internal CA) must also trust Caddy’s root cert to do so without errors/warnings.

Ok, so can i just install caddy’s self-signed certificate to each client by hand?

Caddy only has a certificate for localhost with that config, so if you try to connect with an IP address, it won’t be able to serve any certificate that makes sense.

Setting up the internal issuer for LAN is… complicated. I think this is probably not something for the faint of heart, especially if you don’t have a good grasp of PKI. You’d need to make sure you have a DNS resolver in your LAN to set up a domain name that resolves to your LAN IP address, etc.

Maybe it’s XY progrem. Cause i find it too difficult to find information on this topic: access your local server with https.
So, here is what i want to implement: I have a local FastAPI (served with gunicorn) that i want to access from other clients in the local network. It’s an internal factory tool, so no need for internet access. For a) increased security (no man in the middle attacks for someone who will enter the local network) and b) for using stuff like OAuth 2 i want https access.

I guess i’m thinking something wrong, because i dont find very limited info on this topic.
Do i have to make another approach?
Till now, i’ve managed to do https://localhost only to my local machine, but https://server_local_ip doesnt work. (by the way, i’ve spent a week or so searching on this topic). Also, caddyfile:
server_local_ip reverse_proxy server_local_ip:8080
Doesnt also work

Yep. I think Smallstep might have some tooling to automate this but I’m not sure.

Can you be more specific? Please fill out the help template completely and follow the instructions to get full logs, etc. I can only guess without that information.

This topic was automatically closed after 30 days. New replies are no longer allowed.