What is a Rogue Certificate? How do you prevent them?

One of the most frequent questions we get asked is, “what is a rogue certificate?” And unfortunately, the answer isn’t quite as exciting as the name connotes. Still, rogue certificates represent a major threat to Enterprise businesses. Really, any business — it’s just that Enterprises have the most surface to cover, which means they’re easier to miss.

To answer the question “what is a rogue certificate?” we’re going to have to start with a little bit of background, discuss what it means when a Certificate Authority (CA) goes rogue and we’ll end our discussion with some tips on preventing rogue certificates from affecting your business.

So, what is a rogue a certificate? Let’s hash it out.

Let’s start by talking about the authentication aspect of Public Key Infrastructure — specifically in an SSL/TLS context. When a digital certificate is issued, you send the Certificate Authority your public key and a Certificate Signing Request, complete with all relevant information. The CA validates it and returns a signed digital certificate that contains the validated information.

Now, there are higher levels of validation, which authenticate businesses (Organization Validation and Extended Validation), we’re going to ignore those in this discussion and focus on the one authentication that all SSL/TLS certificates provide: server authentication.

When the CA performs domain validation it’s attempting to verify that the certificate request came from the domain’s legitimate owner.

But the idea is always the same, the CA needs to verify that you are indeed the owner of the domain that is living on that server.

Once it’s done this, the CA issues the certificate. This is how it’s supposed to work.

As long as the certificate’s signature can be chained back to a root the certificate is trusted. A rogue certificate is a trusted certificate that is associated with a site that the certificate’s owner doesn’t actually control.

Not with a rogue certificate. A rogue certificate will trick users’ web browsers into trusting the website despite it being a fake.

Let’s talk about the way that certificate-based authentication actually works. This isn’t the validation that takes place during issuance, this is the check that a browser does when presented with a certificate upon arrival at a website.

The checks are:

Ok, so now let’s mix in a rogue certificate.

Remember, a rogue certificate is a valid certificate that has come into the possession of a third-party — typically a malicious one. That means that the attacker actually has the private key.

So when you arrive at a malicious website with a rogue certificate, your browser performs those four checks. It makes sure the certificate was signed by a trusted CA. It was. It makes sure the certificate is valid. It is. It checks if the certificate was revoked. It isn’t.

Now it’s going to check proof of possession.

It uses the public key associated with certificate to encrypt some data and the attacker, which has the associated private key, decrypts and returns it. As far as your computer system is concerned, this website is who it says it is.

A user’s computer never actually authenticates the server itself, it just authenticates the certificate. It’s kind of like when you present a police officer with your driver’s license. He’s going to make sure that the picture on the license matches, that the license is valid, that it hasn’t expired and he’s going to call into the DMV to make sure it hasn’t been revoked. If those all check out, he’s going to accept the license as legitimate. He’s not actually going to check your DNA and blood type to make sure it’s you on a biological level, he’s going off the documentation.

PKI works the same way. A rogue certificate isn’t all that different from a forged passport or a faked identity in a spy film. It allows an attacker to operate under a false identity.

Here is the million dollar question, how do rogue certificates happen? Well, there are three primary sources of rogue certificates:

Let’s start with certificate authorities going rogue and then we’ll talk about the various exploits that have been used to get legitimate CAs to mis-issue certificates.

There are a number of reasons a Certificate Authority may go rogue. It could be as a result of root compromise, it could be the result of unscrupulous management decisions or it could be that the CA issued an intermediate root to an untrustworthy company.

Remember, because the intermediate root was signed with the private key of a trusted root, any endpoint certificate signed by the intermediate is automatically trusted by browsers. That meant Google and Microsoft had to scramble to distrust CNNIC’s roots, invalidating thousands of legitimate certificates in the process.

Breaching a CA is another method for getting rogue certificates issued. If attackers can break into the CA’s network and compromise the private key they can get certificates mis-issued. This happened twice in 2011, with the more notable case being that of DigiNotar, a Dutch CA that was breached that July.

In this case, Iranian hackers compromised the CA’s private key after gaining entry to the network via SQL injection. That was the beginning of the end for the Dutch CA. The Dutch government took over in September of 2011 and by the end of the month had declared DigiNotar bankrupt. The major root stores removed the DigiNotar roots, which in effect revoked all DigiNotar certificates the world over (they could no longer be chained back to a trusted root).

Finally, we have exploits that can trick a CA into issuing a rogue certificate without having to compromise the private key itself. Now, let me preface by saying that neither of these exploits would be easy to pull off — at least for the average internet user.

Ideally, no two hash values should ever be the same. When they are, it’s called a collision.

In order for the attack to work the DNS response needs to be broken down into fragments, which are then injected to trick the CA into issuing the requested certificate. While the first fragments in the response actually contain the valid DNS challenge-response fields, the rest contains whatever information the attacker needs to get the certificate.

This attack hasn’t been seen in the wild yet, it was discovered by a group of German researchers that will present it at a security conference next month.

There are a number of different steps you can take, as well as some exciting industry initiatives that should also help alleviate some of these concerns. Let’s start with the industry initiatives and then we’ll get into some certificate management advice.

Beyond good certificate management habits, here are a few other pieces of actionable advice:

And here’s one last piece of advice on a personal level, make sure your browser is configured to check for revocations. Certificate Revocation Lists and Online Certificate Status Protocol (OCSP) logs are maintained by CAs and tell your browser when it shouldn’t trust a certificate. Make sure that if an OCSP call fails, that your browser treats the certificate as untrustworthy, too.

Well, there’s your rundown. The next time someone asks “What is a rogue certificate?” Point them in this direction.

And as always, feel free to leave any comments or questions below.

Related posts:

Humans and animals are living together prosperously for a long time period. As quoted by Kamaran Ihsan Salih, “Lots of humans take a refuge for friendship with animals, because the brutality of human…

A small taste of your soul, A tiny touch of your skin, A little embrace from your heart, I felt you deepest, deeply within, The strong gaze into your eyes, The great depth of your emotions, The deep…

SAAS solutions are typically subscription-based, which means businesses can avoid the upfront costs associated with traditional software purchases and instead pay a monthly or annual fee. SAAS…