Your client pins a server's key rather than trusting the whole anchor list - what exactly should the pin cover, and why?

Pinning is a deliberate narrowing of the trust decision. The ordinary decision is "did the path end at *any* entry in my anchor list?" - a list that may hold well over a hundred authorities. A pin replaces that with "and it must also involve *this* key". It is the answer to the observation that your own service never legitimately gets a certificate from an arbitrary authority. ## What is pinned, exactly The unit is a **public key**, identified by a digest over the DER encoding of the certificate's `SubjectPublicKeyInfo` structure - the field that carries the algorithm identifier and the key itself. `RFC 7469` names this the **SPKI Fingerprint** and defines it as a SHA-256 digest of that DER encoding, base64-encoded. The alternative - a fingerprint over the whole encoded certificate - is the natural first instinct and the one that fails in production: | Pinned object | Survives a renewal that reuses the key pair | Survives a re-key | Typical failure | |---|---|---|---| | whole-certificate fingerprint | no | no | outage at every renewal, including routine ones | | SPKI fingerprint over the public key | yes | no | outage at the next key change, which is rarer and plannable | The difference is not subtle: a certificate is re-signed with a new serial number and new validity dates every time it is reissued, so its fingerprint changes even when nothing about the key did. ## Which key in the path to pin A pin can name the end-entity key, an intermediate issuer's key, or the anchor's key, and the choice is a trade between precision and churn: - **The end-entity key** is the tightest and the most brittle - it changes whenever that key changes. - **An issuing intermediate's key** changes far less often and still excludes every other authority in the list, at the cost of accepting anything that issuer signs for the name. - **The anchor's key** is the loosest useful pin and mostly restates "only our own authority". `RFC 7469`'s model is that the connection is acceptable if **at least one** pinned fingerprint matches **some** key in the path the client built, which is what makes a mixed set of end-entity and issuer pins workable. ## Backup pins are not optional A pin set with one entry is a single point of failure that you built deliberately. The rule is to pin at least one key you are **not currently serving** - a generated, stored, ready-to-deploy key pair - so that a compromise or a forced re-key has somewhere to land without new client configuration. Deploying a single pin and generating the backup later means that at the moment you most need to move, you cannot. ## The outage mode, stated honestly Pinning inverts the usual risk. Everywhere else in this subject a misconfiguration means you accepted something you should not have; with pinning, a misconfiguration means you **refuse something that is completely correct**: 1. The key is compromised and must be replaced, and no backup pin matches the replacement. 2. Someone rotates the key as routine hygiene without knowing a pin exists. 3. The client configuration is embedded in something slow to update - an appliance, a field device, an image with a long refresh cycle. 4. The pin outlives the person who set it, which is the ordinary case after a year or two. In all four, the server is serving a valid, correctly issued certificate and the client refuses it. There is no server-side fix; the fix ships to clients. ## The header-based form, and its status `RFC 7469` also defines a way for a **server** to declare pins in a response, through the `Public-Key-Pins` and `Public-Key-Pins-Report-Only` header fields, carrying `pin-sha256` values plus the `max-age`, `includeSubDomains` and `report-uri` directives. It is worth knowing as the specification it is, and worth knowing for its lesson: a server-declared pin is a policy a client caches for `max-age` seconds, so an operator can lock their own users out of their own site for the remaining lifetime of that cache with no way to retract it. **Do not assume any current client enforces these header fields.** The durable form of pinning is the one you compile into a client you control, where you can also ship the retraction. ## Where pinning earns its place A client you build, talking to an endpoint you run, over a relationship that is not a general-purpose web session: a collector reporting to a historian, a device calling home, an internal agent. There the population of legitimate keys is small and known, the client ships on a schedule you control, and the narrowing is real. Pinning a third-party endpoint you do not operate, from a client you cannot update quickly, is how the outage mode above finds you.