[zeta0134]

The primary issue with wildcard certificates is that it encourages certificate reuse between server environments. Even the act of transferring keys around carries a certain degree of risk. With a wildcard certificate though, say you have a very secure shopping site, and a user run forum:

  - https://checkout.example.com/
  - https://forums.example.com/

Your wildcard certificate for * .example.com covers both domains, and can be shared between both servers. Nice! You've saved a bundle of money on certificates. But there's now a security risk: Say an attacker manages to compromise forums.example.com through some vulnerability in the forum software, and steals the private key for * .example.com. They can now set up their own server hosting checkout.example.com, successfully execute a Man in the Middle attack, and steal sensitive customer data without the end user being any the wiser.

Issuing separate certificates prevents this scenario by enforcing a separation of responsibilities. If each server has its own set of keys, then a security compromise on forums.example.com does not spill over to checkout.example.com, because the key used on one server is useless to impersonate the other. Obviously a key compromise at all is a bad situation, but you want to architecture your environment so that a compromise has the least potential to do damage, and that's the basic argument against wildcard certificates.

[sk5t]

Good writeup. In addition, using discrete certificates makes managing them easier, whether for renewal, squashing SHA-1 and the like, or revocation. It can be a big headache to track down all the places a wildcard cert worms its way into at large, penny-pinching orgs.