A third party server sends us signed messages that we verify. When its certificate is about to expire, the third party generates a new key pair and sends us the new certificate.

At some point, the server will start signing with its new key, requiring that we use the corresponding new certificate to verify.

How can we make this two-side replacement process accurate and easy? It would be a hassle if any messages were rejected due to timing issues (i.e. party A switches, then a message is sent, then party B switches).

An obvious solution might be to try all non-expired keys, but that seems like code pollution. Particularly because we only face this challenge in some scenarios, meaning some occurences of signature verification have to bother with multiple certificates, while others do not.

Another idea is to specify a timestamp. However, server clocks might not be in sync, and memory caches (e.g. with a 15-minute expiration) would interfere even more.


How can we make this two-side replacement process accurate and easy?

The conventional way to do this is to support multiple certificates in the verification side. The verifier side should install the new certificates, which should work side by side. The signer then can swap to the new certificate at the time of their choosing before the old certificate expires.

Note that in most use cases of asymmetric cryptography, the verifier generally would need multiple certificate support anyway because the verifier might need to verify old messages using expired certificates. In these cases, the user should be notified that the verification is successful with an expired certificate.

If you really can't support multiple certificate, you would need a synchronized downtime. First, the signer is taken down, and it flushes all unsent messages; then after the verifier finished processing all pending messages, the verifier is taken down. After both asides updated their certificates, the services can be brought up again. If the signer is capable of queueing unsent messages to be resent later, then the signer can restore service at any time after the verifier is confirmed to be down; otherwise the signer had to wait for the verifier to be up before starting up.

If you really can't tolerate downtime every time the certificate expires, then what you could do is use a certificate chain verification. In this scheme, you'd create a long-lived root certificate (e.g. 10 years or more), which is used to certify shorter lived leaf certificates (e.g. six month, yearly); the verifier would accept any certificates that are anchored to the root certificate. You'd still need to synchronize downtimes to replace a root certificate, but replacing leaf certificates wouldn't need to be synchronized. You would need to guard your root certificate very dearly though, because this root certificate is hard to replace if compromised.


You can solve this by using deployment tools such as Chef or Ansible.

Particularly about Chef, you have the Chef Push to push whatever cookbook (i.e. the key files) to all the nodes (i.e. the servers).

  • Very quick, thank you! However, we do not own or control the third party server. We can certainly suggest something to them, but dealing with various third parties makes it less feasible. – Timo Jun 27 '16 at 9:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.