I do not understand why you are using certwarden when Caddy can generate SSL certificates by itself.
this post was submitted on 01 Feb 2026
36 points (100.0% liked)
Selfhosted
56032 readers
731 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:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
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.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
-
No low-effort posts. This is subjective and will largely be determined by the community member reports.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 2 years ago
MODERATORS
The easiest way would be to set up caddy to use acme on the servers, and never care about certificates again. See https://caddyserver.com/docs/automatic-https.
If you insist on your centralized solution, which is perfectly fine imo, just place the certificates to a directory properly accessible to caddy, and make sure to keep the permissions minimal, so that the keys are only accessible by authorized users.
If the certificates are only for caddy, there's no reason to mess around in system folders.
Look into let’s encrypt and acme. Requires a publicly registered domain though.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:
| Fewer Letters | More Letters |
|---|---|
| DNS | Domain Name Service/System |
| HTTP | Hypertext Transfer Protocol, the Web |
| HTTPS | HTTP over SSL |
| IP | Internet Protocol |
| SSH | Secure Shell for remote terminal access |
| SSL | Secure Sockets Layer, for transparent encryption |
5 acronyms in this thread; the most compressed thread commented on today has 15 acronyms.
[Thread #53 for this comm, first seen 1st Feb 2026, 15:40] [FAQ] [Full list] [Contact] [Source code]
I used NGINX with Certbot and haven't had to manually touch anything HTTPS, it's great.
I always recommended people new to reverse proxies start with Npm. Reverse proxies are designed to do exactly what you're trying to do, although I'm not sure why you've brought in certwarden. In npm just put in the IP:Port of the host (local or remote) same goes for caddy, but in my experience its not as easy to configure as npm
If you're solely talking about Caddy using self-signed, just use the caddy directory created for this. Should be simple.
The global /etc/SSL dir is locked down for a reason, and you shouldn't relax permissions there just so Caddy can get to subdirs.
Probably need a bit more detail for this like caddy logs and your caddy config. I did a similar thing on NixOS with services.acme getting the certs and then configuring the cert files to include caddy group access (I didn't use caddy directly either for those reading as the DNS challenge approach requires third party plugins which is a bit annoying on NixOS).
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.
I could never get certs working over locally served stuff, but Nginx Proxy Manager made the few things I publish to web fairly easy to get https working. I'm just commenting to come back later and read the answers myself... Let me know if you get it working over Lan!
You mean you have a script that pulls in the cert from a central source (where certwarden renews it), and then caddy can’t access it locally?
Exactly what error is Caddy giving? What permissions have you tried and what was the result? How are you restarting Caddy after renewal? Why do you have multiple reverse proxies?
how about making symlinks to the dir where caddy expects them
Does the caddy user have the permissions to read the files ? I ran into that problem as well. If only caddy needs the cert I moved them into /etc/caddy, chowned the dir again, make sure you use the full path of the cert so /etc/caddy/domain.crt not ./domain.crt