Skip to Content
How TrustPin WorksCertificate Pinning

Certificate Pinning

Learn how certificate pinning works and why it’s essential for mobile app security.

What is Certificate Pinning?

Certificate pinning is a security technique that restricts your mobile application to trust only specific SSL/TLS certificates or public keys when establishing HTTPS connections. Instead of relying solely on the operating system’s trust store (which trusts hundreds of Certificate Authorities), your app validates that the server’s certificate matches a pre-configured cryptographic hash called a “pin.”

This provides an additional layer of security beyond standard TLS validation, protecting against compromised Certificate Authorities, man-in-the-middle attacks, and other certificate-based threats.

The Problem: Traditional SSL/TLS Trust Model

With standard SSL/TLS validation, your app trusts any certificate signed by any Certificate Authority in the operating system’s trust store:

Vulnerabilities:

  • Compromised CA: If any Certificate Authority is hacked or coerced, attackers can issue valid certificates for your domain
  • Rogue CA: Malicious or negligent CAs can issue unauthorized certificates
  • Nation-state attacks: Governments can compel CAs under their jurisdiction to issue surveillance certificates
  • Human error: CA employees can accidentally issue certificates to wrong parties

Real-world incidents: There have been multiple documented cases of CAs being compromised (DigiNotar 2011, Comodo 2011, TURKTRUST 2013, Symantec issues leading to distrust in 2018).

The Solution: Certificate Pinning

With certificate pinning, your app only trusts specific certificates:

Security: Even if a CA is compromised, your app will reject any certificate that doesn’t match your configured pins.


Types of Pinning

TrustPin supports two pinning methods, each with different use cases:

Subject Public Key Info (SPKI) pinning hashes the public key extracted from the certificate, not the entire certificate.

How it works:

Advantages:

  • OWASP recommended: Industry best practice per OWASP MSTG for certificate pinning
  • Flexible rotation: Works seamlessly with TrustPin’s dynamic pin update system
  • Works with managed certificates: Compatible with AWS ACM, Let’s Encrypt, and other providers when combined with dynamic updates
  • Optional key reuse: Pin remains valid across renewals if you explicitly configure key reuse (not supported by all providers)

Use cases:

  • AWS Certificate Manager (ACM) - requires dynamic pin updates
  • Let’s Encrypt auto-renewal - requires dynamic pin updates or explicit key reuse configuration
  • Any automated certificate management system
  • Production apps requiring high availability

Example:

SPKI SHA-256 Pin: e8a01f3d9b2c456789abcdef1234567890abcdef1234567890abcdef12345678

Important Note: Most managed certificate services (AWS ACM, Let’s Encrypt, Cloudflare) generate new key pairs when renewing certificates by default, which means the SPKI hash changes with each renewal, just like leaf certificate hashes. This is where TrustPin’s dynamic pinning becomes essential - it allows you to update pinned certificates remotely without app releases, enabling zero-downtime rotation regardless of whether keys change.

Optional Key Reuse Scenarios (SPKI hash remains stable across renewals):

Let’s Encrypt with Certbot: Use the --reuse-key flag to generate a new certificate with the same public key:

# Renew certificate while reusing the existing private key certbot renew --reuse-key # Or when obtaining a new certificate certbot certonly --reuse-key -d api.example.com

This approach keeps your SPKI pins valid across certificate renewals, eliminating the need to update pins in TrustPin.

AWS ACM: Not possible - ACM always generates new keys during renewal. You must either:

  • Use TrustPin’s dynamic pin updates to handle key rotation seamlessly
  • Import and manage your own certificates outside ACM’s automatic renewal

Self-Managed Certificates: Keep your private key and only request new certificates (CSR) with the same key from your CA.

Default Behavior: Without explicit key reuse configuration, SPKI pins will change during certificate renewal, just like leaf certificate pins. The advantage of SPKI pinning is that it’s the industry-standard approach, and when combined with TrustPin’s dynamic updates, it enables zero-downtime rotation for both manual and auto-managed certificates.


Leaf Certificate Pinning

Leaf certificate pinning hashes the entire X.509 certificate, including metadata like expiration dates and serial numbers.

How it works:

Advantages:

  • Strictest security: Validates the exact certificate
  • Full certificate validation: Includes all certificate metadata

Disadvantages:

  • Breaks on renewal: Pin becomes invalid when certificate renews
  • Requires manual updates: Must update pins before each certificate renewal
  • Risk of downtime: If pins aren’t updated before renewal, all app requests fail

Use cases:

  • Manually managed certificates with infrequent rotation (one year or longer validity)
  • Compliance requirements mandating full certificate validation
  • High-security scenarios where certificate metadata must be validated

Example:

Leaf SHA-256 Pin: 3f5a8b1c9d2e7f4a6b8c1d9e3f5a7b2c4d6e8f1a3b5c7d9e2f4a6b8c1d3e5f7a

Warning: Only use leaf certificate pinning if you have a process to update pins before each certificate renewal. Otherwise, use SPKI pinning.


TrustPin Default Behavior

TrustPin supports both methods and allows you to configure per domain:

  • Recommendation: SPKI SHA-256
  • High security with auto-renewal: SPKI SHA-512
  • Manual certificates: Leaf SHA-256
  • Highest security manual: Leaf SHA-512

You can configure the pinning method in the TrustPin dashboard when adding or updating domain pins.


Hash Algorithms

TrustPin supports two cryptographic hash algorithms for creating pins from either SPKI or leaf certificates:

  • Hash Size: 256 bits (32 bytes)
  • Output Format: 64 hexadecimal characters
  • Security: High (industry standard)
  • Performance: Fast (approximately 1 to 5 milliseconds per validation)
  • Use Case: Most applications
SHA-256 Pin Example (SPKI): E8A01F3D9B2C456789ABCDEF1234567890ABCDEF1234567890ABCDEF12345678 SHA-256 Pin Example (Leaf): 3F5A8B1C9D2E7F4A6B8C1D9E3F5A7B2C4D6E8F1A3B5C7D9E2F4A6B8C1D3E5F7A

Recommendation: SHA-256 provides excellent security with minimal performance overhead. Use this for 99% of applications.

SHA-512 (High Security)

  • Hash Size: 512 bits (64 bytes)
  • Output Format: 128 hexadecimal characters
  • Security: Very High (additional security margin)
  • Performance: Moderate (slightly slower than SHA-256)
  • Use Case: High-security applications (banking, healthcare, government)
SHA-512 Pin Example (SPKI): 1A2B3C4D5E6F7890ABCDEF1234567890ABCDEF1234567890ABCDEF1234567890 ABCDEF1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1234567890 SHA-512 Pin Example (Leaf): 9F8E7D6C5B4A39281726354A9F8E7D6C5B4A39281726354A9F8E7D6C5B4A3928 1726354A9F8E7D6C5B4A39281726354A9F8E7D6C5B4A39281726354A9F8E7D6C

When to use: Only if your security policy or compliance requirements (PCI-DSS, HIPAA, FedRAMP) specifically mandate SHA-512.


ScenarioPinning MethodHash AlgorithmRationale
AWS ACM, Let’s EncryptSPKISHA-256Industry standard, requires dynamic pin updates
Manual certificates (production)SPKISHA-256Flexible rotation, good security
Banking/Healthcare appsSPKISHA-512High security with flexible rotation
Manual certs (high security)LeafSHA-256Strict validation when needed
Maximum security (manual)LeafSHA-512Strictest validation possible

Practical Example: AWS ACM vs Manual Certificates

Scenario 1: AWS Certificate Manager (ACM)

You use AWS ACM for your API at api.example.com. ACM automatically renews certificates every 60 days.

Problem with Leaf Certificate Pinning:

Solution with SPKI Pinning + TrustPin Dynamic Updates:

Note: AWS ACM generates new key pairs during renewal, so SPKI hashes change just like leaf certificate hashes. The advantage of SPKI pinning here is that it’s the industry-standard approach recommended by OWASP, and when combined with TrustPin’s multi-pin support and dynamic updates, it enables zero-downtime rotation. The key benefit is that you can update pins remotely without app releases.


Scenario 2: Manually Managed Certificates

You manage certificates yourself with 1-year validity for secure.example.com. You want maximum control.

Approach with SPKI Pinning (Recommended):

Approach with Leaf Certificate Pinning:


OWASP Compliance

TrustPin follows OWASP Mobile Security Testing Guide  recommendations:

OWASP Requirements

  1. Pin Backup Keys: Always configure backup pins
  2. Fail Securely: Reject connections on pin mismatch
  3. Report Failures: Log pin validation failures
  4. Update Mechanism: Support remote pin updates
  5. Expiration Management: Handle pin expiration gracefully

Attack Scenarios Prevented

1. Man-in-the-Middle (MITM) Attack

Without Pinning:

With Pinning:

2. Compromised Certificate Authority

Scenario: A CA is hacked and issues fraudulent certificates

Without Pinning:

With Pinning:

3. Rogue WiFi Hotspot

Scenario: Attacker operates a fake WiFi hotspot with SSL interception

Without Pinning:

With Pinning:


Common Questions

Q: What happens if my certificate expires?

Answer: If your certificate expires and you haven’t updated your pins:

  • Existing pins remain valid
  • New certificate will fail validation
  • Update pins in dashboard (no app release needed)
  • Apps fetch new pins automatically

Q: How do I rotate certificates without downtime?

Answer: Use TrustPin’s multi-pin support:

  1. Upload new certificate 30 days before expiration
  2. Both old and new pins are active
  3. Certificate rotates on server
  4. Apps gradually fetch new configuration

Q: Can I pin multiple domains with one configuration?

Answer: Yes, configure multiple domains in your project:

Project: MyApp Domains: - api.example.com (pins: abc, def) - cdn.example.com (pins: ghi, jkl) - auth.example.com (pins: mno, pqr)

Q: What if TrustPin CDN is unreachable?

Answer: TrustPin uses intelligent caching:

  • Pins cached locally for 10 minutes
  • Stale pins used if CDN unreachable
  • App continues functioning with last known configuration
  • Automatic retry on next app launch

Security Considerations

Defense in Depth

Certificate pinning is one layer of security:

Limitations

Certificate pinning does not protect against:

  • Compromised server
  • Application-level vulnerabilities
  • Malicious app modifications (root/jailbreak)
  • Physical device access

Use certificate pinning as part of a comprehensive security strategy.


Performance Impact

Minimal Overhead

TrustPin adds negligible performance overhead:

OperationOverheadImpact
Initial Setup~100msOne-time on app launch
Pin Fetch (CDN)~50-200msEvery 10 minutes
Per-Request Validation~1-5msMinimal, happens during TLS handshake
Local Cache Lookup<1msNearly instant

Next Steps


Resources