Elvith Ma'for

Former Reddfugee, found a new home on feddit.de. Server errors made me switch to discuss.tchncs.de. Now finally @ home on feddit.org.

Likes music, tech, programming, board games and video games. Oh… and coffee, lots of coffee!

I � Unicode!

  • 0 Posts
  • 317 Comments
Joined 1 year ago
cake
Cake day: June 21st, 2024

help-circle
  • No, that’s just another hypothetical app that you’re using a reverse proxy for. I just included it to show how you can also set settings for a single subdomain/reverse proxy entry that isn’t used globally on all domains that get served. I used a hypothetical REST API that needs a CORS Header that other apps don’t need (or maybe serve themselves).

    admin off disables Caddy’s admin interface (which shouldn’t be public and if you’re using config files this usually isn’t needed. So just a bit of gardening)

    servers sets some general server options.

    and then I just inserted several blocks that each define a reverse proxy to a different app / backend to show that you can just dump them all in a single Caddyfile. And the last example to show that you can set specific settings only for a specific subdomain instead of globally. As I set headers mostly used by REST APIs, I just called that api.example.com instead of app3.example.com.


  • If you like, I can send you an example of the Caddyfiles, that I’m using (I used the import directive to split every service into its own Caddyfiles, you could just copy and paste everything in the same file). It will take a few hours until I get home, though.

    But basically you can just put every subdomain and it’s target in a separate block and the add some things globally (e.g. passing the original IP, switching off the admin API of Caddy,…)

    Something like this should work:

    
    admin off 
    
    servers {
    		client_ip_headers X-Forwarded-For X-Real-IP
    }
    
    app.example.com {
        reverse_proxy 127.0.0.1:8080
    }
    
    app2.example.com {
        reverse_proxy 127.0.0.1:8081
    }
    
    api.example.com {
        reverse_proxy 127.0.0.1:8082
        header {
            Access-Control-Allow-Methods "GET, OPTIONS"
            Access-Control-Allow-Origin "*"
        }
    }
    



  • WTF?

    I mean, my work PC is managed by the company and thus a Windows device, but why disable that feature? Yes, it somewhat makes sense if you see it like “we don’t want other OS to have all features to make costumers less likely to switch” BUT Teams on Mac has some unique features that haven’t been ported to windows and are still exclusively available on Mac, so…?!


  • Yeah, that’s exactly why I didn’t use my own CA. There’s a plethora of devices that you now need to import the CA to and then you need to hope, that every application uses the system cert store and doesn’t roll its own (IIRC e.g. Firefox uses its own cert store and doesn’t use the system cert store. Same for every java based application,…)

    It’s fiddly with Caddy, as you need a specific plugin to get it to work with anything else than the default challenge. That means using a custom build via caddy - and with docker, you’re SOL. BUT you can just use certbot and point caddy to the cert file in your file system.


  • I have this setup. I bought a domain (say homeserver.tld) from a registrar that allows zone edits with an API. Then I use certbot with a plugin that supports my registrar to get real Let’s Encrypt certificates. Usually Let’s encrypt connects to your server to ensure that it responds to the domain you’re requesting a certificate for, but this challenge can also be done by editing the DNS record of your domain to prove ownership. That is called DNS-01 challenge and is useful of your domain is not publicly reachable. Google for certbot DNS-01 your registrar to find some documentation.

    Some of the VMs/LXC now get certificates for a specific subdomain (“some-app.homeserver.tld”), other just get a wildcard certificate (“*.homeserver.tld”) - e.g. my docker host.