I've listed this as a positive(praise) category, but it maybe a bit of a general help or question tool. I managed to catch up with @Dan (i hope that's his tag here) at the lets-encrypt desk at Fosdem 2024 here in Brussels, and we got to talking about local development certificates issues.
So as a question on how i might do this better: Following are the details of this project: GitHub - lukeab/k8s-local-dev-env
I developed this project about a year ago to help developers on my team bootstrap a local k8s dev stack, to aid in the adoption of the "new platform strategy" based on k3d and a few observability capabilities (grafana stack components), and i wanted the team to have a functional experience on the dashboards and integration of those components which seems to be far more reliable to setup if you have a valid certificate.
For convenience i based the domain name on the nifty local.gd dns resolver, allowing any prefix to that domain to point back to 127.0.0.1 loopback. Of course i can't issue a letsencrypt for someone else's zone, so i issues a self signed certificate and automated adding to the developers OS and chrome browser trust stores. (only tested on linux, but have always meant to go back and add Mac support). A similar setup approach is well explained here: Certificates for localhost - Let's Encrypt
I could consider tunnel approach with tools like ngrok or the openziti approach zrok, or pinggy, but that might be too complex and diverge away from the goal of keeping the setup as simple and light weight as i can and as close to simulating a "real" service with ssl/tls as I can.
What other options could you all come up with.
And say hi to the letsencrypt team at the stand if you're at Fosdem.
Thanks all.
Run Certbot to obtain a certificate for dev.example.com using the DNS-01 challenge
That will result in the local developer's machine having a valid LetsEncrypt Certificate that has the same trust stores and chain as the final production certificate (except for a slightly different domain name), and can be used for all integrated and functional testing.
An alternate approach is to use the production domain name (e.g. example.com) and then use local DNS/Hosts to handle a split-horizon DNS and point example.com to localhost. I do not like that approach, because people always forget about the split-horizion dns and it just causes problems.
I do not like the approaches of using custom cas, minica, etc - as that will not have the same chain/trust-store as a LetsEncrypt certificate. This approach does require you to have control of public DNS for a registered domain. For teams where privileges to DNS is an issue, you can set up a dedicated subdomain namespace for this and manage the challenges with a self-hosted acme-dns installation.
I have a feeling this is a sticking point for many. There are a ton of solo/hobby devs out there who need an easy way to just start hacking on a project without any external dependencies (free or otherwise). But the state of the web today means a cert is basically mandatory.
You and I know you can purchase a throwaway domain from a registrar for around $1 for the first year. But many do not and/or aren't willing to throw any actual money at making the problem easier no matter how little because that's more friction.
I think what @LukeAB is trying to solve for here is making the process of setting up a tiny self-signed PKI easier for local projects.
I totally agree that a real domain and cert can often end up being less complex than a self-signed PKI. But not always.
I agree with everything you wrote. However, I do believe this can be done with free domains. I know the free TLDs offered by Freenom work with the HTTP-01, I'm not sure if their system currently supports DNS-01 or if another DNS provider is needed.
Using a Private or Self-Signed CA is good enough for many situations and the process is considerably more streamlined. However, it is not much more work for most users to gain control of a registered domain and fully leverage the entire LetsEncrypt trust chain on Development systems to exactly mirror Production.
Thanks for all the responses folks. and thanks @Nummer378 for correcting my mention for Dan Fern
Had a great Fosdem and was lovely to speak with the letsencrypt team there.
I think there's not a clear way forward here, as you mention @jvanasco , there is the possibility of using a subdomain of a production tld, or split level horizon config locally for a production TLD, and signing certs of that using DNS-1 validation, but it does require external dependencies and access.
I hadn't found Minica before, so always nice to find another local tool, thanks for the implied mention, eve though you said you weren't a fan of the local CA approach
One other method I found after speaking with tailscale team at fosdem was to use their funnel feature, I have yet to test that idea out, it has the benefit of making the dev environment endpoint shareable which i do like the idea of, resulting an outcome somewhat like the ngrok approach. I will have to experiment and see where the edges are, but looks promising.
Still, one advantage the local CA approach gave me was having multiple hosts, grafana.local.gd, myapp.local.gd and so on available and secure. plus there was an issue with open-telemetry requiring a ca in cert-manager, though i'm not sure it needed a trust outside the k3s cluster.
Anyway, keen on more insights if anyone has them still to share, and of course, if anyone has issues, comments or PR's they'd be kind enough to submit, please do have a peek at the project: GitHub - lukeab/k8s-local-dev-env
(there's plenty that could be don with it, and i'm sure the scripting has loads of bad parts)
