• Let's assume that we have a client application talking to a server via SSL.
  • Let's also assume that the client is using SSL certificate pinning, i.e. the client will refuse the server certificate unless it conforms to a specific hard coded one the client was released with.

As certificates have expiration dates, the pinned certificate of the server will eventually have to be replaced. This process generally calls for some application/client side update to make the client aware of the new certificate 'to pin'.

Are there best-practices on how this transition/change can be managed?

I'm thinking of something more sophisticated than two people pressing a button at the same time (i.e. the server cert being updated and the application forcing the user to update)... The organisational processes involved here can be non-trivial, especially since the release and maintenance cycles of client/server/operations might be running according to different schedules and priorities.

Maybe something like (I'm just writing down a rather naive approach here):

  • Client has multiple certificates stored for the server, with different but overlapping validity periods.
  • If one pinned certificate is expired the client checks if he has a different still valid one...

--> This would allow new 'pinned' certificates for a server to be delivered well in advance of actually switching certificates on the server.

  • It may be possible to hard-code-in the server's public key signature instead of the certificate itself? The server's public key remains the same even after certificate renewal/replacement. Commented Jan 30, 2017 at 13:27
  • SSL Pinning is not, by and large, compatible with uninterrupted service. Secure, Available... pick 1. If you're writing your own application, and want to pre-publish acceptable certs, and have it pin to multiple certs - that'll work. But in the general case, you have no control over when the cert changes, and cannot expect notice, so you'll have downtime. It's a tradeoff.
    – gowenfawr
    Commented Jan 30, 2017 at 15:23

1 Answer 1


You can pin more than one certificate, and you should pin at least 2. If somehow you lose access to one certificate, you can use the second. With only one certificate, nobody that connected to your site with pinning enabled will be able to connect to your site via HTTPS until the certificate expire (but they can connect via HTTP). If you employed HSTS, nobody that ever connected will be able even via HTTP.

So, as long as you have a valid certificate, you can alter your webserver configuration to send the current and the new certificate on the same response, and the browsers will cache the new one too.

For example, your server uses the current setup:

Public-Key-Pins: max-age=2592000;

And the certificate with fingerprint abcd9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g= is to expire in 2 months. You just alter the server configuration to add the new certificate LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ= with the response headers:

Public-Key-Pins: max-age=2592000;

But if you let the certificate expire, you have to wait until the max-age expires to be able to send another certificate.

  • I read about public key pinning... Is this the go-to way to solve this issue? Are there any drawbacks in using public key pinning vs. cert pinning?
    – fgysin
    Commented Jan 30, 2017 at 14:47
  • Public key pinning is usable when you don't want to depend on a CA (a mobile app, for example), and Certificate Pinning is when you don't trust all CAs around the world. Drawback? Someone hacks into your server, puts a valid cert from them on your server and waits 3 months, nobody notices because everything is working. They hack back, delete the cert and ask ransom. If you don't pay, say goodbye to anyone that connected on the last 3 months. Issuing another cert does nothing, asking every client to delete their caches is not practical.
    – ThoriumBR
    Commented Jan 30, 2017 at 17:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .