Is there a security issue in using the same certificate for all a company's services?

Question

We are a small startup. One of our products is a B2B web service, accessible through its https://service.example.com canonical URL.

For testing purposes, that service also runs on different testing/staging/integration environments, such as https://test.service.example.com , https://integration.service.example.com, etc.

We also have collaborative tools such as a bug tracker or a wiki. They run also on machines provided by our hosting provider. Their URLs are e.g. https://wiki.example.com, https://bugs.example.com.

To keep things simple, we use a single certificate (for example.com), and have added all the URLs above as Subject Alternative Names to that same certificate. All our servers thus use the same certificate.

Is there any security issue in doing so that we should be aware of? If yes, what would have been the "correct" way of doing things?

Answer 1

Using the same certificate does not in any way affect the fundamental security of the connection that is established using it.

The only possible "weakness" introduced by using the same certificate is that if that certificate expires or is leaked all your sites will be affected. Since this certificate is on multiple servers and some of them might be test servers with less security there is the possibility that the private key of that certificate can be inadvertently leaked or exposed from one of these unchecked servers. This is is certainly not a failure of the security provided by the certificate, but rather a failure in keeping the certificate's private key secret.

The alternative would be to use separate certificates for all your sites which would mean that you would have that administrative burden of having to renew, protect and monitor multiple certificates.

If you properly protect the private details of that one certificate there is no reason why using it would introduce any additional security concerns.

Answer 2

There are two weaknesses with this model.

1) Information leakage. Including the dev/qa/etc URLs in the certificate allows one to more easily find these environments. Often they are less secure then the actual production environment since it is used to test the code. If you have other controls in place to limit access such as router/firewall ACLs (or something else) then this isn't as important.

2) Compromise containment. I highly recommend dedicating a cert just for production. If for some reason your dev/qa/etc environment gets compromised and access to the private key was achieved, then one must question if production traffic has been compromised (i.e. MITM). SSL certs are very affordable nowadays that again I would suggest dedicating a cert just for production.

Answer 3

As @anon said, the main issue is Information Leakage. Anyone who goes to any one of your sites can see the names of all the others listed in the certificate (unless you choose to get a wildcard certificate; however, a wildcard certificate won't let you add the extra level test.service..., because the wildcard cannot contain dots in it). If you don't care that visitors to service can see that wiki, bugs, etc. exist, then that isn't a problem.

In general, I prefer to use self-signed certificates for testing sites. That just gives an additional indication that the site is not in production. I started doing this after I had a number of orders come in on the testing site for an online store. (The fact that it said in big bold letters at the top of every page not to use the site didn't seem to matter. It also turned out that most of them were fraud orders, but that's not the point.) Having the "this site is not trusted" warning pop up help make people stop trying to buy on that site.