Cert-manager has great support for a number of providers[0] including AWS, CloudFlare, Google Cloud, and Azure.<p>I recommend this not just for internal IP setups, for actually for all setups, since DNS verification is more robust than HTTP verification, particularly if you have issues with load balancers, or if Let's Encrypt decides to deprecate a protocol again [1].<p>[0] <a href="https://cert-manager.io/docs/configuration/acme/dns01/#supported-dns01-providers" rel="nofollow">https://cert-manager.io/docs/configuration/acme/dns01/#suppo...</a>
[1] <a href="https://community.letsencrypt.org/t/upcoming-tls-sni-deprecation-in-certbot/76383" rel="nofollow">https://community.letsencrypt.org/t/upcoming-tls-sni-depreca...</a>
I do this with Traefik [0] internally in almost the same way. I use DNS-01 to get a Let's Encrypt wildcard cert and all my internal A records point to the ingress IP and Traefik happily proxies the communications to the appropriate service - container based and non-container based - which is the real win I was looking to solve for in my home environment. The thing I like about just using Traefik is it doesn't rely on a lot of extraneous tooling (can just use Docker without Swarm/K8s) and will automatically consume orchestration services if I'd like it to. But the reality is the majority of things I want valid certs for are static mappings. One config file update of a few new lines of boilerplate is all it takes to get a valid cert fronting any service. And then to get a dashboard of all my internal services I use Heimdall [1].<p>[0] <a href="https://docs.traefik.io/" rel="nofollow">https://docs.traefik.io/</a>
[1] <a href="https://heimdall.site/" rel="nofollow">https://heimdall.site/</a>
Keep in mind, adding local entries to your external DNS will expose internal details of your network, such as hostnames and IPs. Same goes for Let's Encrypt, due to Certificate Transparency logging.
Its TLS and not SSL. Its TLS for a long time now...<p>And yes be aware that through this, it works fine but you are also exposing your internal infrastructure details through dns.<p>I'm not seeing a big issue, just be aware of it.
I wrote a similar post about a year ago[0], but even at the time I wasn't the first to come up with this idea. As someone who doesn't have a lot of experiences with DNS security, seeing other people floating similar setups without significant pushback gives me more confidence that the core idea isn't horribly unsafe. I'm pretty happy/relieved to see other people playing around in the same space.<p>My perspective was (and is) that for portable devices (phones/laptops) that are interfacing with locally hosted services, having SSL for those services is really important because your device probably isn't configured to check what network it's on before automatically pinging 192.168.1.x. This is doubly important if you have other people occasionally hopping onto your network and connecting to those same services. It's imo bad practice to ask everyone connecting to your network to install certificates or set up a certificate manager. I wouldn't do that for any of my personal devices if someone asked me to.<p>To push this a step farther, I imagined a world where my services could handle not just renewing their own certificates, but also updating their addresses if they were moved to a different network/address. If I build a physical device to give to someone, I'd like them to be able to plug it into their network, go to a web URL, and have everything just work -- no messing around with their internal DNS settings or worrying about whether they're using DNS over HTTPS in Firefox.<p>[0]: <a href="https://danshumway.com/blog/encrypting-internal-networks/" rel="nofollow">https://danshumway.com/blog/encrypting-internal-networks/</a>
I’ve tried to set up kubernetes at home a couple of times and I always freak out at the amount of layers and “just run this” style of tutorials. Am I crazy?<p>I’ve heard guix has some kind of container management thing. I’ve been thinking about trying it anyway.
I just created a wildcard with letsencrypt in the format of <i>.internal.mydomain.com<p>My public services all run out of </i>.mydomain.com and all my internal services run out of <i>.internal.mydomain.com<p>I have my internal dns set to resolve any </i>.internal calls to an internal load balancer which hosts the ca certs.<p>The downside is that all internal services are ssl terminated at the load balancer, but this makes handling internal certs easy as they're rotated in a single location. This is Good Enough for my homelab.
inlets with the inlets-operator [0] does this by using the HTTP01 challenge, and gives you a LoadBalancer just like you'd have on AWS. The benefit is that you get a real IP and routable traffic, there's no tricks required. It would also work with DNS01 if that's of interest.<p>[0] <a href="https://github.com/inlets/inlets-operator" rel="nofollow">https://github.com/inlets/inlets-operator</a><p>Feel free to check it out in this tutorial: <a href="https://docs.inlets.dev/#/get-started/quickstart-ingresscontroller-cert-manager" rel="nofollow">https://docs.inlets.dev/#/get-started/quickstart-ingresscont...</a>
I haven't tried it yet but if you have control of your DNS and want automation:<p><a href="https://github.com/joohoi/acme-dns/" rel="nofollow">https://github.com/joohoi/acme-dns/</a><p><a href="https://github.com/joohoi/acme-dns-certbot" rel="nofollow">https://github.com/joohoi/acme-dns-certbot</a><p>A simplified DNS server with a RESTful HTTP API to provide a simple way to automate ACME DNS challenges.
This page is raising a ton of security alerts:<p>"NoScript detected a potential Cross-Site Scripting attack from <a href="https://www.techprowd.com" rel="nofollow">https://www.techprowd.com</a> to <a href="https://carbon.now.sh"" rel="nofollow">https://carbon.now.sh"</a><p>Images are failing to load too. Not sure what's going on.<p>edit: Probably some misusing of DNS rather than actual attack but who knows. Author should fix the site.
I use step-ca [0] for these sort of things and it works brilliantly. I barely see the point of having external DNS servers resolving your internal infrastructure.<p>[0] <a href="https://smallstep.com/certificates/" rel="nofollow">https://smallstep.com/certificates/</a>
No association what so ever to 'em but I so dearly love what they do, I'd encourage users to donate to keep them going healthy and strong!<p><a href="https://letsencrypt.org/donate/" rel="nofollow">https://letsencrypt.org/donate/</a>
I did that, the very hard way (I didn’t know better at the time): <a href="https://whynot.fail/homelab/lets-encrypt-the-house/" rel="nofollow">https://whynot.fail/homelab/lets-encrypt-the-house/</a>
Another alternative is inlets which automates all of the steps necessary and offers Layer 4 as well as Layer 7: <a href="https://docs.inlets.dev/#/" rel="nofollow">https://docs.inlets.dev/#/</a>
Instead of using hacky fragile methods , use<p><a href="https://github.com/FiloSottile/mkcert" rel="nofollow">https://github.com/FiloSottile/mkcert</a><p>to automate setting up local CA and making it trusted.
TLDR:<p>- have a proper worldwide domain<p>- obtain a certificate for that domain<p>- point the domain to local IPs in your network and use the certificate on the local server.<p>Doesn't change that you'd need to self-sign certs for .local or other funky domains.