Certificate Pinning: What It Is, Certificate Binding Methods and How to Implement

Advantages and Disadvantages of Certificate Pinning

Certificate Pinning significantly increases mobile application security but places an operational burden on the development team. It is important to weigh the security benefits against the risks of connection blocking due to incorrect implementation.

The main advantage is protection against Man-in-the-Middle attacks, including cases of CA compromise. Pinning makes fake certificates issued by an attacker useless: even if a CA signed a forgery, the application will reject it. An additional benefit is protection against corporate proxy servers that substitute certificates for traffic inspection. According to Google Security Blog (2023), applications with pinning have 86% fewer chances of being compromised through traffic interception compared to applications using only standard TLS verification.

The main disadvantage of pinning is the risk of self-blocking: if the server certificate changes (renewal, provider change, key rotation) before the application update is released, users lose access to the server. Additional drawbacks: debugging complexity (every configuration change requires pin updates), APK size increase by 5–15 KB when using TrustKit, and the inability to quickly roll back changes without a new release. To minimize risks, backup pins, automatic rotation every 2–3 months, and a grace period are used, during which the application accepts both the old and new certificate. It is also important to consider that during development with pinning enabled, proxy tools (Burp Suite, Charles) cannot be used for debugging network requests — for dev builds, pinning must be disabled via the BuildConfig.DEBUG flag, and QA testing should be performed on the release signature with protection enabled. Some teams use a staging domain with a separate pinning certificate for the dev environment to maintain protection even during development.

Implementing Certificate Pinning in Android

Let’s look at an example of implementing Certificate Pinning on Android using OkHttp — the standard library for network requests. OkHttp provides a built-in CertificatePinner that accepts SHA-256 hashes of public keys.

val certificatePinner = CertificatePinner.Builder()
    .add(
        "api.example.com",
        "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA="
    )
    .add(
        "api.example.com",
        "sha256/BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB="
    )
    .build()

val client = OkHttpClient.Builder()
    .certificatePinner(certificatePinner)
    .build()

In the code above, we add two pins for the domain api.example.com: the primary (current certificate) and a backup pin (for rotation). OkHttp automatically verifies that the server’s certificate matches one of the specified SHA-256 fingerprints. To obtain the SHA-256 certificate fingerprint, use the command: openssl s_client -connect api.example.com:443 | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64. It is important to store fingerprints not as plain text in the code, but encrypted or obfuscated: MobSF static analysis easily finds raw SHA-256 strings in DEX files. It is recommended to store pins in res/raw resources, encrypted via AES, and decrypt them at application startup through native code (NDK/JNI).

iOS Implementation via TrustKit

On iOS, the primary tool for Certificate Pinning is the open-source TrustKit library. Unlike OkHttp, TrustKit is configured declaratively through Info.plist, allowing pin changes without recompiling the application. The configuration includes a dictionary with domains and an array of SHA-256 public key fingerprints. TrustKit automatically intercepts NSURLSession requests and verifies certificates before data transmission begins. A critical feature of TrustKit is support for pin validation reports: the library can send reports to a specified endpoint when a pin mismatch occurs, enabling rapid response to certificate anomalies. Apple also provides a native NSPinnedDomains mechanism in Info.plist starting from iOS 14, but TrustKit remains the preferred choice due to more flexible configuration, report support, and the ability to hot-swap pins without OS updates. It is important to note that TrustKit integrates with URLSession via the didReceiveChallenge delegate, returning .performDefaultHandling upon successful pin verification and .cancelAuthenticationChallenge on mismatch. For monitoring pin validation reports, it is recommended to set up a separate endpoint that analyzes error frequency: if the number of reports sharply increases — this may indicate a MitM attack or imminent certificate expiration requiring immediate pin updates.