Certificate Pinning
Certificate pinning constrains a client to accept only a specific certificate or public key for a given host, instead of trusting any certificate chaining to a trusted root, as formalized for HTTP in RFC 7469's Public-Key-Pins header. AdminKit's guide to certificate chain completeness explains the broader trust model pinning narrows.
By AdminKit team, Netbase JSC · Updated
Certificate pinning restricts a client to accept only a specific, previously known certificate or public key for a given host, rather than trusting any certificate that chains to a trusted root through the normal certificate chain validation an X.509 certificate goes through. The IETF formalized one version of this for the web in RFC 7469, the HTTP Public Key Pinning (HPKP) extension: a server sends a Public-Key-Pins header listing one or more Subject Public Key Info (SPKI) hashes, a client caches them, and on later connections it requires the server to present a certificate whose public key matches one of those pinned hashes — in addition to, not instead of, passing ordinary chain validation. If none of the certificates in a later connection match a cached pin, RFC 7469 requires the client to treat it as a pin validation failure and abort the connection, which is also why a misconfigured or expired pin set can lock clients out of a server’s own legitimate certificate. Rather than relying on a browser caching a pin from an earlier visit, DANE/TLSA (RFC 6698) takes a related but distinct approach: it publishes the expected certificate or key directly as a DNSSEC-secured DNS record, so a client can enforce the pin starting with its very first connection to a host. Encrypted ClientHello (ECH) is a complementary TLS technique AdminKit’s glossary also covers: where pinning hardens which key a client will trust, ECH hardens what a network observer can see about the handshake itself. Modern certificate pinning is now more commonly implemented directly inside individual mobile apps — checking a pinned SPKI hash in app code — rather than through a browser-enforced HPKP header.
Certificate pinning is part of AdminKit’s Machine protocols cluster; the full AdminKit glossary lists other related terms.
Frequently asked questions
What does RFC 7469's Public-Key-Pins header actually pin?
It pins one or more Subject Public Key Info (SPKI) hashes rather than a whole certificate, so a server can rotate to a new certificate as long as its public key still matches a pinned hash.
Does certificate pinning replace normal certificate chain validation?
No -- pinning is an additional constraint layered on top of normal chain validation; a pinned certificate must still validate to a trusted root the way any certificate chain does.
What happens under RFC 7469 if none of a server's presented certificates match a client's cached pins?
The client must treat the connection as a pin validation failure and abort it, even if the certificate otherwise chains to a trusted root -- which is why a misconfigured pin set can lock out a server's own legitimate certificate.
How does DANE/TLSA differ from HPKP-style pinning?
DANE (RFC 6698) publishes the expected certificate or key as a DNSSEC-secured DNS record, so a client can enforce it on the very first connection, instead of HPKP's model of caching a pin from an earlier visit before it can be enforced.