Security by Obscurity is often misused. SBO is bad or insufficient when it’s the only control you have, when it’s not it’s just called OPSEC…. There is absolu

Security by Obscurity is often misused. SBO is bad or insufficient when it’s the only control you have, when it’s not it’s just called OPSEC…. There is absolutely no reason to leak unnecessary information that can describe how your system is built, how many components are there and giving out information such as internal service names that make exploitation of various vulnerabilities such as SSRF easier. Heck you can look up just how many bounties Google has paid out because everyone is aware of what “dogfood” is these days and that it’s the nomenclature for their internal test environment/endpoints. You will never have a system that has no design or implementation flaws. The less information an attacker can gain about it the less likely they’ll be able to either discover a flaw or successfully exploit it. Relying on external CA’s opens you to additional supply chain attacks it’s not uncommon for highly regulated industries or high security systems in general to not only use an internal CA but to break the public chain of trust altogether by removing the public certs from the system. As far as the complexity goes yes running a CA adds another component but there are plenty of good solutions out there that abstract the complexity. Most of the “complexity” is around constructing the CSRs and getting the certificates securely deployed during the deployment or post deployment configuration management stages anyhow which a 3rd part public CA doesn’t solve. And tools like Istio and other service meshes usually allow you to automate all of that fairly easily regardless if you use an internal or external CA. lastly if you can’t figure out how to manage root CAs on your endpoints you shouldn’t do anything with PKI regardless of who issues your certificates.