Pular para o conteúdo
ecdsa.com

Gerador de pins SPKI (SPKI Pin Generator)

Cole a cadeia de certificados do seu servidor — ou um CSR ou uma chave pública — para obter os pins de chave pública e a configuração que os aplica. A fixação pode deixar os usuários sem acesso: leia o aviso antes de publicar o aplicativo.

100% local — tudo roda no seu navegador, nada é enviado a nenhum servidor

Carregando o gerador de pins…

A fixação é um compromisso Um aplicativo que usa fixação aceita apenas as chaves listadas. Se a chave do servidor, a CA ou o certificado intermediário mudar e nenhum pin corresponder, todas as cópias instaladas do aplicativo param de se conectar até que os usuários o atualizem. Fixe um certificado intermediário ou uma chave que você controla, sempre inclua um pin de backup para uma chave que você mantém offline, defina uma data de expiração e garanta que as renovações mantenham uma chave fixada.
Uma chave privada também funciona: só a metade pública dela é usada, neste navegador, e a chave privada nunca entra em um link de compartilhamento.

Configuração

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.