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.

  • 43
    Isn't that reason enough? There is nobody you can trust more than yourself and CAs usually want money and paperwork before they give you a certificate.
    – Philipp
    Commented Dec 1, 2015 at 9:49
  • 2
    it isn't reason enough to me; a certificate is cheap in the grand scheme of things. Self signed certificates are perfectly fine for development, but I wouldn't want to use them in production.
    – Dan
    Commented Dec 1, 2015 at 9:50
  • 5
    @DanPantry But the come with a cost. A wildcard certificate will cost you 200$, give or take a few. If you're like me, you have 20 VMs in your LAN for downloading, Owncloud, Ampache etc.. You'd hardly want to pay for a domain and a wildcard certificate (or 20 single ones) just for private use in LAN. And don't even get started with certificate authentication ...
    – Sebb
    Commented Dec 1, 2015 at 11:43
  • 6
    @DanPantry Yes, but that's not what a CA will charge for client certificates for each of a few thousand employees. Also, you asked about "your own network" and for me 200$ are a good graphics card or 8TB backup space.
    – Sebb
    Commented Dec 1, 2015 at 12:05
  • 3
    Where can I get a trusted code-signing cert for 200$? Commented Dec 1, 2015 at 21:12

7 Answers 7


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.

  • 13
    This is an interesting point. I didn't factor in the fact that you cannot have internal domains being signed by 3rd parties.
    – Dan
    Commented Dec 1, 2015 at 9:57
  • 4
    @user2428118 CAs creating certificates for private domains is deprecated since July 2012. Personally I don't understand why it took them so long to deprecate that practice, because it is quite irresponsible to certify a domain which means something completely different on each network.
    – Philipp
    Commented Dec 1, 2015 at 14:55
  • 7
    LANs are not as safe as we think - almost anyone that can enter the office can plug something into a free ethernet port. That's a good reason to use HTTPS internally.
    – Agent_L
    Commented Dec 1, 2015 at 14:56
  • 4
    You can use a public domain for internal applications, but then block access to the web server based on source IP address. This is also more flexible when companies merge and networks get combined. Commented Dec 1, 2015 at 16:15
  • 10
    While you can't get a certificate for intranet.local (anymore, and shame on the CAs who would do this), you can get one for intranet.mycompany.com (or just *.mycompany.com, if you're comfortable with the implications of spreading a wildcart cert around more widely), even if that domain is only accessible from within your internal network. This is far better than a root CA. Commented Dec 1, 2015 at 20:21

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.

  • 1
    Plus one for the answer we don't like. This is like a dark pattern for network security.
    – Jeff
    Commented Dec 4, 2015 at 4:54

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .