How Does Certificate Pinning Protect Against Fraudulent Certificates?

You may have recently seen a story in which it was reported that airline wireless internet provider Gogo was issuing SSL certificates for domains owned by Google. There was a small storm of controversy around the story, because, in theory, issuing such certificates could allow the bandwidth provider to see content flowing over its network that the user assumed to be encrypted.

In fact, no such security breach happened, because Google’s Chrome browser blocked the certificates and the pages using them and other browsers would have shown an unmissable warning that the certificates were not to be trusted. However, it’s interesting to take a look at how browsers decide if certificates are to be trusted, the limitations of that system, and a (partial) solution to those problems, which is known as certificate pinning.

Let’s say you visit a website at Your browser initiates an SSL handshake to set up an encrypted connection, which involves the browser receiving a SSL certificate. How does the browser know the certificate is genuine and to be trusted? Browsers (and operating systems) automatically trust certificates that are digitally signed by a limited number of trusted certificate authorities; they have information that allows them to verify that a cert has been properly signed by a trusted entity (or signed by a cert that has been signed by a trusted entity, etc). When a site owner “buys” an SSL certificate, what they pay for is that digital signature and any work that goes into verifying their identity so the CA is comfortable signing their certificate.

That stops just anyone from issuing and signing SSL certificates that a browser will trust: it has to be a recognized certificate authority. But what happens if a certificate authority goes rogue? Browsers will trust a certificate signed by any certificate authority’s root certificate or, more usually, an intermediate certificate signed by the root certificate. That means any recognized certificate authority could sign’s certificate and it would be accepted as genuine. It doesn’t matter at all which certificate authority the site owner used originally: the browser doesn’t care about that, just that some certificate authority signed.

A few years ago a CA called DigiNotar was compromised and was used to issue certificates for various domains to hackers. That’s the weakness in the system. If any certificate authority is compromised, then online criminals can issue “valid” SSL certificates for any domain. Fortunately, that’s a rare occurrence, but it has happened before and it might happen again.

Certificate pinning is the solution. Browser manufacturers can “pin” a certificate to an authority. They will only accept a certificate as genuine if it is signed by a specific certificate authority, not any certificate authority. When Adrienne Porter Felt, the Google Chrome engineer in the story we mentioned at the top of the article, was issued a certificate for that was not signed by the pinned CA the browser expected, it blocked the site.

However, pinning is only a partial solution. The reason we use certificate authorities in the first place is so that browsers don’t have to carry with them information about which certificates are valid for every site the world. The certificate authorities determine certificates are valid, and the browsers trust the certificate authorities. It would be impractical to say the least for the browsers to have a constantly updating database of tens of millions of sites and their certificates. The same is true of certificate pinning: it would be impractical for browsers to carry a list of which certificates should have been signed by which authorities, because these things change constantly, and keeping the database up-to-date would be impossible.

What we can do is pin a proportionately tiny number of important sites, like Certificate pinning is ultimately not a solution to the problem of rogue certificate authorities, it merely protects the users of a relative handful of sites, which is better than nothing.

Matthew Davis is a technical writer and Linux geek for Future Hosting.

Dedicated Server Special

Take advantage of our Double RAM offer on the E3-1230v2 4 x 3.30GHz+HT server! Only $134.95 per month. Managed and Unmanaged options available at checkout.