Scenario: I am hosting a website for a my client, who we'll call S. S owns the domain s.com and I own the servers that actually host the website. S now wants to enable SSL on their website.

I have generated a private key and CSR on my server, and sent the CSR to S so that they can submit it to their CA.

However, like all clients, S is cheap. They don't want to spend the money on a new certificate. Instead, they want to give me their existing SSL certificate for *.s.com and its corresponding private key. This certificate and key is already in use by S and some of S's other vendors.

I already know that this is a bad idea, but why? What problems does this cause now and potentially in the future?

For bonus points, does sharing a private key like this cause any problems in the context of PCI standards?

  • Not necessarily from a security standpoint, but some cert providers charge per-server; if S is cheap, then they probably bought a 1-server cert... Dec 14, 2012 at 17:08
  • @jimbobmcgee that wouldn't make a great deal of sense for a wildcard cert.
    – lynks
    Dec 14, 2012 at 17:44
  • @jimbobmcgee: That is a good point, but I checked the issuing CA's policies, and they allow installation of the cert on an unlimited number of servers.
    – josh3736
    Dec 14, 2012 at 20:04
  • @lynks - might not make sense, but still happens. And there is no reason you couldn't serve www.example.org, secure.example.org, example.org and images.example.org from the same server. Good that it is not limited in this instance, though. Dec 17, 2012 at 12:10
  • ~ $120/2 years gets you unlimited certs from startssl (I don't work for them). They have a reseller program too Mar 18, 2015 at 20:56

3 Answers 3


There are several reasons why wildcard certificates are bad:

  • The same private key has to go on the systems that have different security levels, so your key is only as good as your least-protected system. Giving it out to third-party vendors is a really bad idea, as then it completely escapes your control.
  • You have to keep meticulous records that show exactly where your wildcard private key is installed, so that when you have to replace it, you don't have to play "Where is Waldo" across all your sites.
  • Most importantly, if the private key and wildcard certificate are stolen at any point, the attackers can then impersonate any system in that wildcard space. Common mistake is to say "we'll use wildcard certs on low-security systems, but named certs on all important systems" -- you have to do the exact opposite! If the attackers have *.s.com, they can impersonate any domain in .s.com space, regardless if it's using any other certificates. So if you have "www.s.com" with a wildcard and "login.s.com" with a one-off cert, attackers can impersonate "login.s.com" regardless of what's on "login.s.com".
  • The easiest way to take advantage of stolen wildcard keys is by DNS poisoning or via rogue wireless APs.

All that being said, you have to evaluate the risks. If your friend S is already giving out this wildcard cert and key to all the vendors, then refusing to accept it doesn't lower his risks in any significant way. You'll just appear obstinate and uncooperative and lose his business. Do your best to educate, but also understand that some people just won't care.

If, however, he's bound to conform to PCI-DSS, then I'm pretty sure he's not compliant, as I think you're supposed to have logs of all access to private encryption keys. I'll let others more familiar with PCI-DSS expand on that.

  • Also - the client should be aware of what the agreement is with the certificate provider. Was there an agreement on how the keys would be protected or distributed? If this is an expensive certificate, there's usually some level of control on how it's created to provide better assurance of identity. I wouldn't be suprised to hear that the cerficate was issued to a specific corporation and they are now in violation of their agreement with the certificate vendor. Dec 28, 2012 at 15:03
  • Just sent this link to a guy who emailed me saying, "I just spoke to our lead developer. Its not a bad practice for us to have the private key…”
    – ngoue
    Feb 13, 2017 at 21:01
  • 3
    You, sir, need a new lead developer.
    – ngoue
    Feb 13, 2017 at 21:01

Whoever has access to the private key used by a SSL server has the technical power to:

  • Impersonate any server with a name matching that which is inscribed in the certificate.
  • Decrypt sessions which have been passively eavesdropped (unless the SSL session uses one of the "DHE" cipher suites which provide perfect forward secrecy, but such suites are rarely selected by default, someone must configure them explicitly).

So giving the same private key to many people is really trusting them all, and making them trust each other. Remember that "someone you trust" is an expression which really means "someone who has the power to betray you".

On a general basis, once a secret value is known by more than two people, then it is no longer secret, only kinda discreet. Also, you cannot force forgetfulness, so if your client S wants to cease doing business with one of the vendors to which S gave a copy of the private key, they have to cancel the whole thing (revoke the certificate, create a new one with a new key, and distribute it) -- alternatively, S can go one level up on the scale of gullibility, and just assume that everybody is honest and competent, and that vendors with which they no longer have any business relationship will nonetheless take care of their private key, not having it leaked through a backup tape or an indelicate intern.

Also, support for wildcard certificates is known to be a bit flaky, since they have historically been a source of trouble (not per se, but they amplify the power of nuisance of an evildoer who gets to steal the corresponding private key). Browser vendors tend to restrict them in arbitrary and changing ways.

There are CAs who provide SSL server certificates for free. How cheap do you have to be, to find free certificates too expensive ?


Using the same certificate on many (trusted) servers does not cause problems by itself.

The main problem will be in the case of the private key falling into the wrong hands (from any of the many vendors, you included).

  • It's harder to know about a breach – if many people/machines have the cert, the probability of a breach increases, and the probability of finding out about the breach decreases. If S.com is a relatively high-value target, using the same cert on all services also means potential hackers can pick and choose the weakest server to exploit.

  • When the certificate has to be revoked, all vendors must immediately replace the certificate with a new one to avoid clients rejecting it. This also means that the client might not want to revoke the cert (as it would "cause too much hassle"). If different vendors had different certs, only the leaked cert would have to be revoked, and only that single vendor would have to install a new cert.

You must log in to answer this question.

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