...
- All of the usual risks of compromised SSL private keys apply, but when it is a wildcard certificate the impact of exposure is magnified enormously.
- Network Eavesdropping Attack (Passive): if a wildcard certificate is compromised, an attacker with access to the network can sniff and decrypt all of the traffic to all SSL websites for the wildcard domain.
- Man-in-the-Middle Attack (Active): if a wildcard certificate is compromised, an attacker with access to the network can sniff, decrypt, change, and replay all of the traffic to all SSL websites for the wildcard domain.
- Impersonation Attack: if a wildcard certificate is compromised, the attacker can use it to create new hostnames or impersonate existing sites (when combined with phishing, or local host / DNS cache name resolution poisoning) on the same domain as the wildcard domain, leading users to an attacker's site instead of a trusted site even though they see a trusted valid SSL certificate.
References:
- http://www.entrust.com/wp-content/uploads/2013/05/WP_WildcardSSL_July2012.pdf
http://www.incommon.org/certificates/certpick.html
Q6. "I want to just get a single certificate that will work for all the systems in my domain, such as all hosts matching the pattern *.example.org"
That's called a wildcard server certificate. While InCommon offers them, we urge you to avoid using wildcard certificates whenever possible. To understand why, consider the following scenario:
A wildcard certificate is obtained for *.example.org and installed on numerous systems, including a security sensitive health care-related system, operationally critical teaching and learning management systems, the campus identity management system, and the campus student bridge club's server. Those systems have widely varying security profiles.
Assume the bridge club server, run by a volunteer with little or no server administration experience, ends up gets compromised and the wildcard certificate and its associated private key gets stolen. This undercuts the security of all the other systems that rely on that certificate, and because the Bridge Club system was compromised, the wildcard certificate will need to be revoked and replaced on ALL systems using that wildcard cert. This can be a real potential "fire drill."
If you'd used system specific certificates, the compromise of a single system (such as the Bridge Club server) would have had no effect on the security of the other servers, and only that single private key and associated certificate would have needed to be replaced. Do yourself a favor and avoid wildcard certificates when you can.