this post was submitted on 01 Feb 2026
36 points (100.0% liked)

Selfhosted

56127 readers
1530 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

  7. No low-effort posts. This is subjective and will largely be determined by the community member reports.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
 

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?

you are viewing a single comment's thread
view the rest of the comments
[–] antithetical@lemmy.deedium.nl 2 points 1 week ago* (last edited 1 week 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. No experience with Caddy itself. 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.