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

Selfhosted

60587 readers
1338 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:

Detailed Rules Post

  1. Be civil.

  2. No spam.

  3. Posts are to be related to self-hosting.

  4. Don't duplicate the full text of your blog or readme if you're providing a link.

  5. Submission headline should match the article title.

  6. No trolling.

  7. Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details. Tags [CBH] or [AIP] are required, see the link in Rule 8 for details.

  8. AI-related discussions and AI-involved promotional posts have additional requirements for tagging, as noted in Rule 7 and the AI & Promotional Post Expanded Rules post. )

Resources:

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

Questions? DM the mods!

founded 3 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 5 months ago* (last edited 5 months 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.