Maybe this is more of a home lab question, but I’m utterly clueless regarding PKI and HTTPS certs, despite taking more than one class that goes into some detail about how the system works. I’ve tried finding guides on how to set up your own CA, but my eyes glaze over after the third or fourth certificate you have to generate.

Anyway, I know you need a public DNS record for HTTPS to work, and it struck me recently that I do in fact own a domain name that I currently use as my DNS suffix on my LAN. Is there a way I can get Let’s Encrypt to dole out a wildcard certificate I can use on the hosts in my LAN so I don’t have to fiddle with every machine that uses every service I’m hosting? If so, is there a guide for the brain dead one could point me to? Maybe doing this will help me grock the whole PKI thing.

  • A Mouse@midwest.social
    link
    fedilink
    English
    arrow-up
    11
    ·
    edit-2
    2 months ago

    I use Caddy for this. I’ll leave links to the documentation as well as a few examples.

    Here’s the documentation for wildcard certs. https://caddyserver.com/docs/automatic-https#wildcard-certificates

    Here’s how you add DNS providers to Caddy without Docker. https://caddy.community/t/how-to-use-dns-provider-modules-in-caddy-2/8148

    Here’s how you do it with Docker. https://github.com/docker-library/docs/tree/master/caddy#adding-custom-caddy-modules

    Look for the DNS provider in this repository first. https://github.com/caddy-dns

    Here’s documentation about using environment variables. https://caddyserver.com/docs/caddyfile/concepts#environment-variables

    Docker

    A few examples of Dockerfiles. These will build Caddy with DNS support.

    DuckDNS

    FROM caddy:2-builder AS builder
    RUN xcaddy build --with github.com/caddy-dns/duckdns
    
    FROM caddy:2
    COPY --from=builder /usr/bin/caddy /usr/bin/caddy
    

    Cloudflare

    FROM caddy:2-builder AS builder
    RUN xcaddy build --with github.com/caddy-dns/cloudflare
    
    FROM caddy:2
    COPY --from=builder /usr/bin/caddy /usr/bin/caddy
    

    Porkbun

    FROM caddy:2-builder AS builder
    RUN xcaddy build --with github.com/caddy-dns/porkbun
    
    FROM caddy:2
    COPY --from=builder /usr/bin/caddy /usr/bin/caddy
    

    Configure DNS provider

    This is what to add the the Caddyfile, I’ve used these in the examples that follow this section. You can look at the repository for the DNS provider to see how to configure it for example.

    DuckDNS

    https://github.com/caddy-dns/cloudflare?tab=readme-ov-file#caddyfile-examples

    tls {
    	dns duckdns {env.DUCKDNS_API_TOKEN}
    }
    

    CloudFlare

    https://github.com/caddy-dns/cloudflare?tab=readme-ov-file#caddyfile-examples Dual-key

    tls {
    	dns cloudflare {
    		zone_token {env.CF_ZONE_TOKEN}
    		api_token {env.CF_API_TOKEN}
    	}
    }
    

    Single-key

    tls {
    	dns cloudflare {env.CF_API_TOKEN}
    }
    

    PorkBun

    https://github.com/caddy-dns/porkbun?tab=readme-ov-file#config-examples Global

    {
            acme_dns porkbun {
                    api_key {env.PORKBUN_API_KEY}
                    api_secret_key {env.PORKBUN_API_SECRET_KEY}
            }
    }
    

    or per site

    tls {
    	dns porkbun {
    			api_key {env.PORKBUN_API_KEY}
    			api_secret_key {env.PORKBUN_API_SECRET_KEY}
    	}
    }
    

    Caddyfile

    And finally the Caddyfile examples.

    DuckDNS

    Here’s how you do it with DuckDNS.

    *.example.org {
            tls {
                    dns duckdns {$DUCKDNS_TOKEN}
            }
    
            @hass host home-assistant.example.org
            handle @hass {
                    reverse_proxy home-assistant:8123
            }
    }
    

    Also you can use environment variables like this.

    *.{$DOMAIN} {
            tls {
                    dns duckdns {$DUCKDNS_TOKEN}
            }
    
            @hass host home-assistant.{$DOMAIN}
            handle @hass {
                    reverse_proxy home-assistant:8123
            }
    }
    

    CloudFlare

    *.{$DOMAIN} {
            tls {
    	        dns cloudflare {env.CF_API_TOKEN}
            }
    
            @hass host home-assistant.{$DOMAIN}
            handle @hass {
                    reverse_proxy home-assistant:8123
            }
    }
    

    Porkbun

    *.{$DOMAIN} {
            tls {
    	        dns porkbun {
    			api_key {env.PORKBUN_API_KEY}
    			api_secret_key {env.PORKBUN_API_SECRET_KEY}
    	        }
            }
    
            @hass host home-assistant.{$DOMAIN}
            handle @hass {
                    reverse_proxy home-assistant:8123
            }
    }
    
    • theparadox@lemmy.world
      link
      fedilink
      English
      arrow-up
      2
      ·
      2 months ago

      Thanks for being so detailed!

      I use caddy for straightforward https, but every time I try to use it for a service that isn’t just a reverse_proxy entry, I really struggle to find resources I understand… and most of the time the “solutions” I find are outdated and don’t seem to work. The most recent example of this for me would be Baikal.

      Do you have any recommendations for where I might get good examples and learn more about how do troubleshoot and improve my Caddyfile entries?

      Thanks!

      • sugar_in_your_tea@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        2
        ·
        1 month ago

        Baikal

        Ah, PHP, there’s your problem. 😀

        Honestly, I just proxy to a separate nginx server to handle the PHP bits, it’s not worth cluttering up my nice, clean Caddy setup with that nonsense.

    • sugar_in_your_tea@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      2
      ·
      1 month ago

      I did basically this w/ Cloudflare, and it worked perfectly. I used to do ACME requests, but this is simpler and doesn’t require me to route traffic into my LAN. I now expose a handful of services, but I used to have to expose all services for TLS cert renewal to work.

    • Monument@lemmy.sdf.org
      link
      fedilink
      English
      arrow-up
      0
      ·
      1 month ago

      The advice I needed and have not been able to find. I could kiss you. Or at least give you a fond nod.

    • conrad82@lemmy.world
      link
      fedilink
      English
      arrow-up
      0
      ·
      2 months ago

      I do the same!

      I have a provider that is not supported by caddy, but I can still use it via duckdns delegation!

      https://github.com/caddy-dns/duckdns?tab=readme-ov-file#challenge-delegation

      Challenge delegation

      To obtain a certificate using ACME DNS challenges, you’d use this module as described above. But, if you have a different domain (say, my.example.com) CNAME’d to your Duck DNS domain, you have two options:

      1. Not use this module: Use a module matching the DNS provider for my.example.com.
      2. Delegate the challenge to Duck DNS.
  • False@lemmy.world
    link
    fedilink
    English
    arrow-up
    7
    ·
    1 month ago

    You don’t need a public DNS record for https to work. You can just use public external certs as long as it’s for a domain you own. You don’t need to setup the same domains externally.

    If you want certs for a domain you own, then yeah you’re looking at self signed.

  • reluctant_squidd@lemmy.ca
    link
    fedilink
    English
    arrow-up
    4
    arrow-down
    1
    ·
    edit-2
    1 month ago

    Not sure if anyone else mentioned this, but you can just redirect traffic on your local LAN with an ad blocker like pihole ( I currently use adguardhome podman instance )

    Basically, it rewrites any calls to your outside domain from within your local network, back to your local web server. As long as the site is setup with the certificate there, you’re good.

    Then setup a nginx reverse proxy and you’re golden. Regular site outside LAN, internal site inside LAN.

    Edit: spelling

  • JakenVeina@lemm.ee
    link
    fedilink
    English
    arrow-up
    3
    ·
    2 months ago

    The most straightforward thing to do, on a private LAN, is to make all your own certs, from a custom root cert, and then manually install that cert as “trusted” on each machine. If none of the machines on this network need to accessed from outside the LAN, then you’re golden.

  • xrun_detected@programming.dev
    link
    fedilink
    English
    arrow-up
    2
    ·
    2 months ago

    +1 for the letsencrypt wildcard with DNS verification, been using this for years. with dehydrated (https://github.com/dehydrated-io/dehydrated) you can automate renewing the certs, pretty convenient.

    One thing i didn’t see mentioned yet - you can also easily create a wildcard for a subdomain of your domain, e.g. *.local.example.com. Most DNS providers let you define something like _acme-challenge.local IN TXT ... so you don’t even need to define an extra zone for local.example.com. Probably makes no big difference, but i like it ^^

    • 4am@lemm.ee
      link
      fedilink
      English
      arrow-up
      3
      ·
      2 months ago

      If you are really looking for hassle-free this is it. LetsEncrypt root certificates are already trusted by most devices so when your friends come over and wanna control the media library or whatever you don’t need to install your locally hosted CA’s self-signed certificates on their phone.

      Also certbot and a cron or systemd timer is all you need; people have rolled all these fancy solutions but I say keep it simple.

      • sem@lemmy.blahaj.zone
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 month ago

        Adding to this, the eff certbot website has really great noob-friendly instructions which really helped me get set up.

    • early_riser@lemmy.radioOP
      link
      fedilink
      English
      arrow-up
      2
      ·
      1 month ago

      At the time of the OP I was testing federating two nodeBB instances. ActivityPub requires HTTPS AFAIK.

  • TedZanzibar@feddit.uk
    link
    fedilink
    English
    arrow-up
    1
    ·
    2 months ago

    If you own a domain, which you do, you can get wildcard certs from Let’s Encrypt using a DNS challenge. Most (all?) popular reverse proxies can do this either natively or via an addon/module, you just need to use a supported DNS provider.

  • fmstrat@lemmy.nowsci.com
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 month ago

    I used to do what you do, just sub-domains for everything. I eventually set up an internal CA for *.lan and install the CA cert on all devices.

    It’s actually more secure, since I dont rely on a third-party for certs and have full control over pinning.

  • catloaf@lemm.ee
    link
    fedilink
    English
    arrow-up
    1
    ·
    2 months ago

    You don’t need public DNS. You can use whatever domain you want if you use your own DNS server (though you should use one you own, or something under the .internal TLD).

    Likewise, you can issue whatever certs you want if you trust the CA.

    But LE does support wildcard certs. You can get them with certbot or other tools.

    Personally I use traefik, which has LE support built in. It automatically gets an individual cert for each service. If you use caddy, I’m sure it has something similar.

  • douglasg14b@lemmy.world
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    1 month ago

    I just:

    1. Have my router setup with DNS for domains I want to direct locally, and point them to:
    2. Have a reverse proxy that has auto- certbot behavior (caddy) connected to the cloud flair API. Anytime I add a new domain or subdomain for reverse proxine to a particular device on my network a valid certificate is automatically generated for me. They are also automatically renewed
    3. Navigation I do within my local network to these domains gives me real certificates, my traffic never goes to the internet.
    • Lovable Sidekick@lemmy.world
      link
      fedilink
      English
      arrow-up
      0
      ·
      edit-2
      1 month ago

      When somebody says they “just” reverse the polarity of the navigational deflector array and channel power directly from the warp core.

      I can’t even get host mapping to work on my Centurylink router - the name is defined for the IP address but nothing else on my network can browse to it by name, only by IP. - software dev who has never understood networking.

      • douglasg14b@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 month ago

        In this case I run pfSense instead of my ISP provided router. This allows me to have my own DNS resolver, which I can then resolve various domains to internal addresses.

        All devices on my network point to my router for DNS allowing them to resolve internal addresses from all of these.

        • Lovable Sidekick@lemmy.world
          link
          fedilink
          English
          arrow-up
          1
          ·
          1 month ago

          Thanks, I’ll lookup pfSense. But straightforward host mapping has worked for me in the past with this router and others. It worked great on my old Cisco DSL router 25 years ago. So simple and straightforward, it should just freaking work. sigh

    • Celestus@lemm.ee
      link
      fedilink
      English
      arrow-up
      0
      ·
      1 month ago

      FYI, all the certs you generate are public record, so it might be a good idea to use a wildcard route in Caddy. That will make it only generates one cert, so no one can find your internal domain names. Especially if your Caddy instance is accessible from the Internet, and you’re expecting external connections not to be able to access domains with only internal DNS records

      • douglasg14b@lemmy.world
        link
        fedilink
        English
        arrow-up
        2
        ·
        edit-2
        1 month ago

        That’s a good call out.

        There are a few things I do right now:

        1. All of my public DNS entries for the certs point at cloudflare, not my IP.
        2. My internal Network DNS resolver will resolve those domains to an internal address. I don’t rely on nat reflection.
        3. I drop all connections to those domains in cloudflare with rules
        4. In caddy, I drop all connections that come from a non-internal IP range for all internal services. Additionally I drop all connections from subnet that should not be allowed to access those services (network is segmented into VLANs)
        5. I use tailscale to avoid having to have routes from the Internet into my internal services for when I’m not at home.
        6. For externally accessible routes, I have entirely separate configurations that proxy access to them. And external DNS still points to cloudflare, which has very restrictive rules on allowable connections.

        Hopefully this information helps someone else that’s also trying to do this.

  • Admiral Patrick@dubvee.org
    link
    fedilink
    English
    arrow-up
    0
    ·
    edit-2
    2 months ago

    Is there a way I can get Let’s Encrypt to dole out a wildcard certificate

    Yep. Just specify the domains yourdomain.com and *.yourdomain.com in the certbot request. Wildcard domains require the DNS-based challenge, but you’ve said you’re already good there. You don’t technically need the apex domain (yourdomain.com) but I always add it since I do have services running there.

    Any subdomains under the wildcard can use internal DNS or internal IPs on the public DNS (I do the former, but the latter works too).

    I used to run an internal CA, and it wasn’t too hard to setup a CA and distribute my root cert. Except on mobile devices. On Android it was easy, but there was a persistent warning that my network traffic could be intercepted (which is true when there’s a custom root cert installed), but it since it was my cert, it got annoying seeing that all the time. Not sure if Apple devices can even do that, but regardless, it wasn’t practical for friends who wanted to use my self-hosted services to install a custom cert when they were over.

    • early_riser@lemmy.radioOP
      link
      fedilink
      English
      arrow-up
      0
      ·
      2 months ago

      Cool. Follow up question: Do I generate the cert once and distribute the same private key to all the servers I’m running? I’m guessing not, but does that mean I run the certbot command on every server?

  • towerful@programming.dev
    link
    fedilink
    English
    arrow-up
    0
    ·
    2 months ago

    You need to control a domain, so LE can verify you are the controller of the domain, then LE will issue you a certificate saying you are the controller of the domain.

    For a wildcard LE cert, you need to use the DNS challenge method.
    Essentially the ACME client (or certbot or whatever) will talk to LE and say “I want a DNS challenge for *.example.com”.
    LE will reply “ok, your order number 69, and your challenge code is DEADBEEF”.
    ACME then interacts with your public nameserver (or you have to do this manually) and add the challenge code as a txt record _acme-challenge.example.com. (I’ve been caught out by the fact LE uses Google DNS for resolution, and Google will only follow 1 level of NS records from the root authorative nameserver).
    All the while, LE is checking for that record. When it finds the record, it mints a wildcard certificate.
    ACME then periodically checks in with LE asking for order 69. Once LE has minted the cert, it will return it to acme.
    And now you have a wildcard cert.

    So, how to use it on a local domain?
    Use a split horizon DNS method.
    Ensure your DHCP is handing out a local DNS for resolving.
    Configure that local DNS to then use 8.8.8.8 or whatever as it’s upstream.
    Then load in static/override records to the local DNS.
    Pihole can do this. OPNSense/pfSense can do this. Unifi can do some of this.

    How does this work?
    Any device on your network that wants to know the IP of example.example.com will ask it’s configured DNS - the local DNS that you have configured.
    The local DNS will check it’s static assignments and go “yeh, example.example.com is 10.10.3.3”.
    If you ask you local DNS for google.com, it won’t have a static assignment for it, so it will ask it’s upstream DNS, and return that result.
    And it means you aren’t putting private IP spaces on public NS records.

    Then you can load in your wildcard cert to 10.10.3.3, and you will have a trusted HTTPS connection.

    Here is a list of LE clients that will automate LE certs.
    https://letsencrypt.org/docs/client-options/

    Have a read through and pick your desired flavour.
    Dig into the docs of that flavour, and start playing around.

    If it’s all HTTPS, consider using something like Nginx Proxy Manager (https://nginxproxymanager.com/) as a reverse proxy in front of your services and for managing the LE cert.
    It’s super easy to use, has a decent GUI, and then it’s only 1 IP to point all DNS records to.