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?

  • 2
    Adding all domains as SANs is far from keeping things simple. When you add new one, you have to have it signed again anyway and then you have to update it anyway. To keep things simple you should use a wildcard certificate.
    – Jan Hudec
    Sep 3, 2014 at 4:58

3 Answers 3


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.

  • 2
    couldn't you have 1 main certificate and use that to sign the publicly viewable certificates (those on the test servers and such), Sep 2, 2014 at 12:21
  • 8
    you can't really do that. Certificates are signed for specific purposes and while its technically possible to have one for signing, CAs just won't sell you that type because they cannot verify what you are signing. You can do this with your own self-certified certificate structure, but this requires adding a new root certificate on the clients.
    – JamesRyan
    Sep 2, 2014 at 15:15
  • @JamesRyan The CAs can sell you a certificate with an extension restricting that you can only sign certs below your domain. Note it will be more expensive than a wildcard certificate.
    – Ángel
    Sep 3, 2014 at 15:01
  • @Ángel can you link to any CA offering this? Browsers do not implement that extension.
    – JamesRyan
    Sep 3, 2014 at 15:30

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.

  • I presume it would be a wildcard certificate in which case 1 does not apply.
    – Jan Hudec
    Sep 2, 2014 at 22:08
  • 1
    @JanHudec the question specifically says that it's not a wildcard cert -- that they have one cert with several Subject Alternate Names (SANs).
    – Moshe Katz
    Sep 2, 2014 at 23:46
  • 1
    @MosheKatz: Hm, true.
    – Jan Hudec
    Sep 3, 2014 at 4:56

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.

You must log in to answer this question.

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