[dilyevsky]

So exposing your internal infrastructure to the whole world and risking a 3rd party (CA) turning the keys (literally) to your kingdom to someone else is better than someone making a mistake that’s very easy to discover and correct?

> Also, sometimes people need to access documents and emails from home computers and the company may use some devices on which it isn't possible to install the CA

That’s a plus as far most security professionals are concerned

[nsgi]

> So exposing your internal infrastructure to the whole world and risking a 3rd party (CA) turning the keys (literally) to your kingdom to someone else is better than someone making a mistake that’s very easy to discover and correct?

That's not how certificates work. The CA doesn't have your private key. They could theoretically sign a fake certificate with your hostname but that risk is still present if you use a private CA and is mitigated by certificate transparency

[dilyevsky]

Yes, should’ve been more clear on that they sign a cert without your knowledge and hand to to someone performing mitm. How is that risk present when you roll your own PKI and validate against your private CA (or intermediate) only?

Regarding CT I’m not aware of any clients other than browsers actually enforcing that.

[closeparen]

Typically an internal CA adds to the certificate trust store rather than replacing it.

[dilyevsky]

Yes you are correct here (although I’ve seen both methods). At least 3rd party won’t easily know which hostnames to fake though