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:
SPKI Pinning (Recommended)
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: e8a01f3d9b2c456789abcdef1234567890abcdef1234567890abcdef12345678Important 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.comThis 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: 3f5a8b1c9d2e7f4a6b8c1d9e3f5a7b2c4d6e8f1a3b5c7d9e2f4a6b8c1d3e5f7aWarning: 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:
SHA-256 (Recommended)
- 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):
3F5A8B1C9D2E7F4A6B8C1D9E3F5A7B2C4D6E8F1A3B5C7D9E2F4A6B8C1D3E5F7ARecommendation: 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
1726354A9F8E7D6C5B4A39281726354A9F8E7D6C5B4A39281726354A9F8E7D6CWhen to use: Only if your security policy or compliance requirements (PCI-DSS, HIPAA, FedRAMP) specifically mandate SHA-512.
Recommended Configurations
| Scenario | Pinning Method | Hash Algorithm | Rationale |
|---|---|---|---|
| AWS ACM, Let’s Encrypt | SPKI | SHA-256 | Industry standard, requires dynamic pin updates |
| Manual certificates (production) | SPKI | SHA-256 | Flexible rotation, good security |
| Banking/Healthcare apps | SPKI | SHA-512 | High security with flexible rotation |
| Manual certs (high security) | Leaf | SHA-256 | Strict validation when needed |
| Maximum security (manual) | Leaf | SHA-512 | Strictest 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
- Pin Backup Keys: Always configure backup pins
- Fail Securely: Reject connections on pin mismatch
- Report Failures: Log pin validation failures
- Update Mechanism: Support remote pin updates
- 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:
- Upload new certificate 30 days before expiration
- Both old and new pins are active
- Certificate rotates on server
- 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:
| Operation | Overhead | Impact |
|---|---|---|
| Initial Setup | ~100ms | One-time on app launch |
| Pin Fetch (CDN) | ~50-200ms | Every 10 minutes |
| Per-Request Validation | ~1-5ms | Minimal, happens during TLS handshake |
| Local Cache Lookup | <1ms | Nearly instant |
Next Steps
Resources
- TrustPin Dashboard: app.trustpin.cloud
- OWASP Guide: OWASP Certificate Pinning