Follow up from comments on another question.
Is there any reason as to why you might install yourself as a root CA on your own network? The only reason I can think of is forcing computers in the network to trust your own self signed certificates instead of getting them digitally signed by a 3rd party CA.
A custom CA is required if you want to use https on your corporate intranet. 3rd party CAs can only give you certificates for public domains. They won't give you certificates for intranet.local or any other hostnames which are only routed in your own network. So when you want to have a certificate for your intranet or for the web interface of your own servers, you need to add a custom CA and sign it yourself.
You might ask yourself "Why would I use https on my own network"? There is currently a trend to implement everything as a browser-based application. This means more and more processes are handled through internal web interfaces, including sensitive ones. For example, our company is currently implementing a web-based intranet application to view our own payslips (and hopefully only our own). But in larger organizations, the internal network can become so large and complex that you can't really speak of a private LAN anymore. Eavesdropping from internal attackers becomes a possibility which can not be handwaved away, so internal encryption becomes a reasonable precaution.
Certificates are a matter of trust.
CA are supposed to be trustful globaly so we can rely on them even if we don't know each other.
In cases where you are communicating with only people you know or .... yourself, like when you are responsible of a network of different machines, you can choose to rely on yourself more than to rely on a CA that in fact, you don't know.
An example could be when you want to create tunnels via openVPN between computers you manage.
Intentionally "spying" on yourself for debugging purposes, using proxy tools like Fiddler or Charles to capture https traffic.
These tools are often used by mobile app developers, among others, to debug client-server communications. A root CA can be generated and installed on a mobile device, a computer set as that device's http proxy, and all web traffic, including details of headers, cookies, etc... will be displayed for the developer.
This is useful in understanding performance of network requests, deciding whether to blame the client or the server for a bug, or reverse engineering existing APIs.
Another (additional) answer is that private CA have a different security domain than public CAs.
A public CA will certify public information: the fact that the owner of the private key matching has particular public right at the moment of the request. they don't really care about internal segregation and will definitely not secure internal resource (for instance, the example provided by @Philipp about host names not belonging to the public DNS).
A private CA is all about securing your internal resources: it is designed to ha ve a more limited domain of application: it will only work within the context of your network. Therefore, it can be used to secure internal communication and provide internal authentication which have little or no meaning outside the network.
Also, they are a bit safer to use: you can delegate access more easily with them. For instance, the admin of a local branch could have the necessary right to issue certs for systems and people under his control without having to delegate the complete corporate identity to him.
Another reason an organization might want to install a root certificate is for content filtering. My high school had a content filter just before the firewall, which was intended to prevent students from accessing various types of content. However, it didn't do a very good job of filtering HTTPS connections--sometimes it would block based on IP address, but it tended to be very heavy handed on some sites (blocking the entire IP address) and not filter at all on others (giving full, unfiltered access). For example students quickly figured out that they could access Facebook if they typed https://facebook.com. (I think the content filter was old enough that it didn't support Server Name Indication, either.)
Shortly before I graduated they installed a new content filter which provided full filtering on HTTPS traffic. They installed a root CA on all the computers, and the firewall would create certificates on the fly for HTTPS websites. This allowed URL-based blocking (rather than the much coarser-grained hostname-based blocking they would have had to use had they not spoofed the certificates), so for example they could now allow students to watch YouTube videos while blocking others.
Interestingly, the firewall had an option to sniff traffic to banking sites, along with a big warning to leave the option disabled for security. (Presumably it had a whitelist of financial domains.)
If I was running a corporate network and wanted to keep an eye on what my employees were doing, I would create certificate server, and configure all of the client computers to only trust certificates from this server. I would then have this server issue it's own certificates for any sites my employees might need to use. My employees would then happily use their gmail, facebook etc. While blissfully unaware that the certificate their browser is happily using is issued not by an external CA, but by my own internal network CA server. Their full unencrypted network traffic can then be logged and monitored by the network proxy server.
I have an opinion on this (and it is only an opinion).
"The only reason I can think of is forcing computers in the network to trust your own self signed certificates instead of getting them digitally signed by a 3rd party CA."
If you only add one root CA then its unlikely to be viewed self signed certificate in the traditional sense, its a certificate signed by an internal CA (although that CA certificate will be self signed). Unless you whack that same cert on every box which would be a very stupid idea. You just sign the correct cert with it and then lock that CA away again never giving it network access and sneakernet signing requests when needed.
Additionally, its preferred (by me) to a wildcard certificate as a compromise of a host can only lead to interception to that one host (which it would likely do anyway) rather than everything in that domain.
Finally a third party CA is to me an unnecessary line of trust on an internal network. You can control your own internal policies but not theirs - of course if they are corrupt/compromised they can still screw you over unless you trust ONLY your own CA.So I have mixed feelings on this point.
If you protect that CA certificate sufficiently, it is no less secure than a third party, and in my view more secure than a wildcard certificate.
