本文へスキップ
ecdsa.com

SPKI ピン生成ツール

サーバーの証明書チェーン(または CSR や公開鍵)を貼り付けると、その公開鍵ピンと、ピンを適用するための設定を取得できます。ピンニングによってユーザーが接続できなくなることがあります。リリースする前に警告を読んでください。

100% ローカル:すべてブラウザー内で処理され、どのサーバーにも何も送信されません

ピン生成ツールを読み込み中…

ピンニングは長期的な約束 ピンニングしたアプリは、リストにある鍵しか受け付けません。サーバーの鍵、CA、または中間証明書が変わり、どのピンとも一致しなくなると、インストール済みのアプリはすべて、ユーザーが更新するまで接続できなくなります。中間証明書か自分で管理している鍵をピンニングし、オフラインで保管している鍵のバックアップのピンを必ずアプリに含め、有効期限を設定して、証明書を更新してもピンニングした鍵が引き継がれるようにしてください。
秘密鍵も使用できます。使用するのは公開鍵部分だけで、処理はこのブラウザー内で行われ、共有リンクに含まれることはありません。

設定

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.