Is there any legitimate reason to install yourself as a root CA?

Question

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.

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, Dec 01 '15 at 09:49
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, Dec 01 '15 at 09:50
@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, Dec 01 '15 at 11:43
@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, Dec 01 '15 at 12:05
No sane corporation will use a wildcard cert without a LOT of consideration: losing control over one of these is a real hassle. Additionally, wildcard certs aren't available for sub-domains, you can't get them for code signing, or email, etc. — Stephane, Dec 01 '15 at 13:16
@Stephane If they lose control over one they can uninstall it from all the computers. — user253751, Dec 01 '15 at 19:52
Your question asks "is there any reason?" (the answer is "yes, duh") but your title asks "is there any *legitimate* reason?". Also, what reasons are legitimate? — user253751, Dec 01 '15 at 19:54
@immibis legitimate being reasons that don't involve tampering or "spying" (for want of a better word) on user interaction. Essentially, what can you do with that that isn't a MITM attack — Dan, Dec 01 '15 at 19:56
There's the trivial case, where the company in question is a CA... — Ben, Dec 02 '15 at 05:07
@Ben True, though I would assume for the vast majority of companies (myself included) are not CAs — Dan, Dec 02 '15 at 09:18
@DanPantry Actually, most companies do now have their own PKI infrastructure, and are therefore acting as Certificate Authorities. What they're not, however, is publicly trusted by default. — Dan, Dec 02 '15 at 11:00
@DanPantry "Most" might have been a risky word for me to use, but it's certainly very common now. I generally only need to request public certs when it's expected that non-corporate machines, outside of the network, will be utilising whatever the technology is. Inside, it's nearly always a case of simply requesting an internal cert. It's not a real answer, because your question is very specific, but a lot of my certificates are for securing internal services talking to internal services - it'd be a complete waste of funds to use public certs there — Dan, Dec 02 '15 at 11:03
@Philipp `There is nobody you can trust more than yourself`. We can never know. — Aloha, Dec 03 '15 at 00:55
@PandaLion98 Indeed, "someone I can trust more than I can trust myself" is a very low bar; it's still a bar few humans have ever even come close to clearing. — Matthew Najmon, Dec 04 '15 at 01:54
Use [Let's Encrypt](https://letsencrypt.org/) and you don't have to worry about this all. — rugk, Jul 21 '16 at 13:29

Philipp · Accepted Answer · 2015-12-01T10:27:09.813

103

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.

edited Dec 01 '15 at 10:27

answered Dec 01 '15 at 09:56

Philipp

49,017
8
127
158

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 Dec 01 '15 at 09:57
2

This is only the case as of November 1. Certificates signed before July 1 this year will not be revoked until October next year. (Source: [Comodo](https://support.comodo.com/index.php?/Default/Knowledgebase/Article/View/722/16/).) It is a good that these are going away, since because you can't claim ownership over an internal name, _anyone_ could have gotten a certificate for it anyway. – user2428118 Dec 01 '15 at 14:46
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 Dec 01 '15 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 Dec 01 '15 at 14:56
@Philipp You're right, I should have read it more carefully. – user2428118 Dec 01 '15 at 14:59
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. – Ian Ringrose Dec 01 '15 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. – Zach Lipton Dec 01 '15 at 20:21
2

I tend to think that's a good trend. Any application that has a password should really be using some form of encryption; even if it's only internally accessible, I don't especially want my passwords flying around in the clear on *any* network. – jpmc26 Dec 02 '15 at 01:06
I worked for a company that used the Active Directory login for the proxy. The proxy used basic authentication. I never bothered turning promiscuous mode on on my NIC and sniffing everyone's password. But I did promptly use 'Password1' for my password there. – Wayne Werner Dec 02 '15 at 14:00
@IanRingrose ... or just don't let the public name server resolve the name. – Paŭlo Ebermann Dec 02 '15 at 19:10
This is usually done in a corporate environment to enable https traffic monitoring. The networks certificate server is likely providing it's own ssl certificates for external https sites. This allows all *secure* content to be decrypted and monitored. If you're using a corporate network and believe your https traffic is private, think again. – user1751825 Dec 03 '15 at 00:42
Technically HTTPS shouldn't be neccessary in an internal network, because it should be quite possible to enforce IPSec on every - every - connection. In practice, it is somewhat harder because IPSec is a lot of trouble to set up right and very few people know how to do it (or have even tried). – Ben Dec 03 '15 at 10:04
1

@ZachLipton: Not if you are a larger company that has several hundred internal webservers, a few dozen teams to manage them, and don't want the team that manages the engineering data servers to be able to impersonate accounting, or vice versa. And as soon as you want to use client certificates, everything but rolling your own CA becomes impractial anyway, for financial *and* handling *and* security reasons. – Guntram Blohm Dec 04 '15 at 12:39

score 18 · Answer 2 · answered Dec 01 '15 at 09:52

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.

score 11 · Answer 3 · answered Dec 01 '15 at 20:32

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.

score 10 · Answer 4 · answered Dec 01 '15 at 13:23

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.

score 6 · Answer 5 · answered Dec 01 '15 at 20:15

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.)

user1751825 · Answer 6 · 2015-12-03T03:16:43.190

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.

Plus one for the answer we don't like. This is like a dark pattern for network security. — Jeff, Dec 04 '15 at 04:54

score 2 · Answer 7 · answered Dec 02 '15 at 17:43

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.

Is there any legitimate reason to install yourself as a root CA?

7 Answers7

Linked