How to rotate cert when only first matching cert been verified

[Jochen Bern]

On 23.12.20 23:56, openssl-users-request at openssl.org digested:
> Message: 4
> Date: Wed, 23 Dec 2020 23:56:44 +0100
> From: David von Oheimb <dev at ddvo.net>
[...]
> Yet since both your old and new server cert are not expired and have the
> same subject, keyIdentifier, and serial number,
> and you appended the new server cert to your list, it is no surprise
> that the certificate chain building algorithm will pick up the old one.
> For efficiency reasons, no other (equally applicable) certificates will
> be tried.

To expand on the "*should* you actually do it like this" angle: I do not
see any reason why the new server cert (SC) should have *the same serial
number* (SN) as the old one.

At least in the general case - where the CA and the server are run by
different entities -, the CA wants(*) to be able to revoke old and new
SC separately, and CRLs identify revoked certs exclusively by the
issuing CA Cert (CC) and the revoked cert's SN.

So, what *is* the rationale to reuse the SN? Do you have a
"verification" mechanism somewhere that (cannot be updated in a timely
manner for the new SC and) would protest a changed SN, but *not* the
changed validity period (or, for that matter, fingerprint or CA
signature)? Note that the mere thought already makes me put quote marks
around "verification" ...

Disclaimer: I'm *not* saying that merely using different SNs will make
the problem you're currently experiencing disappear. In fact, I consider
that rather unlikely, but it might be one contributing factor.

(*) Scenario 1: Before the old SC expires, the CA finds out that it
issued a new SC to an imposter, so they now want to revoke the new but
not the old. Scenario 2: The old SC is found to have been leaked after
the new one was already issued, so at least the server admin would
prefer to have the old SC revoked but *not* the new one.

Kind regards,
-- 
Jochen Bern
Systemingenieur

Binect GmbH

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20201224/df6a7b4e/attachment.bin>