Think I’ve gone down the rabbit hole on this one.

I have more than one Debian machine that I host apps on. I want to serve them with https, so I decided it was best to centrally get the domain cert/key (I’ve used certwarden) and use a script/cron job on each server to get the certs. Then use caddy to reverse-proxy.

So, after some research I decided that certs should be placed in /etc/SSL/certs (keys in /etc/SSL/private). Problem is caddy can’t get to them. I’ve tried messing around with permissions etc but I suspect I’m running into issues because I’m not doing this the proper way.

What is the proper way of doing it? Or is there a much easier solution?

  • Antithetical@lemmy.deedium.nl
    link
    fedilink
    English
    arrow-up
    2
    ·
    edit-2
    11 hours ago

    Oh certificates are so much fun and you have so many options. From fairly easy to mindboggling complex.

    Your current solution is OK if you keep in mind security implications of distributing certs using scripts.

    It is not entirely clear where you do your tls-termination but it sounds like that is the Caddy reverse proxy so that is where your certs should be.

    Placing them in a location like /etc/ssl/example_com/ as fullchain.pem and privkey.pem is probably easiest. Make sure access rights are appropriate. Then point Caddy at them and it should work. I have no experience with Caddy itself though. If Caddy runs in Docker be sure to map the certificates into the container.

    Mind that in this scenario the certificates are only on the Caddy server, connections from the reverse proxy to the services is unencrypted over http. You can’t easily use the LE certificates on the services itself without some ugly split-horizon DNS shenanigans.

    Alternatively you can set up a PKI with certificates for your services behind the reverse-proxy for internal encryption and do public tls termination in the proxy with Let’s Encrypt.