Aller au contenu
ecdsa.com

SPKI Pin Generator — générateur d’empreintes SPKI

Collez la chaîne de certificats de votre serveur (ou une CSR ou une clé publique) pour obtenir ses empreintes de clé publique à épingler et la configuration qui les applique. L’épinglage peut bloquer l’accès de vos utilisateurs : lisez l’avertissement avant de le mettre en production.

100 % local : tout s’exécute dans votre navigateur, rien n’est envoyé à aucun serveur

Chargement du générateur d’empreintes…

L’épinglage est un engagement Une application avec épinglage n’accepte que les clés listées. Si la clé du serveur, l’AC ou le certificat intermédiaire change et qu’aucune empreinte ne correspond, chaque copie installée de l’application cesse de se connecter jusqu’à ce que les utilisateurs la mettent à jour. Épinglez un certificat intermédiaire ou une clé que vous contrôlez, livrez toujours une empreinte de secours pour une clé conservée hors ligne, définissez une date d’expiration et assurez-vous que les renouvellements conservent une clé épinglée.
Une clé privée fonctionne aussi : seule sa moitié publique est utilisée, dans ce navigateur, et la clé privée n’est jamais incluse dans un lien de partage.

Configuration

What an SPKI pin is

Public-key pinning means that a client accepts a TLS connection only when one of the certificates in the server's chain carries a public key it knows in advance. The key is identified by its pin: the SHA-256 hash of the certificate's SubjectPublicKeyInfo (SPKI, RFC 5280 §4.1.2.7), written in base64. Hashing the SPKI rather than the whole certificate is deliberate (RFC 7469 §2.4): a certificate renewed with the same key keeps the same pin.

Every platform uses this one format:

  • Android — <pin digest="SHA-256"> entries in a <pin-set> of the network security configuration, with an expiration date after which the pins are no longer enforced;
  • iOS and macOS — NSPinnedDomains in the app's Info.plist with SPKI-SHA256-BASE64 values (Apple: identity pinning), or the TrustKit library with kTSKPublicKeyHashes;
  • OkHttp — CertificatePinner entries written sha256/<pin> (OkHttp: certificate pinning);
  • HTTP Public Key Pinning — the Public-Key-Pins header of RFC 7469. Browsers no longer support it: Chrome removed it in 2019 and Firefox in 2020, after site owners locked their own visitors out and attackers showed they could pin a hijacked site to their keys. The tool prints it for reference only.

What the tool computes, and where

Paste the chain your server sends (openssl s_client -showcerts -connect host:443 prints it), a single certificate, a CSR or a public key. Everything is computed in your browser: each item is parsed, its SPKI hashed, and its role in the chain worked out — server certificate, intermediate CA or root. A private key works too, for a key you hold in reserve: only its public half is used, nothing is uploaded, and the key never goes into a share link. The pins are the same values OpenSSL prints with the command shown in the OpenSSL tab, so you can check them on your own machine.

The risk: a pinned app can lock itself out

This is not hypothetical. CAs rotate intermediates on their own schedule: since 2024 Let's Encrypt signs each certificate with one of several intermediates picked at random, and its new generation of roots and intermediates is already in use, so a pin on "the" Let's Encrypt intermediate breaks without warning. Lifetimes are falling towards 47 days, which means more renewals and more chances for a key to change. For most services the better tools are elsewhere: Certificate Transparency monitoring to see every certificate issued for your names, CAA records that limit which CAs may issue them, and short-lived certificates.

Pinning remains reasonable when you control both ends — a mobile app talking to your own API, an agent talking to your own backend — and you follow the rules the checks on this page enforce:

  • Pin a key that outlives renewals. Pinning only the server certificate's key is the most fragile choice unless every renewal reuses that key. An intermediate of your own private CA is a stable anchor; a public CA's intermediate is stable only as long as that CA keeps it, and a root pin accepts any certificate the CA issues for anyone.
  • Always ship a backup pin for a key that is not in use yet and kept offline, so a lost or compromised key can be replaced without bricking the app. Android's documentation asks for one in every pin set.
  • Set an expiration. Android's expiration and TrustKit's kTSKExpirationDate turn enforcement off after the date, so an old app version that was never updated degrades to normal certificate checking instead of failing forever.
  • Watch the dates. The tool warns when a pinned certificate expires before the pin set does: its successor must keep the same key, or be pinned too.

Using the result

By default the configuration pins the intermediates of the chain and then the server key; tick or untick any item to change that, add backup pins one per line, and set the domain, subdomain handling and expiration. The snippets update as you type — copy the one for your platform. Before you ship, compare the certificate you pinned with its next renewal in the certificate diff: it tells you at once whether the key changed. To see the full details of each certificate, use the certificate decoder.