---
title: "Certificate pinning"
url: https://proxy.wiki/glossary/certificate-pinning/
type: Glossary Term
author: "proxy.wiki editorial"
published: 2026-09-06
updated: 2026-09-06
site: proxy.wiki
topics: ["Proxy fundamentals"]
license: CC BY 4.0 — quote freely with attribution to https://proxy.wiki/
---

# Certificate pinning

> Certificate pinning is the practice of accepting only a specific key or certificate for a host, rather than any certificate that chains to a trusted root.

**Certificate pinning is the practice of accepting only a specific key or certificate for a host, rather than any certificate that chains to a trusted root.** It narrows trust from the whole certificate authority system to one identity chosen in advance.

## What is actually pinned

Usually a hash of the Subject Public Key Info rather than the certificate itself, so that the host can renew a certificate without breaking the pin as long as the key is retained. Pins may be set on the leaf, on an intermediate, or on both, with a backup pin held for the case where the primary key must be replaced.

Pinning is a supplement to ordinary validation, not a replacement for it. RFC 6125 covers the identity checking that still has to happen underneath.

## Why it matters for scraping

Pinning is what stops you reading a mobile application’s traffic through a proxy. The application refuses the substituted certificate that [TLS interception](/glossary/tls-interception/) depends on, so the connection fails rather than yielding plaintext. That is the mechanism working as designed. Defeating it requires modifying the application, which raises legal and terms-of-service questions worth answering before the technical ones.

The failure is distinctive: the handshake completes at the appliance and the application then closes the connection itself, usually with no useful error. Seeing traffic reach the middlebox and stop there is the signature, and no amount of proxy configuration changes it.

## The browser story

RFC 7469 defined `Public-Key-Pins`, an HTTP header letting a site pin itself in visiting browsers. It was withdrawn from major browsers in practice, because an operator who loses the pinned key locks users out of the site for the lifetime of the pin, and because the header offered an attacker a way to do the same deliberately. Pinning survives where the client and the server are shipped by the same party: mobile applications, desktop clients, embedded devices.

## Commonly confused with

[IP whitelisting](/glossary/ip-whitelisting/) restricts who may connect. Pinning restricts which server identity the client will accept. A [proxy](/glossary/proxy-server/) does not interfere with a pin unless it terminates TLS, so a pinned application works normally through a plain [CONNECT](/glossary/http-connect/) tunnel.

## Frequently asked questions

### Does a proxy break certificate pinning?

Not on its own. A CONNECT proxy forwards encrypted bytes without touching the certificate, so a pinned client validates the real server exactly as it would directly. Pins break when something terminates the TLS session and substitutes its own certificate, which is interception rather than proxying.

### Why did browsers stop supporting the Public-Key-Pins header?

Because the failure mode is severe and irreversible. An operator who loses the pinned key makes the site unreachable for every visitor holding the pin until it expires, and an attacker with temporary control could set a hostile pin deliberately. The mechanism survives in applications that ship their own pins.

### Is pinning the same as certificate transparency?

No. Pinning is a client-side rule about which identity to accept for one host. Certificate transparency is a public logging system that makes wrongly issued certificates discoverable after the fact. One prevents acceptance, the other enables detection, and they are frequently deployed together.

## Sources

1. [RFC 7469: HTTP public key pinning, the header form and its risks](https://www.rfc-editor.org/rfc/rfc7469.html)
2. [RFC 6125: verifying service identity in TLS, the validation pinning supplements](https://www.rfc-editor.org/rfc/rfc6125.html)