Certificate pinning is the practice of associating a specific TLS certificate (or its public key) with a particular server, rather than trusting any certificate issued by any trusted CA. For software update channels, pinning adds a layer of defense against man-in-the-middle attacks that use fraudulently issued certificates.
The concept is compelling: even if an attacker compromises a certificate authority and obtains a valid certificate for your update server, pinned clients will reject it because it does not match the pinned certificate. This has prevented real attacks -- the DigiNotar compromise in 2011, where fraudulent Google certificates were issued, was detected partly through Chrome certificate pinning.
But pinning also introduces significant operational risk. Pin the wrong certificate, let a pin expire, or lose the ability to rotate certificates, and your update channel is dead. Let us walk through when pinning makes sense and how to implement it without shooting yourself in the foot.
When Pinning Makes Sense
High-value update channels. If your software runs on millions of devices and a compromised update could cause widespread damage, pinning the update server certificate adds meaningful protection.
Regulated environments. Some compliance frameworks require additional certificate validation beyond standard TLS. Pinning satisfies this requirement.
Known hostile network environments. If your software runs in environments where network-level MITM attacks are realistic (corporate networks with TLS inspection, countries with state-controlled CAs), pinning provides defense.
When Pinning Causes More Harm Than Good
Short-lived certificates. If you use Let's Encrypt or another CA with 90-day certificates, pinning the leaf certificate means updating the pin every 90 days. Missing a rotation bricks your update channel.
Multi-CDN distribution. If your updates are served through CDN providers that manage their own certificates, pinning is impractical because the certificates are outside your control.
Small user base. If your software has a small number of installations, the operational risk of pinning outweighs the security benefit.
Implementation Approaches
Pin the Intermediate CA
Instead of pinning the leaf certificate (which changes frequently), pin the intermediate CA certificate. This allows certificate rotation without pin updates, as long as the new certificate is issued by the same intermediate CA.
This is a reasonable compromise between security and operational flexibility. An attacker would need to compromise the specific intermediate CA, not just any CA.
Pin the Public Key
Pin the Subject Public Key Info (SPKI) hash rather than the certificate itself. This allows you to reissue certificates (for expiration or other reasons) using the same key pair without changing the pin.
Include Backup Pins
Always include at least one backup pin for a key you control but are not currently using. If you need to rotate your primary certificate and the new certificate does not match the primary pin, the backup pin prevents a total lockout.
Pin with Override Mechanism
Include a mechanism to update pins through a signed configuration. This is essentially a secondary trust root for pin management. If pin rotation fails, you can push new pins through this channel.
What to Pin To
Best: Intermediate CA public key. Provides protection against most attacks while allowing leaf certificate rotation.
Good: Your own public key with backup. Provides strong protection with operational flexibility through key backup.
Risky: Leaf certificate. Maximum security but maximum operational risk. Only appropriate if you have robust certificate lifecycle management.
Wrong: Root CA. Pinning to a root CA provides almost no additional security because root CAs issue millions of certificates.
Recovery Planning
Every pinning implementation needs a recovery plan for when things go wrong:
Pin expiration. Set pin validity periods and ensure pins are updated before they expire.
Key compromise. If your pinned key is compromised, you need a way to rotate to the backup pin. Test this process before you need it.
CA migration. If you need to change CAs (the CA stops issuing certificates, changes pricing, or is compromised), pinned clients will reject certificates from the new CA. Backup pins should include keys for certificates from an alternative CA.
How Safeguard.sh Helps
Safeguard.sh monitors the certificate infrastructure underlying your software distribution. Our platform tracks certificate expiration, validates pinning configurations, and alerts you to certificate changes that could affect update delivery. Combined with SBOM generation and artifact verification, Safeguard.sh ensures your software distribution pipeline is authenticated end-to-end.