What is Certificate Pinning?

Why certificate pinning is tempting

TLS normally trusts any certificate chain that validates to a trusted root and matches the requested name. That scales the web, but it also means many public Certificate Authorities can issue for the same domain if validation succeeds or fails in their systems.

Certificate pinning narrows that trust decision for a specific client. Instead of accepting every valid Web PKI certificate for api.example.com, the client also checks whether the presented key material matches a known pin.

That extra check can help high-risk apps, but it moves certificate lifecycle risk into the application.

What can be pinned

Modern guidance favors pinning stable public-key material rather than entire leaf certificates.

SPKI pinning is common because the pin is calculated over the certificate's public-key structure, not over expiration dates, SAN lists, or signatures. It still requires planning: if you lose the matching private key, clients need a trusted path to a replacement key.

How SPKI pin validation works

Pinning should be an additional validation step, not a replacement for normal TLS checks.

The order matters. A raw key match should not make an expired, wrong-name, or otherwise invalid certificate acceptable unless you are building a deliberately private trust model with explicit rules.

HPKP, mobile pinning, and CT compared

HTTP Public Key Pinning (HPKP), defined in RFC 7469, let servers send a Public-Key-Pins header that browsers cached. It was powerful enough to be dangerous: a mistaken max-age, missing backup pin, lost key, compromised server, or hostile pin could make a site unreachable for affected users. Browser vendors removed it rather than keep a web-scale footgun.

Mobile and thick-client pinning survived because the application publisher controls the client code. That control is also the main risk: if the app has no update path, no backup pins, or no tested emergency process, a normal CA rotation can become a production incident.

Deployment checklist

• Use pinning only for a clear threat model, such as high-value mobile APIs, managed devices, or private service clients.
• Prefer SPKI hashes over whole leaf certificate pins for public TLS endpoints.
• Keep normal TLS validation enabled before applying pin checks.
• Ship at least one tested backup pin whose private key is protected and available for emergency rotation.
• Document rotation steps for CDN, CA, key, and app-release changes before enabling enforcement.
• Add telemetry that distinguishes pin failures from generic TLS errors without leaking secrets.
• Avoid HPKP and remove obsolete `Public-Key-Pins` headers from browser-facing sites.
• Use Certificate Transparency monitoring for public domains; pinning does not tell you what other certificates were issued.

When pinning is worth it

Certificate pinning can make sense when both sides of the channel are under one organization's control and the client population can be updated quickly. Examples include a banking mobile app, managed endpoint agent, embedded device, or internal service client that talks to a small set of APIs.

It is usually a poor fit for ordinary public websites. Browsers already enforce Web PKI rules, public certificates are covered by CT expectations, and users cannot recover easily from site operator pinning mistakes. For the public web, prioritize automated certificate renewal, strong CA account security, HSTS, CT monitoring, and incident response for unexpected issuance.

Expect-CT belongs in the history section of this decision. It was useful while browsers were transitioning toward CT enforcement, but new systems should not choose between Expect-CT and pinning. They should choose between broad public-issuance visibility through CT monitoring and narrow client-side trust restriction through app-controlled pinning.

The practical takeaway

Certificate pinning narrows TLS trust by requiring known certificate or public-key material, with SPKI pinning being the least brittle common form. It can reduce exposure to CA mis-issuance and local trust-store abuse for controlled clients.

Use it sparingly, keep backup pins ready, and rehearse key rotation. For normal web properties, avoid HPKP and rely on CT-compliant certificates plus continuous Certificate Transparency monitoring instead.