> Setting up your own private CA gives you complete control and flexibility to customize your certificates to suit your needs. This is probably the second stro

> Setting up your own private CA gives you complete control and flexibility to customize your certificates to suit your needs. This is probably the second strongest point in the article, but one that is also probably limited in necessity. Many servers standardize on TLS formats and algorithms. At least on my internal network, I've not had a use case that I couldn't use one of LetsEncrypts PKI for. > If you decide to do the same, it means that you can’t use publicly trusted CAs to issue certificates to your internal web apps and services, DevOps build servers, testing resources, IoT devices, or other entities with domain names that are only valid in the context of an internal or private network (e.g. example.local, 10.0.0.0/8, or even localhost). The solution is to get your own CA. You shouldn't be using non-routable local domains either. Internal domains should be owned externally and the authoritative servers should not propagate externally. > The solution is to set up your own CA to issue certificates for your internal infrastructure. That way, you can keep your internal hosts from showing up in a public CT log. The last point is the strongest, imo. Transparency means that you have created maps of your network - past and present. That said, if you're relying on secrecy to be sure, that is no form of security. Obscurity these days buys you time by wasting the attackers time, but it's not a great strategy, imo. It'd be like if the military assumed nobody had ever seen a base from above. She goes on to talk about configuring your own internal CA. Is there anything prohibitive about using LE PKI to run an internal CA? Maybe short expiry? I wish they'd spent the meat of the article on this rather than concluding with "don't".