What issues arise from sharing a SSL certificate's private key?

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.

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.