2

I have an app which connects to an API. The API TLS certificate is about to expire and we are using Public key Pinning.

How do I rotate the certs without disabling access to our users?

When rotating certs; can I change the private key without changing the public key? I assume no as they are a key pair. Can someone confirm?

What would be the point of rotating the cert only to update the expiry date? Surely someone investing sufficient time to compromise the private key can continue to do if only the expiry date variable is changed?

I understand if it coming close to expiry I should update the cert to prevent unavailability of the service but then is it recommended to have a long expiry date on the next rotation?

When keys are rotated (say I leave the public and private key the same); is there anything mathematically or from an encryption perspective that changes if only the expiry date has changed?

Improve this question

1 Answer 1

Reset to default
2

can I change the private key without changing the public key?

No. You can reuse the same private and public key for another certificate but you cannot switch only the private key and use the same public key. If this would be possible then pinning to a public key for security would also not make sense.

What would be the point of rotating the cert only to update the expiry date?

What is the point of ending a certificate in the first place? To have the ability to create a new key and maybe adapt to a better key algorithm if needed. And because the owner of a domain might change so the previous owner (who has the private key) should no longer be able to (mis)use a certificate for a domain it no longer owns.

Of course, this could be done with certificate revocation. But revocation does not scale since more and more revocation information would have to be stored and checked. An expiration thus provides a way to cleanup older revocations (since the certificate is expired anyway) and with a short expiration it also limits the impact if revocation is not properly checked in the first place - as it is unfortunately the case with most uses of TLS.

Thus, it is not necessary to create a new key with each certificate but it is good to have the option to create a new key if necessary.

... but then is it recommended to have a long expiry date on the next rotation?

It is better to have short expiration but change the key only when needed. And in case of public key pinning one should also have at least a second key which then gets used for the new certificate in case the first key was compromised.

When keys are rotated (say I leave the public and private key the same); is there anything mathematically or from an encryption perspective that changes if only the expiry date has changed?

I'm not sure what you mean. There are no changes to the keys but the certificate is newly signed by the issuer to proof that the existing information in it are still valid. Thus at least the expiration time and the signature on the certificate has been changed.

Improve this answer
8
  • Thanks for your reply. You state It is better to have short expiration; but would still be the case if we are same key pair?
    – Architect
    May 5, 2020 at 8:46
  • You also state to have a 2nd key in case the first is compromised. What is the rational behind this? If the first is compromised then surely the 2nd copy is also compromised? or have i misunderstood you?
    – Architect
    May 5, 2020 at 8:47
  • When rotating certs with the same key pair; does the existing CSR also need to be used or does a new CSR need to be generated? my understanding is that CSR is essentially a new public key. so i would need to use the existing one.
    – Architect
    May 5, 2020 at 8:49
  • @Architect: "You state It is better to have short expiration; but would still be the case if we are same key pair?" - Expiration as a way to make revocation information scale. Short expiration is a way to mitigate that many clients don't even check revocation. There is no harm to reissue certificates with short expiration with the same key as long as one is sure that the key is still not compromised.
    – Steffen Ullrich
    May 5, 2020 at 13:55
  • @Architect: "You also state to have a 2nd key in case the first is compromised. What is the rational behind this?"* - the rational is to be able to issue a certificate with a key which is not compromised (the second) and use this then to invalidate the old key on the client and to also send a new backup key.
    – Steffen Ullrich
    May 5, 2020 at 13:57

You must log in to answer this question.

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