This is unnecessary

It is straightforward to create your own Root CA and use it to sign certificates for your private network, using openssl.

Ensure that you implement the V3 extensions with @altnames, for the certificates you issue, with a "DNS => " (or you can use an IP address instead of FDN. I have not experimented with that). .local domain names work fine

If you do not implement "@altnames" the certificate will work for tools like curl, wget "openssl s_client", but not for browsers. (In my notes some place I am too lazy to go and read there is a reference to the RFC that documents that you do not have to use the subject/CN, mēh)

There are other tools (than openssl) that do this to.

Using this service means you really do not have a private network

Caddy will do this for you as long as you don't give it an ACME config. It handles the root CA creation as well as all of the certificates for any domains that you define in the Caddyfile, so all you have to do is find the root CA it generates and install it on your devices.

> all you have to do is find the root CA it generates and install it on your devices.

Unfortunately that's the hard part - getting Firefox/chrome/edge/safari and is/libc/curl to all trust the ca. It's a little easier on Linux, but still convoluted.

And with an actual trusted CA the trust is way too wide (every domain).

Not to mention revocation lists and certificate renewals (and revocation s) ...

Dedicated letsencrypt "internal" domain is probably the sweetspot for most uses these days.

Maybe a serviceN.int.example.com where int.example.com allows for dynamic DNS updates/DNS challenges.

I've been thinking about setting up powerdns/coredns/knotdns with rfc dynamic updates for a dedicated internal domain - but for now tailscale with magic DNS mostly fills the need (unfortunately not with ssl for all k8s internal services, "only" VPN).

https://github.com/joohoi/acme-dns/

https://docs.getlocalcert.net/tips/validation-domain/#self-h...