We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Security Architecture
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Security Architecture
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
In 2011, DigiNotar, a Dutch Certificate Authority trusted by every browser, was compromised. Attackers issued fraudulent certificates for google.com, microsoft.com, yahoo.com, and over 500 other domains. These fake certificates were trusted by every browser because DigiNotar was in the trusted root store. Attackers used them to intercept Gmail traffic of 300,000 Iranian users in a state-sponsored surveillance operation.
DigiNotar was not a small player. It was a government-accredited CA. And it was not the only compromise. In 2015, CNNIC (the Chinese government CA) issued unauthorized certificates for Google domains through an intermediate CA called MCS Holdings. In 2017, Symantec was discovered issuing 30,000 certificates without proper validation, leading Google to distrust the world's largest CA.
Standard TLS trusts any certificate signed by any of the approximately 150 root CAs in your browser's trust store. If any one of those CAs is compromised, an attacker can issue a valid certificate for any domain. Certificate pinning narrows this trust. Your client only accepts the specific certificate or public key that you expect, not any certificate from any CA.
| Pinning Type | What You Pin | Flexibility | Risk |
|---|---|---|---|
| Certificate pinning | Hash of the full certificate (SHA-256 of DER) | Must update client when cert rotates (every 90 days with Let's Encrypt) | Highest assurance, highest maintenance |
| Public key pinning | Hash of the Subject Public Key Info (SPKI) | Survives cert renewal if the key stays the same | Good balance. Rotate keys on schedule, not on every cert renewal |
| CA pinning | The issuing CA's certificate | Most flexible. Any cert from that CA is accepted | Least restrictive. If the CA is compromised, the pin is worthless |
Where pinning is still used today:
Mobile banking apps pin their API server's public key. The pin is compiled into the app binary. If a corporate or malicious CA issues a fake certificate for api.mybank.com, the app refuses the connection even though the OS trusts the certificate.
iOS apps using App Transport Security can declare pins in Info.plist. Android apps use network_security_config.xml to specify pins with backup keys. Both platforms support pinning natively.
The death of HPKP. Public Key Pinning was a browser standard that let websites declare their pins via an HTTP header. It was deprecated in 2018 because misconfiguration could permanently brick a website. If you pinned the wrong key and the backup failed, no browser could connect to your site until the pin expired, sometimes months later. RangeForce called it "the most dangerous HTTP header ever created." One disgruntled employee could pin a key only they controlled and hold the domain hostage.
Modern approach: Use Certificate Transparency (CT) logs to detect unauthorized certificate issuance. Pin certificates in mobile apps where you control the client. For web, rely on CT monitoring instead of browser-level pinning.