On 23.12.20 23:56, openssl-users-request@xxxxxxxxxxx digested: > Message: 4 > Date: Wed, 23 Dec 2020 23:56:44 +0100 > From: David von Oheimb <dev@xxxxxxxx> [...] > 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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
