Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
In a comment on this answer, AviD says:
"There are numerous security issues with wildcard SSL certs."
So, what are the problems? I understand that the same private key is being used in multiple contexts, but given that I could host all of my applications under the same host name I don't see this as a 'new' issue introduced by wildcard certificates.
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 Web sites, there are four main actors:
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 benefits 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:[email protected]/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 setup 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:
I actually expect all three measures to be applied within the next the years. I could be totally wrong about it (that's the problem with predicting the future) but this is still my gut feeling.
Nitpickingly, 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. Traveling private keys are a security risk in their own right; the more a private key wanders around, the less "private" it remains.
It is bad practice to spread the same private key across multiple servers providing different service: Any exploited security issues in any service will reveal the private key used for everything.
But it is common to use wildcard certificates to isolate user contributed web content in user specific subdomains to leverage the same origin policy. The same approach is commonly used to render untrusted portlets. It's part of the Open Social "standard".
At my workplace we develop a software which contains an open social implementation and uses the wildcard setup. Customer installations have been subjected to penetration tests. The wildcard setup was not criticized.
Ultimately, many of the vulnerabilities noted in these answers come from mixing levels of trust. But if you understand how wildcard certs work, you can mitigate these vulnerabilities for particular use cases. I think that explaining this in more detail will improve the usefulness of this question and its answers.
Unless all of the systems in your domain have the same trust level, using a wildcard cert to cover all systems under your control is a bad idea. But you can use DNS subdomains as a segmentation tool. As Hendrik said, since wildcards do not traverse subdomains, you can restrict a wildcard cert to a specific namespace. For example, if you had a CDN farm, you could wildcard just *.cdn.example.com. This keeps hosts in example.com itself (like www.example.com) separate, and you could issue a separate cert for www.example.com.
As AviD mentioned from OWASP: internal workstations, development systems etc. belong in lower trust levels. However, hosts like these should be in their own internal domain space anyway (like prv.example.com). Since wildcards do not traverse subdomains, a *.example.com cert cannot be applied to prv.example.com hosts. (This would keep public and private properties separate, but obviously does not segregate private properties from one another. Other subdomain wildcards could be used, mapped to appropriate trust levels).
While this eWeek article notes that the private key can be shared across multiple hosts, this SSLShopper rebuttal says that some issuers (like DigiCert) allow you to generate separate private keys for each wildcarded host. This does reduce some of the usefulness of wildcard certs, but definitely mitigates the shared-private-keys problem, and might be helpful in some circumstances. Otherwise, this Entrust article and the whitepaper PDF that it references discuss best practices for managing private keys when used with wildcard certs.
Finally, resorting to argument by authority... if Google is using wildcard certs for some of their properties, they must not be universally bad:
:-)
Ideally the list of services a certificate/key can be used to impersonate should be the same as the list of services that certificate/key is intended to be used for.
Lets say you have a domain example.com. You set up various hostnames under that domain www.example.com catpictures.example.com users.example.com . All are hosted on the same server so you get one certificate to cover them all.
Now lets say you set up secure.example.com on a more highly secured server. Lets say you get a seperate cert for that server.
Now consider what happens if the private key corresponding to the certificate on the first server gets stolen.
If it was a certificate for *.example.com (a wildcard cert) then the attackers can use it impersonate secure.example.com
If it was a certificate for www.example.com catpictures.example.com and users.example.com then the attackers cannot use it to impersonate secure.example.com
