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:

  • Survives certificate renewal: Pin remains valid if the same key pair is reused
  • Zero-downtime rotation: Perfect for auto-managed certificates (ACM, Let’s Encrypt)
  • OWASP recommended: Industry best practice per OWASP MSTG
  • Less maintenance: Ideal for certificates that renew automatically every few months

Use cases:

  • AWS Certificate Manager (ACM)
  • Let’s Encrypt auto-renewal
  • Any automated certificate management system
  • Production apps requiring high availability

Example:

SPKI SHA-256 Pin: e8a01f3d9b2c456789abcdef1234567890abcdef1234567890abcdef12345678

Why SPKI is preferred: Modern certificate authorities like AWS ACM and Let’s Encrypt automatically renew certificates every 60-90 days. With SPKI pinning, these renewals don’t require updating pins in your TrustPin dashboard, as long as the same key pair is reused.


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-256Auto-renewal compatible, industry standard
Manual certificates (production)SPKISHA-256Flexible rotation, good security
Banking/Healthcare appsSPKISHA-512Auto-renewal + high security
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:


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