Explain wildcard certificate risks & vulnerabilities.

To understand wildcard certificate risks, you should understand that a "wildcard certificate" is a certificate which contains, as possible server name, a name which contains a "*" character. Details are in RFC 2818, section 3.1. The bottom-line: when the server certificate contains *.example.com, it will be accepted by clients as a valid certificate for any server whose apparent name matches that name.

• In the certification business for Websites, there are four main actors:
  
• The SSL server itself.
  
• The vendor of the Web browser which the client will use.
  
• The human user, who controls to some extent what the client browser will do.
  
• The CA who issued the certificate to the server.
  

Wildcard certificates don't imply extra vulnerabilities for the SSL server; indeed, the SSL server has no interest in looking at its own certificate. That certificate is for the benefit of clients, to convince them that the public key contained in the certificate is indeed the public key of the genuine SSL server. The SSL server knows its own public/private key pair and does not need to be convinced about it.

The human user has no idea what a public key is. What he sees is a padlock icon and, more importantly, the intended server name: that's the name at the right of "https://" and before the next "/". The Web browser is supposed to handle the technical details of verifying that the name is right, i.e. validation of the server certificate, and verification that the name matches that which is written in the said certificate. If the browser does not do this job, then it will be viewed as sloppy and not assuming its role, which can have serious commercial consequences, possibly even legal. Similarly, the CA is contractually bound to follow defined procedures for identifying SSL server owners so that fake certificates will be hard to obtain for attackers (contract is between the CA and its über-CA, recursively, up to the root CA which is itself bound by a pact with the OS or browser vendor, who accepted to include the root CA key in the OS or browser under defined conditions).

What this amounts to, is that the browser and the CA must, in practice, pamper the user through the verification process. They are more or less under obligation (by law or, even stricter, by business considerations) to prevent the user from being swindled through fake sites which look legit. The boundary between the user's job and the browser/CA job is not clearly defined, and has historically moved. In Days of Yore, I mean ten years ago or so, browsers just printed out the raw URL, and it was up to the human user to find the server name in it. This lead forged site operators (i.e. "phishing sites") to use URL which are technically valid, but misleading, like this one:

https://www.paypal.com:payment-interface-login-session@xcvhjvb.com/confirm.html

Since human users are, well, human, and most of them read left-to-right (most rich and gullible scam targets are still in Western countries), they will begin on the left, see www.paypal.com, stop at the colon sign ("too technical"), and be scammed.

In reaction, browser vendors have acknowledged that the URL-parsing abilities of human users are not as good as was initially assumed, and thus recent browsers highlight the domain part. In the case above, this would be xcvhjvb.com, and certainly not anything with paypal.com in it. Now comes the part where wildcard certificates enter the game. If the owner of xcvhjvb.com buys a wildcard certificate containing "*.xcvhjvb.com", then he can set up a phishing site called:

https://PayPal-payment-interface-login-session.xcvhjvb.com/confirm.html which will be accepted by the browser (it matches the wildcard name), and is still likely to catch unwary users (and there are many...). This name could have been bought by the attacker without resorting to wildcards, but then the CA employees would have seen the name with obvious fraudulent attempt (good CA do a human validation of every request for certificates, or at least raise alerts for names which are very long and/or contain known bank names in them).

Therefore, wildcard certificates decrease the effectiveness of fraud-containment measures on the CA side. This is like a blank signature from the CA. If wildcard-based phishing attempts become more commonplace, one can expect that one or several of the following measures will come into existence:

Browsers highlight only the parts of the domain name which match non-wildcard elements in the certificate.

CA requires heavier paperwork and contracts for wildcard certificates (and these will be more expensive).

Browsers deactivate support for wildcard certificates altogether.

I actually expect all three measures to be applied within the next few years. I could be totally wrong about it (that's the problem with predicting the future) but this is still my gut feeling.

Nitpicking, we can also point out that wildcard certificates are useful for sharing the same key pair between different server names, which makes it more probable that the private key will be shared between different server machines. Travelling private keys are a security risk in their own right; the more a private key wanders around, the less "private" it remains.