This is a pretty nice guide, though it misses some steps I'd consider important. If you're making a CA for internal use today, I would highly encourage you to use Name Constraints. Name Constraints allow you to specify that your CA will only be used to sign domains you pre commit to. This means you can add your internal CA to your system trust stores on all of your corporate systems and not worry about it being abused to MITM your employees connections to the wider internet. (If that is a feature you'd like to have, I would be happy to expound further on why that's a bad idea)
I'm giving a workshop in a few weeks at Bsides Seattle[1] about this - Pick up a Yubikey and come play with PKI with me.
Given that traffic inspection for user and service proxies rely on MITM traffic inspection for many forms of IPS/IDS beyond basic SNI signature detection - I'd love to hear more!
I'm not necessarily suggesting it should be mandatory - I remember the pain of introducing Zscaler about a decade ago and the sheer number of windows apps that simply broke, leaving a trail of complex PAC files - but not enough to warrant off the solution.
I would assume the half way house would be to leave Name Constraints off your offline CA, maintain (at least) one intermediary with constraints turned on for regular certificate lifecycle management for internal certs, and a dedicated intermediary that is only used to generate the MITM certs?
I'm giving a workshop in a few weeks at Bsides Seattle[1] about this - Pick up a Yubikey and come play with PKI with me.
[1]https://www.bsidesseattle.com/2025-schedule.html