Wildcard Certs, Not Quite The Star

Edited 20/11/2017

Introduction

Let me start off by stating that wildcard certificates do have a place if used wisely and sparingly. For example a small startup, where certificates can create a large cost (this is changing however with the likes of Let’s Encrypt).  However if they are used in manner where there is not sufficient attention payed to them, this could represent a significant security risk. The purpose of this blog post is to briefly describe what wildcard certificates are and then try show why they could represent such a significant security risk.

Certificates Justification

The reason for requiring a certificate is quite simple. They are a means to reasonably validate that the system which a client is connecting to is in all likelihood the system which the client was expecting to speak to, i.e. confirm that a Man in Them Middle (MiTM) attack hasn’t taken place. To do this, the client will validate the server certificate presented by the server:

1. The certificate has been issued (and thus signed) by a Certificate Authority (CA) which the client trusts.
2. The certificate has been issued for the domain on which the server is running on.
3. The certificate has not expired.
4. The certificate has not been revoked (this is often no the case, see Scott Helme’s excellent blog post Revocation is broken).

In order to perform the validation in step 2, the client will either compare the Common Name (CN) from the certificates Subject field, or the DNS entries in the certificate’s Subject Alternative Name (SAN) field. If the hostname of the server matches either, the client will then trust the certificate so long as the certificate passes all the other validation steps above.

Introducing a Star

Wildcard certificates take the host validation a step further. If the hostname of the server matches the domain or sub-domains to match the wildcard entry, the certificate will be trusted by the client (so long as it passes the other validation checks as well). Like the static hostname, the wildcard entry can appear both in the CN value of the certificate’s Subject field or as a DNS entry in the certificate’s SAN field.

Dangers of Wildcard Certificates

Due to the nature of allowing a wildcard to cover so many hosts, many stick with a single certificate adding additional wildcard entries to the certificate. Take for example the certificate for YouTube:

As you can see there are a large number lot of wildcard entries set in the above certificate, 44 to be precise. Along with all of them being root level domain wildcard entries This single certificate is most likely to be used on several severs, possibly hundreds. And this is where the problem lies. In an ordinary certificate, if the private key were compromised, then only the connections to the individual servers listed in the certificate would be compromised (which is why I prefer to stick to a single certificate per server). If the the private key for above wildcard certificate were ever compromised, it would compromise the secure connections to all the servers which fall under the domains listed in the certificate. Think about it, a single key for possibly hundreds of servers! And this is the problem, how do you effectively and securely handle that key across so many servers as well as most likely different teams? This just compounds the likelihood of the key being leaked. A most recent example includes the leak of the certificate for drone maker DJI:

Good example of why having a wildcard cert can be so dangerous: https://t.co/ujouhBX2EW

— Sean Wright (@SeanWrightSec) November 17, 2017

And this is only where the problem starts. As it stands today there is no clear and effective means to revoke certificates with a 100% confidence as security researcher Scott Helme explains extremely well:

Oh boy, @DJIGlobal published their private key and had to revoke their wildcard cert: https://t.co/RjnOrIKh7H
They replaced it with a new one in Sep: https://t.co/tKLd9BK8vV
Given that the revocation is essentially useless this is a pretty big problem: https://t.co/PlIsSZ88u0

— Scott Helme (@Scott_Helme) November 16, 2017

Another consideration to consider is that an attacker could use the certificate for a server which they host under the wildcard domain. The victim would likely to be unaware about this server. Take the above certificate for example. An attacker could potentially stand up a server with the hostname of evil.youtube.com, and the victim (Google in this case) might not be aware of this rogue server. To an ordinary user, this server will also appear to be legitimate since the browser will trust the certificate.

Other Considerations

Some other considerations of using wilcard certificates:

• If the certificate is revoked, then all servers which use that certificate will need to be updated to use the new certificate. This may or may not be significant work, depending on where there certificate is used (for example on a central WAF) and/or how the certificate is deployed.
• The certificate will expire at some point, which means it will need to be replaced with a new certificate. Much like the point of the revoked certificate above, the same challenges could be face with an expired certificate. If the certificate is not renewed in time, one could face a significant outage.

Effective and Safe Use of Wildcard Certificates

In close I would give the following tips when using wildcard certificates:

1. Protect the private key at all costs. This should always be done, but with wildcard certificates it becomes even more imperative.
2. Avoid using wilcard certificates if possible.
3. If you still have to use them, avoid using them for root level domains and try use them for the lowest level domain.
4. Ensure that you implement all possible certificate revocation features which you have at your disposal.
5. A relatively new approach which is starting to gain popularity is also to use short lived certificates.

At the end of the day, using or not using wildcard certificates is about where one is comfortable with the risk it poses over the benefits which it produces.