In my application, the human user accepts the server's X.509 certificate, verifying the fingerprint during the first-time connection. The fingerprint is stored in the client software. At later connections, only that particular certificate is accepted by the client.

If the server renews own certificate, the fingerprint naturally does not match any more and the user has to verify and accept the new fingerprint again.

I want to relax this restriction and accept this certificate, and also any renewal (maybe even rekey) of it.

The server certificate is issued by a CA, which is trusted by the client software. So my new check at the client side will be like:

  1. Check that the fingerprint matches the recorded one. Accept connection if yes.
  2. Check that the certificate is issued by a trusted CA. Reject connection if not.
  3. Check if this is a renewed previous certificate, accept connection if yes, reject otherwise.

Question: How can the last check be implemented? How can I know that a certificate C2 is in fact a renewal (or rekey) of another certificate C1?

3 Answers 3


So you need either the CA or the client to tell you that the certificate was renewed. I can guess there are a few ways to approach this...

Renewal + Same Subject

A client holding the old cert and new cert could use the private key of each certificate, and sign the new cert, thus proving they have knowledge of both keys.

A server that revokes a certificate should mark it in the CRL as superseded. I am not certain if both the RFCs and the software (Microsoft FIM or AD CS) supports multiple revocation reasons, and how that may confuse your software.

Renewal + Different Subject Name

If a renewed key can change the subject name (e.g. a name change of a user via marriage) or SAN, then you will need a custom field in the certificate to link the previous certificate together. I hope that this kind of field is standardized in an RFC somewhere....??

If this is supported, then I would question the need for a PKI or CA anyway since a simpler solution might be based solely on thumbprints (SSH)


This gets a little hairy if the previous key is revoked, where a thief could replace the old certificate with a new one. In addition to revocation logic, you will need logic to address an outage of a revocation server, and perhaps have a new key window that would handle the situation where a thief steals a key, changes the primary authentication key, and the user needs to communicate with the old "unrenewed" key.

Microsoft has key based renewal, where a thief could renew and lock out the user, so don't be under the assumption that a renewed certificate always has more assurance than the identity you're currently using.


Set up your own CA. Hard code this CA into your app. Check if certificate is issued by this CA. Ditch the fingerprint verification. Renewals are not an issue in this scenario.

Or: alternatively: have the old cert/key sign the new cert/key for renewals. Send that signature along when you need to renew.

  • I cannot restrict the trust to only one hardcoded CA; there are scenarios when an external CA (configurable at the client side) must be used. Giving up the fingerprint verification check is a big thing... but signing the new cert with the old one is something to consider. Thank you, +1. Jan 4, 2015 at 16:59
  • Ouch, no +1 yet, not enough reputation :) Jan 4, 2015 at 17:01

I don't believe that this is safe I'm afraid. Without further user interaction, how would you know whether the new certificate is valid & that it wasn't a man-in-the-middle attack?

If you continue to accept updated certs without manual checking, you will get less and less security over time.

By the way, if you want real security, you will need an additional check that must be done fairly often and that is to check the Certificate Revocation List for the authorising authority. How often you check for revocation depends on the type of application and how secure you need it to be.

Check out the RFC (RFC5280) for details.

  • Thank you for the notes; being fully valid, I believe they more qualify as a comment, not as an answer to the asked question. In my case, the decision to lower the security level in favor of usability is deliberate. Jan 3, 2015 at 4:21
  • Well, it is an answer of sorts - I don't recommend that you do it. If you don't need the level of security PKI is meant to provide, why use it all all? If you do want to use it, don't break it - that is how so many security problems propagate across the Internet. And certainly don't ask in THIS group how to misuse the standards! Jan 4, 2015 at 17:17
  • There is no question about how to misuse the standard. The requirements in my situation are more strict than in a typical PKI-based scenario: normally, just a certificate from a trusted CA is required (probably with matching Subject or SubjectAltName or other fields), while in my setup there are additional checks. I just want to relax these additional checks. Jan 4, 2015 at 17:24

You must log in to answer this question.

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