When certificate trust becomes a point of failure
Certificate pinning was developed at a time when the Public Key Infrastructure (PKI) ecosystem looked very different. The idea was straightforward: a server presents its TLS certificate to a client and instructs it to accept only that exact certificate, rejecting anything else. This was meant to stop a mis-issued certificate from being used to impersonate a legitimate domain, such as a bank's website, and intercept sensitive traffic.
But the threat model that made pinning attractive no longer matches how certificates are issued and managed. Over the past two decades, certificate issuance has become more dynamic, and the practices that support that agility — frequent rotations, shorter lifetimes, and greater transparency — are fundamentally incompatible with pinning's rigid approach. The result is that pinning, once a security safeguard, has become a leading cause of avoidable downtime.
Why pinning breaks under modern certificate management
Certificate pinning depends on exact matches. When a certificate is rotated — whether the leaf certificate or an intermediate in the chain — a client with a pinned certificate will reject the new one unless the pin has been updated to match. The new certificate may be perfectly valid and issued by the same certificate authority (CA), but that does not matter: the client sees a mismatch and refuses to establish the connection.
The PKI ecosystem has been moving toward more frequent rotations as a security improvement. Certificate authorities are beginning to rotate certificates and intermediates more often to encourage automation and limit the damage from a compromise. For anyone using pinning, this is a problem: every rotation is a potential outage if the pinned certificate hasn't been updated beforehand.
The uptick in pinning-related incidents is not hypothetical. Since the start of 2024, customer-reported outages caused by certificate pinning have risen sharply. Two events account for much of that increase: Cloudflare's migration away from DigiCert as a certificate authority, and intermediate CA rotations by Google and Let's Encrypt.
What is most telling about those outages is that nearly all affected customers did not know they had a pin in place. Certificate pinning has a "set and forget" reputation, but that mentality stopped working once certificate rotations became routine. To use pinning safely now, an organization needs a system for tracking every certificate change and applying those updates across all clients. That is a management burden few teams are prepared for, and the cost of failure is full loss of availability.
Modern certificate practices replace pinning's security guarantees
The security goals that pinning was meant to achieve are now covered by other mechanisms that do not require manual tracking. These newer practices are designed to be automated and scale with the current PKI ecosystem.
Shorter certificate lifetimes
Certificate validity has shrunk dramatically. Before 2011, a certificate could be valid for up to eight years. In 2024, the maximum is one year. Google Chrome is pushing further, advocating for three-month validity as the new standard. Cloudflare is also moving in that direction, preferring CAs that support the ACME protocol (Automated Certificate Management Environment), which issues certificates with 90-day validity by default. As part of its reduced usage of DigiCert, Cloudflare has already removed the option to issue one-year certificates for Universal SSL.
The shift to shorter lifetimes serves several security purposes. It limits the window in which a compromised certificate or private key can be abused. It lessens dependence on certificate revocation, which remains inconsistently implemented across clients and browsers. And it forces automation, replacing manual, error-prone certificate management practices.
Frequent intermediate rotations
Cloudflare's partner CAs, Let's Encrypt and Google Trust Services, both changed their intermediate chains in June 2024. Let's Encrypt now balances issuance across ten intermediates (five RSA and five ECDSA). This rotation is a deliberate security measure: shorter-lived intermediates reduce the attack surface and make revocation more practical.
For pinning, this is a hazard. Even when a customer renews a certificate with the same CA, they have no guarantee the same chain will be used. A renewal can succeed while producing a certificate whose intermediate does not match the pinned one. The client then rejects the new certificate, and the domain or application goes down until the pin is updated. The problem is that this exact matching is intrinsic to how pinning works — it cannot accommodate the very rotations that make the PKI ecosystem more secure.
Certificate transparency
Certificate transparency (CT) logs create a public, auditable record of every TLS certificate issued. This provides a way to detect misissued or malicious certificates that duplicates the original purpose of pinning. CT monitoring can notify domain owners when any certificate is issued for their domain, allowing them to respond to a potentially fraudulent issuance in real time.
Why pinning persists and where it still causes risk
Pinning was originally designed to defend against monster-in-the-middle (MITM) attacks by binding a hostname to a specific certificate, so that clients would only trust a server presenting that exact certificate. It was commonly used to secure IoT devices, mobile apps, and APIs.
IoT devices present a particular challenge. They are often limited in processing power and unable to perform regular software updates. Some cannot even carry out certificate revocation checks. Pre-installing trusted certificate pins has been a way to give these devices a baseline level of security they might otherwise lack. But with certificates rotating more frequently, devices with immutable software cannot update pins in time for a renewal, leading to failures that cannot be corrected without hardware access.
Mobile app developers have also used pinning for Android and iOS applications. Yet both Apple and Google explicitly warn against it, citing the risk of failures when implementations are incorrect. Those warnings reflect the same structural problem: pinning requires continuous, exact coordination that modern certificate practices make increasingly difficult to maintain.
The combination of shorter lifetimes, intermediate rotations, and certificate transparency now addresses the core threats pinning was designed to mitigate, through automated and scalable means. The remaining argument for pinning belongs to legacy deployments — chiefly IoT devices with constrained update paths — where the tradeoff between a static trust anchor and the risk of a breaking change is increasingly difficult to justify.
Why pinning root or intermediate certificates can backfire
Certificate pinning is often applied at different levels of the certificate chain, and each level carries its own operational trade-offs. The core problem is that while pinning can restrict which certificates a client trusts, it also introduces failure modes that are easy to overlook until a renewal breaks production traffic.
Root CA pinning
Pinning a root certificate tells a client to trust only certificates issued by that specific Certificate Authority (CA). Because root certificates have lifetimes exceeding 10 years and rarely change, this approach minimizes the frequency of pin updates.
The trade-off is broad trust. Most CAs issue certificates from a single root, so pinning that root means trusting every certificate the CA issues. If the root is compromised, the blast radius includes all certificates from that CA, creating a single point of failure.
There is also a maintenance blind spot. Root certificates are rotated so infrequently that teams tend to adopt a "set and forget" mentality. CAs do occasionally change their roots, and when that happens, a properly renewed certificate will fail the pin and cause an outage. Because the pins are rarely revisited, diagnosing these outages can take significant time as engineers hunt for where old pins were configured.
Intermediate CA pinning
Pinning an intermediate certificate restricts trust to certificates issued by a specific intermediate CA that chains up to a trusted root. With lifetimes of 3 to 10 years, intermediates sit between roots and leaf certificates in both security granularity and management burden.
This approach narrows trust compared to root pinning and requires less frequent updates than leaf pinning. However, it still trusts a broad set of certificates. Intermediates also rotate more often than roots, so pins need more regular attention. A bigger issue is predictability: CAs like Let’s Encrypt issue from varying intermediates, so you cannot reliably predict which chain a renewal will use. That makes it more likely that a routine renewal breaks the pin.
Leaf certificate pinning
Pinning the leaf certificate restricts trust to one specific certificate. This offers the strongest security guarantee but is the most fragile in practice.
Leaf lifetimes have been shrinking, with 90 days becoming the norm, so pins must be updated constantly to stay in sync with renewals. Any mismatch between the pinned certificate and the renewed one results in an outage unless the renewal process is managed very carefully.
Modern alternatives to certificate pinning
The goal that pinning was meant to achieve—preventing a mis-issued certificate from intercepting traffic—can now be addressed with newer mechanisms that do not carry the same operational risk. Cloudflare recommends the following approaches instead.
Shorter certificate lifetimes
Regularly rotating certificates limits the window in which a compromised certificate can be exploited. Cloudflare issues 90-day certificates by default; customers on Advanced Certificate Manager can request TLS certificates with lifetimes as short as 14 days.
CAA records to restrict certificate issuance
Certification Authority Authorization (CAA) DNS records let domain owners specify which CAs may issue certificates for their domain. This provides a similar benefit to pinning a root CA without the hard dependency on a specific certificate chain. For example, using Google Trust Services as your CA, you can add the following record so only that CA can issue for your domain:
example.com CAA 0 issue "pki.goog"Cloudflare sets CAA records by default on behalf of customers so certificates can be issued from the CAs Cloudflare partners with. Customers can further restrict that list by adding their own CAA records.
Certificate Transparency and monitoring
Certificate Transparency (CT) logs certificate issuances in publicly accessible logs, making it possible to monitor, detect, and respond to mis-issued certificates at the moment they appear. Cloudflare customers can enable CT Monitoring to receive notifications whenever certificates are issued for their domains. The product is available to all customers and can be enabled with one click. Today, notifications cover all certificates issued for the domain; in the future, customers will be able to filter so they only hear about issuances from external parties rather than Cloudflare itself.
Multi-vantage point Domain Control Validation
Domain Control Validation (DCV) is how a CA verifies that the domain owner controls the domain before issuance. One uncommon but real attack vector involves BGP hijacking to spoof DNS responses and trick a CA into issuing a certificate for the wrong party. To counter this, CAs now run DCV checks from multiple network locations and only issue once a quorum is reached.
Cloudflare has built its own multi-vantage point DCV solution for CAs to use, and partners with CAs such as Let’s Encrypt that continue adding new check locations to reduce the risk of mis-issuance.
ACME account URI in CAA records
A recent extension to the ACME protocol lets certificate requesters specify an ACME account URI in CAA records, tying issuance to a specific authorized account. Let’s Encrypt supports this extension, allowing subscribers to set a record like this:
example.com CAA 0 issue "letsencrypt.org;accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/<account_id>"That record ensures only Let’s Encrypt can issue certificates for the domain, and only through the specified ACME account. Cloudflare plans to support this enhancement automatically for customers in the future.
The bottom line on pinning
Certificate pinning was a useful security control years ago, but the certificate ecosystem has moved on. Rather than improving security, pinning has become a common source of renewal-related outages, because it fails to account for changes in root and intermediate certification chains that are now routine.
Adopting shorter certificate lifetimes, CAA restrictions, Certificate Transparency monitoring, and multi-vantage point DCV checks addresses the original threat model of pinning without the fragility. For Cloudflare customers who are still required to pin, the only way to guarantee zero downtime during renewal is to upload custom certificates and test the renewal against the staging network to confirm the pin is updated before going live.
