Certificate Pinning Pitfalls: Why Rotation Breaks Apps

Vladimir Kocjancic — Thu, 05 Mar 2026 22:22:37 +0000

You went and implemented certificate pinning in your app. You tested it and it worked perfectly.

Fast forward a few months and your users cannot connect. You haven't changed the code for ages. So you check your API and it works fine, but your app? Not so much.

The problem: certificate rotation. Something completely outside your control that managed to break your application. Most likely in the most awkward way and at the least desirable or expected time.

What is certificate rotation?

Certificate rotation is the process of replacing an existing certificate with a new one. Certificates require rotation for several reasons:

Expiration – some certificates expire more often than others (yes, I'm looking at you, Let's Encrypt)
Revocation – the certificate has been compromised or invalidated
Algorithm upgrades – moving from SHA-1 to SHA-256, for example
Domain changes – adding or removing domains from the certificate

Expiration you can plan for. Other rotations are silent, unpredictable. And by the time you notice, users have already noticed. By then, it's too late.

Why does my app break?

Certificate pinning is based on a certificate's public key, hash, trust chain, or other metadata. When the certificate changes, some (if not all) of that data changes too—causing validation to fail.

Certificate hash and public key change with each new certificate.
Trust chain changes less frequently, but pinning only the chain is insecure and weak. If you only check the chain, you're effectively accepting any certificate from that chain. And that defeats the purpose of pinning.

What can I do to avoid downtime?

Set expiration reminders

The easiest thing to do is set up calendar reminders for when your certificates expire. You can't fix what you don't know is expiring.

Pin the SPKI, not the whole certificate

Some Certificate Authorities (CAs) allow renewal with the same key pair. If you control the server and configure this, the certificate's public key will remain unchanged. But by default, many renewals generate a new key.

Still, pinning the Subject Public Key Info (SPKI) is a decent solution. SPKI is the part of the certificate that contains the actual public key and its algorithm. Pinning this survives renewal if the key pair stays the same.

// Extract SPKI for pinning in .NET
byte[] spki = certificate.GetPublicKey();
string spkiHash = Convert.ToBase64String(SHA256.Create().ComputeHash(spki));

Implement backup pins

Keep at least two pins: the current certificate and a backup. You can use your CA's root or intermediate certificate for this. When rotation happens, your application still trusts the backup while you update the primary.

Yes, you'll need to refresh the list over time. But your users won't experience downtime.

Get notified before things break

This is exactly why I'm building CertWatch. The app tracks your certificates and alerts you:

90/60/30/14/7/1 days before expiry
Immediately on unexpected rotation events

The alert includes the new public key so you can update your pinned app before it breaks. You'll know before your users do.

Conclusion

Certificate pinning makes your app more secure. But without handling rotation, it makes your app brittle and prone to unexpected outages.

Pin SPKI, keep backups, and set reminders. Do that, and you won't be waking up to a bunch of angry emails and calls in distress

Implementing Certificate Pinning in .NET: A Step-by-Step Guide

Vladimir Kocjancic — Thu, 05 Feb 2026 22:06:53 +0000

Certificate pinning is a security technique where a client (like a mobile or desktop app) associates a specific server with an expected X.509 certificate or public key. When the client connects to the server, it verifies that the certificate presented matches the one it knows.

Why Pin Certificates?

The primary reason for pinning is to prevent man-in-the-middle (MITM) attacks where an attacker intercepts communication using a fake or invalid certificate. Pinning ensures your app only talks to a server you trust.

The implementation

We will create a simple command line application that fetches source code of my SaaS product web site CertWatch. Why command line? Because, it is good enough example that will work everywhere else and because it is isolated enough that it is easy to follow even for a casual tech follower.

The site uses Let's Encrypt certificate, that changes quite often, so beware that certificate public key used in this sample may not be valid at the time you read this article.

First, we need to obtain public key of server certificate. We can do this by either viewing certificate in the browser or use a tool like openssl.

private static string g_ssPublicKey =       "3082010A0282010100C4FFFFE6F3945AD2BF27D5DD674166130D5D2021CEFF0" +
"4B06AD48F5F56A6245C590433121C8F08B7A565FBF38F1102917CB7434AFE91" +
"18E2CB904BA723D57182B680B872CF05578B234F65DB1A39CD77DEBD07D0939" +
"A0C440A9AE9245D0CAB59480DC3864D744BA6404B0D6DA9BAEE0E85CE0816D9" +
"D7F43468D2E073CBA2EA10114323B0053F8AE29F86AD846B71FE4D7924494FB" +
"0D80E3C78875085163B53121EBEBCF1356A4386DFF9E2CB93D0BD9CA3A39D4A" +
"AC7BB34F2FF4AC70D59DBCD92254D48DE0BC3CCB4A8B4822D64CCE46F1E539B" +
"116A00420825AD2AFF128F7A761D79186FB747761E47187BD527B1398F603DC" +
"F7DCABD3535C28B7FB2C3068230203010001";

In the program Main function, we will use HttpClient to connect to the web site. In order to set certificate handling and verification, we must first declare HttpClientHandler. The handler must do at least three things:

enable Certificate Revocation List check to check that certificate has not been revoked
set client certificate options to Manual, as we are going to manually validate certificate
implement server certificate validation callback method to perform validation.

Before we implement the callback method, let’s set a boiler plate for it and set first two items on the list. Validation method will return false and thus fail on every request.

using var handler = new HttpClientHandler(); 
        handler.CheckCertificateRevocationList = true;
        handler.ClientCertificateOptions = ClientCertificateOption.Manual;
        handler.ServerCertificateCustomValidationCallback = (message, certificate, chain, sslPolicyErrors) => { return false; };

Great. With that done, we can implement the body of the callback function. First, we need to check if the server web site certificate actually exists. If it doesn't we return false and print an error. Here, you would do some logging instead, but this is a demo app.

if (null == certificate)
{
    Console.WriteLine("ERROR: No server certificate found");
    return false;
}

Next, we verify there are no SSL policy errors in certificate chain. If they are, we return false and print all policy errors.

if (sslPolicyErrors != SslPolicyErrors.None)
{
    Console.WriteLine($"SSL Policy Errors: {sslPolicyErrors}");
    return false;
}

Then, we obtain, the public key of server certificate and check if it matches the one, we declared in our app. If there is no match, we again print an error and return false. If public keys match, then the certificate is correct and we successfully end validation.

string sPublicKeyToVerify = certificate.GetPublicKeyString();
if (g_ssPublicKey != sPublicKeyToVerify)
{
    Console.WriteLine("ERROR: Certificate public key mismatch");
    return false;
}

Console.WriteLine("Certificate public key matches");
return true;

Now, all we have to do, is call our website and print it's source code. The validation procedure will run immediately after SSL handshake is established.

using var httpClient = new HttpClient(handler);
string sResponse = await httpClient.GetStringAsync("https://certwatch.dev");
Console.WriteLine(sResponse);

In less than 50 lines of code, we have implemented a working, robust certificate pinning that ensures our app only communicates with our genuine API server. This simple technique significantly raises the bar against possible man-in-the-middle attacks.

Complete working example is embedded below. If you cannot see it, it is also published as gist on Github.

The Operational Challenge

While the code is straightforward, the ongoing management of pinned certificates is not. Teams must track expiry dates, coordinate rotations, and update client apps. This usually ends up as a manual process, which is prone to error and often the cause of preventable outages.

If managing this process across multiple APIs feels like a burden that is likely to cause a production incident, you might be interested in CertWatch, a tool I'm building to automate SSL certificate monitoring and alerting.

This article was originally published on lotushints.com.

Forem: Vladimir Kocjancic