No, I don't, but it's conceptually pretty easy (the devil is always in the details). I'm sure you could find something on the net describing this better.

What I've done is, first, to block the HTTPS port from going anywhere except to my proxy. If you want to use HTTPS in my network, you have to install my cert. That cert is used to negotiate the HTTPS connection to the proxy. The proxy then has access to the plain-text data stream. If that data stream is a DNS request, then it's diverted to a DNS-over-HTTPS server that I run (which uses my local DNS server to resolve the request). Otherwise, the proxy just transfers the data to and from the destination site using an HTTPS connection from the proxy to the destination.

How do you cope with devices that do not allow the installation of a new CA root?

I suspect the answer is "I don't use them", but that's going to be a blocker for mostly everyone.

> What I've done is, first, to block the HTTPS port from going anywhere except to my proxy. If you want to use HTTPS in my network, you have to install my cert.

But there are a very large number of potential HTTPS ports (a reasonably well behaved system could, as well as 443, use anything that isn't well-known or registered, or which was registered for the particular use, even if the underlying protocol was HTTPS.)

This is giving me some good ideas for my homelab... Thank you!

does this work with apps using certificate pinning?

This does break all sorts of apps/workflows, and it's a pain having to let each and every tool (pip/curl/firefox/java/etc...) know about the cert you want it to know about.