Certificate pinning adds a requirement to TLS server validation: a certificate or public key in the validated chain must match one the application has chosen to accept. It can reject a substitute certificate that ordinary trust checks would otherwise allow. It can also reject a legitimate server after a certificate or key change, leaving deployed applications unable to connect.

Using pinning requires a specific threat to address and control over both the client and server. Most applications can rely on maintained platform trust and correct TLS validation. With pinning, certificate renewal or emergency key replacement can cut off older clients that have not received updated pins.

Certificate pins, public key pins, and a restricted set of certificate authorities (CAs) are different controls. The controls differ in what they match and how certificate or key changes affect clients.

Keep Ordinary TLS Validation in Place

For a certificate-authenticated HTTPS service, the client needs to validate the certificate chain and check that the certificate identifies the intended service. Validity dates, certificate purpose, and the platform's applicable trust checks also matter. Connecting to the right IP address does not replace these identity checks.

Pinning adds a further acceptance condition. A certificate can pass the ordinary checks yet fail the pin because its key is outside the application's accepted set. The connection is then rejected even though another client using only platform trust might accept it.

In this design, a matching pin does not excuse an expired certificate, an incorrect hostname, or an invalid chain. Some libraries configure public key matching separately from ordinary certificate validation. Leaving ordinary validation enabled preserves the intended combination of checks.

Certificate Pins and Public Key Pins

The value being compared determines which server changes the application can tolerate. A certificate fingerprint and a public key fingerprint can both look like short encoded hashes while representing different objects. Naming the hash algorithm alone does not identify what was hashed.

A Pin for the Complete Certificate

A complete certificate pin binds the application to that certificate's encoded contents. Reissuing a certificate changes those contents, even when the service continues using the same key. A client accepting only the previous certificate can therefore reject an otherwise valid renewal.

A replacement certificate must be in the client's accepted set before the server starts presenting it. Routine automatic renewal does not automatically update a pin embedded in an installed application.

A Pin for the Public Key

A public key pin commonly uses a hash of SubjectPublicKeyInfo, or SPKI. That structure contains the public key and its algorithm information. The accepted value describes the key identity rather than the certificate's full contents.

A certificate renewal using the same SPKI can preserve that match. Replacing the key does not. Avoiding a pin update is not a reason to retain a key indefinitely; planned rotation and urgent replacement after compromise still need to be possible.

Some pinning implementations accept a matching key anywhere in the validated chain, while others focus on the server's key. The chosen certificate role matters. A pin for an intermediate CA key permits a broader range of server certificates than a pin for one endpoint key.

What Pinning Can and Cannot Protect

Pinning can reject a certificate or key that ordinary validation accepts but the app's pinning policy excludes. For example, a trusted CA might mistakenly issue a certificate for the service, or a client might trust an unwanted TLS inspection CA. Pinning helps only if the substituted identity fails the pin check and that check runs on the affected connection.

Pinning does not secure a compromised client. An attacker able to alter the application's operation may also alter its trust decisions. Pinning likewise does not repair an already compromised server or prevent that server from mishandling data sent over a valid TLS connection.

Identify the actual TLS endpoint before choosing pins. If a CDN or reverse proxy terminates the client's TLS connection, the client validates that intermediary's certificate. A separate connection from the intermediary to the backend has its own trust policy. A pin for the backend server's key will not match a proxy's different key.

An app may send requests through a platform networking API, a separate library, native code, or an embedded browser. These components may not use the same trust settings. Android Network Security Configuration applies only where the networking stack honors it.

Distribute Replacement Pins before Changing Keys

A pinset lists the certificates or public keys a client accepts. A useful backup pin corresponds to another key the operator can actually deploy, with its private key protected and a valid certificate available when needed. Repeating the active pin adds no replacement option.

Consider a hypothetical application that accepts key A today and must move to key B. A planned transition would proceed in this order:

  1. Prepare key B under the service's approved key-management process.
  2. Release a client configuration that accepts both A and B while the service still presents A.
  3. Confirm which supported clients accept B and arrange updates or an authenticated recovery path for clients that still accept only A.
  4. Move the service to a valid certificate using B and check the intended client connections.
  5. Retire A from future client configurations when the transition and recovery requirements permit it.

A client that remains offline through the update can return with only A accepted. Switching the server to B can then prevent that client from connecting, even if updated clients connect successfully.

Emergency replacement is harder because continuing to use a compromised key may be unacceptable. A previously distributed backup can provide a usable option, but only if the supported clients accept it and the service can deploy it safely. Backup pins do not make an unprepared replacement key acceptable.

Recovering When Pins Block Updates

A pinning outage can block the same endpoint that supplies configuration updates. An affected application may be unable to download the pinset that would restore access. The application therefore needs an authenticated way to receive updated pins or a new app version even when the pinned connection fails.

An update channel needs its own authentication even when it is separate from the pinned service. A signed update mechanism also needs protected signing keys, a trusted verification key on the client, and a defined approach to updating that verification trust.

An application can give a useful error and retain functions that do not require the failed connection. It should not silently accept an arbitrary certificate or switch sensitive traffic to unencrypted HTTP. An authenticated application update can change the accepted pins without weakening the other TLS checks.

Android Network Security Configuration allows pins to expire. After that date, the pinning check stops being enforced, while ordinary trust validation still applies. This can reduce failures in clients that have not received updates, but the narrower pin requirement has ended. The expiration date must be treated as an explicit security and availability tradeoff.

Alternatives to Endpoint Pinning

Maintained platform TLS validation is the usual starting point. It allows the platform to maintain its accepted trust anchors and associated certificate policies without requiring every application to track one server key. Correct server identity checking remains necessary even when the application uses the platform's trust store.

A domain-specific trust configuration can limit an app to selected CAs, such as an organization's CA for a private service. Certificates issued under those accepted authorities can pass without matching one preselected server certificate or key, provided they satisfy the other TLS checks.

Restricting trust to one CA does not identify one particular server key, and changing that CA can still affect old clients. The chosen control should match whether the requirement concerns an issuer, an endpoint identity, or an organization's private trust domain.

Certificate Transparency supports visibility into certificate issuance through public logs and applicable client policies. HSTS tells supporting browsers to use HTTPS for a host. Mutual TLS adds client certificate authentication. These controls address different requirements and do not reproduce an application's endpoint pinset.

The old browser mechanism called HTTP Public Key Pinning, or HPKP, learned pins from response headers. It was removed from Chrome because of its operational and security risks. That historical mechanism should not be deployed as a current browser counterpart to application pinning.

Test Pinning before a Release

Test the networking code and trust settings used in the release build. Include the active key, an accepted backup, a normally valid but unpinned key, certificate renewal, replacement of the endpoint key, and the oldest supported client configuration. Separate pin matching from ordinary certificate failures so that one successful check does not conceal a missing check.

Also consider different TLS endpoints used by the service and clients that missed a release. Record the application version, destination hostname, certificate identity, selected pin policy, and observed connection result without logging private keys or credentials.

If the client and server owners cannot coordinate those changes or provide a trustworthy recovery path, platform trust controls offer a more manageable design. Choose pinning only when it addresses a specific security need and deployed clients can keep working through planned and emergency certificate or key changes.