Risks Using Wildcard SSL Certificates
- Joshua Drummond
Policy
- For a single hostname on a single IP address, a single InCommon SSL certificate should be requested.
- For multiple hostnames on different IP addresses (even if on same physical machine), separate InCommon SSL certificates should be requested for each.
- For multiple hostnames on same IP address, a single InCommon Multi Domain SSL (or InCommon Unified Communications) certificate should be requested using the Subject Alternative Names (SAN) field enumerating the multiple hostnames.
- For multiple hostnames on same IP address, under exceptional circumstances (i.e. literally hundreds of hostnames on same IP or they change weekly) you can petition to use an InCommon Wildcard SSL Certificate. After acknowledging the risks below, a request and justification should be submitted to the UCI RAOs (security@uci.edu) for review and possible approval. If approved, the maximum term is 1 year for expiration of wildcard certificates rather than up to 3 years for the others.
Risks
- 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.