The primary issue with wildcard certificates is that it encourages certificate reuse between server environments. Even the act of transferring keys around carri

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.