SSL Pinning Configuration

If your app talks to your own backend over TLS, Protect can pin your API's certificate at the native layer — independent of the device's OS trust store — so a malicious CA installed on the device can't be used to intercept your traffic.

Generating a pin set

Pin sets are generated from the Protect portal against your API's hostname. Protect computes the SPKI (Subject Public Key Info) hash of your certificate — the same value tools like openssl or curl --pinnedpubkey would produce — and stores it as your app's pin set.

Multiple hosts

If your app talks to more than one backend host (an API domain and a CDN, for example), each host gets its own pin entry. All configured pins are embedded into the shielded build.

Certificate rotation

Because the pin is tied to your certificate's public key, a routine certificate renewal from the same key pair doesn't require a new pin. If you rotate to a new key pair, generate a new pin set before your new certificate goes live on your backend, and ship an updated build with both the old and new pins during the transition window — otherwise devices on the old build will fail to connect once the old certificate is retired.

Where this fits

SSL pinning configuration happens once per app (and again on key rotation) and applies to every subsequent shielded build. See the Quickstart for where this step fits in the overall flow.