Cert Pinning Checker

Generate SPKI SHA-256 hashes for certificate pinning

About Certificate Pinning

Certificate pinning associates a host with its expected X.509 certificate or public key, preventing man-in-the-middle attacks by rejecting unexpected certificates. Our Certificate Pinning Checker generates SHA-256 SPKI (Subject Public Key Info) hashes from a server's certificate, which you can use in HPKP headers, mobile app pinning, or browser configuration to lock down which certificates are trusted for your domain.

How to Use

Enter the domain name for which you want to generate pinning hashes.
Click Generate Hash to fetch the server's certificate and compute the SPKI SHA-256 fingerprint.
Copy the generated hash for use in your HPKP header or application configuration.
Repeat for backup certificates to include multiple pins for redundancy.

Use Cases

HPKP Deployment: Generate SPKI hashes for HTTP Public Key Pinning headers on your web server.
Mobile App Security: Pin certificates in Android, iOS, or desktop applications to prevent MITM attacks.
API Security: Ensure API clients only trust pinned certificates for backend communications.
Certificate Rotation: Generate pins for both current and backup certificates to enable smooth rotation.

Frequently Asked Questions

SPKI stands for Subject Public Key Info. The SPKI hash is a SHA-256 hash of the certificate's public key information. Unlike a certificate fingerprint, the SPKI hash remains the same even after certificate renewal if the same key pair is used, making it ideal for pinning.

HPKP has been deprecated by major browsers due to abuse potential and lockout risk. However, certificate pinning remains widely used in mobile applications, API clients, and internal infrastructure where careful key management is possible. Always include backup pins to avoid lockout.

Best practice is to pin at least two keys: the current production key and a backup key from a different key pair. For HPKP, include a pin for an intermediate CA as well. This ensures continuity if the primary key needs to be rotated or is compromised.

For most sites, no. Pinning defends against compromise of the CA infrastructure itself, which is rare, while the certificate trust model already covers the realistic case of a key exposed on your own server. The costs are real — you lose the freedom to rotate certificates on your schedule, and a pin mistake takes the site down entirely with no graceful degradation. Strong keys, HSTS and prompt rotation handle the threats you are realistically exposed to.

The public key, not the certificate. Pinning a whole certificate means every renewal breaks clients until you update the pin, which turns a routine automation task into a coordinated outage. The key hash on this page is that form, and it survives reissuance because the same key signs the replacement. If you pin certificates for regulatory reasons, pin an intermediate and keep a backup so rotation does not require client changes.

At least two, and from genuinely different sources. A single pin is a single point of failure; two pins from the same issuer protect nothing extra, because compromising that issuer defeats both. One pin plus one backup key held in reserve is the common pattern, and it is what lets you rotate the certificate without coordinating with clients or taking the site down.

Every connection fails at once, for every client honouring the pin. There is no fallback and no warning period from the client's perspective, which is why an expiring pin is a hard-dated incident rather than something to discover. Monitor certificate expiry on a schedule, put the dates in a calendar with advance reminders, and treat the pin as something with an expiry you own.

It complicates things considerably, and it is one of the strongest practical arguments against pinning for public sites. Every hostname terminating TLS has to satisfy the pin, and a CDN fronting many domains means the certificate actually served is theirs — so pinning couples you to their infrastructure and their rotation schedule. If you must pin behind a CDN, verify what the edge serves rather than what the origin holds.

What Is Produced

Pinning needs a value to pin against. This page computes the subject public key info hash — the form worth pinning — and reports the certificate's identity alongside it.

1Retrieve the certificate and extract its public key in the standard encoding, then hash exactly that — not the certificate and not the PEM text. Pinning the key rather than the certificate is what lets the certificate be renewed without breaking every client.
2Report subject, issuer, expiry and chain length, so the value can be attributed to a specific certificate rather than being a bare hash. Attributing a pin is what makes it auditable later.
3Hand you the value and stop there. Pinning is a deployment decision with real operational cost, and this page produces the input for it without pretending to have assessed whether you should. Read the trade-offs before adding pins to a public site.

One pin is one point of failure. Whatever you decide, carry at least two pins from different sources so you can rotate without an outage — a backup you cannot recover is the same as no backup at all.

Tips & Best Practices

•Pin to intermediate certificates rather than leaf certificates for flexibility
•Include backup pins in case your primary certificate is compromised
•Use both SHA-256 hashes and public key pins for maximum security
•Monitor pin validity to prevent pin validation failures

Technical Details

Method: Public key pinning and certificate pinning analysis
Hash: SHA-256 hash calculation for pin values
Backup: Backup pin configuration and validation
Output: Pin values and implementation recommendations