super VS certificates

You can give us a try, https://github.com/spr-networks/super, http://supernetworks.org/. Wireguard is well integrated. We also have a tailscale plugin, and more vpn plugins on the way

Somewhat related -- with the project I work on, https://github.com/spr-networks/super, we do support wireguard peers (and also support combining that wireguard identity with a wifi peer identity as well).

Devices are provisioned by assigning or generating a wireguard keypair in the API.

Next the peers are routed together by policy and by default can't access one another. There's support for bidirectional network groups or one-way firewall rules with NAT.

One are of improvement is multicast support with wireguard, it's doable, just not ready yet.

golang-based SPR is open-source and can be run on RPi: https://github.com/spr-networks/super

> An unspoofable device identity is established with a MAC address and Per-Device Passphrase for WiFi (or a VPN Public Key for Remote Devices). From there, each device gets its own /30 subnet to exist on. Hardening and strict firewall rules block network spoofing and impersonation, and routing rules redefine connectivity between devices and to the internet.

The other thing we've been tasked to work on is load balancing across uplink interfaces, and we're happy for more feedback for how the feature should work. That's tracked under here https://github.com/spr-networks/super/issues/134. We will likely use the fwmark capabilities (which we already use for redirecting traffic to site-to-site vpn connections)

Yes -- except for limited wireguard support, usability for multicast is mostly solved. SPR services mDNS and Zeroconf/SSDP with a udp proxy[1].

[1] https://github.com/spr-networks/super/blob/main/multicast_ud...

You can roll your own with https://github.com/smallstep/certificates. We maintain major open source projects and contribute a lot to other projects. I don’t think that means everything we do has to be open source. Sorry this one wasn’t. Doing this in pure open source would be a book, not a blog post.

Love Let’s Encrypt — we’re sponsors — but using them for WiFi is a terrible idea. You need internal PKI for WiFi.

letsencrypt was always about moving the public internet off of http, it doesn't really make sense to use it throughout your internal network. but if you really want TLS and ACME for auto renewal, other solutions are available: https://github.com/smallstep/certificates

You could try step-ca: https://github.com/smallstep/certificates. There’s an OIDC provisioner for SSO and you can sign (short-lived) SSH certificates with it.

You could also check out out Step CA: https://github.com/smallstep/certificates and the accompanying CLI. It has an ACME server and other methods for requesting certificates. It can work/integrate with your existing root(s), too.

This is a lot more complicated setup but it works for me. I run a private CA called step-ca from smallstep and it provides CA and ACME endpoint. I use a .home domain. The trick is the validation for non-http devices which is typically the DNS-01 challenge. For this, I have unbound in pfsense setup to work with acme-dns so I can keep everything internal. Again its complicated but if your learning cyber security it might help get a handle on all things TLS. Btw way behind the scenes I think the ACME plugin is really just running acme.sh bash script which is really good. Final reminder as other have stated. Private CA is great but you need to distro the roots and intermediates out to your clients for trust. If all your trying to do is have an https web gui for pfsense from one device its pretty easy.

Just a little heads up https://smallstep.com/certificates/

Step-ca: Not web based, but the CLI is pretty user friendly: https://smallstep.com/certificates/

I was just looking at https://smallstep.com/certificates a few days ago. It looks like they have an operator that fits your description as well as example docs for setting up inter-microservice mtls.