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