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.

  • Hug? What does "pentest" even mean?
    – curiousguy
    Commented Oct 19, 2011 at 2:14
  • 2
    @curiousguy pentest is an abbreviation for penetration testing. Penetration testing is a controlled scenario when a person or team act as adversary and attempt to penetrate the protections in place (bypass security).
    – this.josh
    Commented Oct 19, 2011 at 6:49
  • 1
    @this.josh So what security protections did they bypassed?
    – curiousguy
    Commented Oct 19, 2011 at 10:53
  • 1
    @curiousguy that's what I'm hoping the answers to this question might reveal :)
    – user185
    Commented Oct 20, 2011 at 8:36
  • Consider that poor phrasing on my part. It would more likely be an issue for an audit. E.g. from OWASP: "You should refrain from using wildcard certificates. Though they are expedient at circumventing annoying user prompts, they also violate the principal of least privilege and asks the user to trust all machines, including developer's machines, the secretary's machine in the lobby and the sign-in kiosk.".
    – AviD
    Commented Mar 10, 2013 at 13:42

4 Answers 4


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:

  • 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 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:


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 matches non-wildcard elements in the certificate.
  • CA require 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 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.

  • 1
    I'm still not convinced there are no scenarios where this would put the web server at risk. For example, if the wildcard cert is shared between two sites, of different sensitivity levels - say, a public website and an internal accounting app - vulnerabilities in the publicly accessible website could possibly affect the private accounting app, no?
    – AviD
    Commented Mar 11, 2013 at 14:42
  • 2
    Ah, that's something other. It is not the wildcard which triggers a vulnerability, but sharing the private key. If a server contains a private key, and the server is hijacked, then the key is revealed and this impacts every other system using that key (although, arguably, the problem is still on the client, not on the server: you won't penetrate a server by knowing its SSL private key, but you may create a fake server or decrypt client/server traffic). Commented Mar 11, 2013 at 14:49
  • 1
    Well, yeah, but sharing the cert (and of course the private key) between more than one site is kind of implied by having a wildcard (otherwise, why bother?). This seems to be one of the risks of using a wildcard cert. Moreover, it's not just about sharing the private key - even if you only install the cert on the low-trust server (e.g. public website), it will not help to have a specific, non-wildcard cert for the more-sensitive site. Having a wildcard cert is like the joker in the pack - it can be absolutely anything you want it to be.
    – AviD
    Commented Mar 12, 2013 at 7:56
  • 3 years later: Prediction 1: correct (in my browser, at least, although I think it may just be graying out all subdomains). Prediction 2: No idea since I don't buy them. Prediction 3: it seems not yet; not sure of if browsers are moving in that direction.
    – jpmc26
    Commented Mar 21, 2016 at 17:56
  • 1
    This is a very descriptive answer but it does not describe why it is bad for a legitimate operator to request and use a wildcard certificate. It only notes how badguy.com could make use of a wildcard certificate. Commented Aug 28, 2019 at 18:56

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.

  • 4
    To be quite clear, this isn't an issue with wildcard certificates at all - there is nothing about them that makes them inherently less secure. They can be (and indeed, are often) used for only a single service (see the linked question - that's exactly how that asker would have deployed it), and a non-wildcard certificate is just as commonly deployed in multiple services. While use for multiple services certainly increases risk, it's complete nonsense to make a blanket statement that implies that a wildcard certificate will "fail a pentest" where another certificate would not. Commented Oct 18, 2011 at 16:24
  • @ShaneMadden you are basically saying the same thing, I did. But the person who made that statement might not see your reply to my posting. Commented Oct 18, 2011 at 16:45
  • Yeah - I completely agree with your answer and was just trying to elaborate a bit, sorry I didn't make that apparent. Commented Oct 18, 2011 at 17:13
  • 1
    "While use for multiple services certainly increases risk". It's not so much about what services the certificate is intended to be used for. It's about what services an attacker who steals the private key could use the certificate to impersonate. Commented Dec 2, 2015 at 15:11

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:

Qualys SSL Labs screenshot for youtube.com cert



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

You must log in to answer this question.