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?

  • x1gma@lemmy.worldEnglish
    3·
    1 hour ago

    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.

  • 4am@lemmy.zipEnglish
    1·
    56 minutes ago

    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?

    • jobbies@lemmy.zipOPEnglish
      51·
      5 hours ago

      Because I have more than one server. It made sense to manage the cert in one place then distribute it to the places it needs to be.

      Caddy because its easy to use.

      • BlackEco@lemmy.blackeco.comEnglish
        10·
        5 hours ago

        But you’re still using Caddy as the sole reverse proxy, don’t you? Do you have multiple Caddy instances that require access to a single certificate?

      • poVoq@slrpnk.netEnglish
        4·
        4 hours ago

        If you switch to the dns-01 challenge you can just generate the certs on multiple servers hasselfree. And as a bonus you can get wildcard certs for subdomains.

  • just_another_person@lemmy.worldEnglish
    21·
    3 hours ago

    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.

  • Mozart409@lemmy.worldEnglish
    1·
    3 hours ago

    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

    • jobbies@lemmy.zipOPEnglish
      2·
      5 hours ago

      Certwarden does that bit. Its making the certs available to caddy that I can’t work out

  • vividspecter@aussie.zoneEnglish
    2·
    5 hours ago

    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).

  • Antithetical@lemmy.deedium.nlEnglish
    2·
    4 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.

  • hendrik@palaver.p3x.deEnglish
    21·
    4 hours ago

    You could try to debug the permission issue… Like take a note of the current permissions, chmod the certificates to 666 and the parent directories to 777 and see if that works. Then progressively cut them down again and see when it fails. And/or give caddy all the group permissions ssl, acme, certwarden… and then check which one makes it fail or work.