How to rotate cert when only first matching cert been verified

[David von Oheimb]

定平袁 you are welcome.

The OpenSSL version you are using is way too old!
Do not use version 1.1.0, 1.0.x, and anything older - those versions are
unsupported and must be considered insecure.

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.
I've just clarified this and some further details in
https://github.com/openssl/openssl/pull/13735.

I think Michael Wojcik already gave the right hint to solve your problem
two days before:

> Why are you appending it to the file containing the existing certificate?

So I suggest you better prepend the new certificate to that file rather
than appending it,
or even better, remove the old (non-matching) certificate from that file.

Hope this helps,

    David


P.S.: I will be unavailable for several days, too.

On 23.12.20 04:15, 定平袁 wrote:
> @David Thanks for you help!
> This is my openssl version, and the self compiled curl backend
> ```
> $ openssl version
> OpenSSL 1.0.2g  1 Mar 2016
>
> $ ldd /usr/bin/openssl  |grep ssl
> libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0
> (0x00007f3099799000)
>
> $ ldd ./lib/.libs/libcurl.so |grep ssl
> libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0
> (0x00007f8720fd4000)
> ```
> the system built-in curl binary:
> ```
> $ ldd /usr/bin/curl  |grep tls
> libcurl-gnutls.so.4 => /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4
> (0x00007f4b7fa07000)
> libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30
> (0x00007f4b7e851000)
> ```
> Actually, the old cert and new cert both are not expired yet, just the
> old cert is not consistent with server side. The new cert has the same
> content with server side imported cert(after replaced).
>
> David von Oheimb <dev at ddvo.net <mailto:dev at ddvo.net>> 于2020年12月22日周二
> 下午10:27写道：
>
>     @定平袁, which version of OpenSSL are you using?
>
>     I've just checked: since OpenSSL 1.1.0, expired certificates are
>     effectively not used for chain building.
>
>         David
>
>     On 20.12.20 02:02, 定平袁 wrote:
>>     the exact behavior:
>>
>>     When looking up CA certificates, the OpenSSL library will first
>>     search the certificates in *CAfile*, then those in *CApath*.
>>     Certificate matching is done based on the subject name, the key
>>     identifier (if present), and the serial number as taken from the
>>     certificate to be verified. If these data do not match, the next
>>     certificate will be tried. If a first certificate matching the
>>     parameters is found, the verification process will be performed;
>>     no other certificates for the same parameters will be searched in
>>     case of failure.
>>
>>     why no other certificates for the same parameters will be searched?
>>
>>     定平袁 <pkudingping at gmail.com <mailto:pkudingping at gmail.com>>
>>     于2020年12月20日周日 上午8:59写道：
>>
>>         Hello everyone,
>>
>>         Recently I am trying to rotate a cert, and the client uses
>>         python requests lib, which leverages openssl. Here is my steps:
>>
>>         1. Generate a new cert, and append it to the cert file(at
>>         this point, there are 2 certs in the file, first is old cert,
>>         second is new, they have the same Subject), restart client
>>         side process, (no problem here, because first cert matching
>>         server side cert, and it verifies successfully)
>>         2. Replace server side with new cert.
>>
>>         As soon as I issue step #2, the client side process starts to
>>         show error “certificate verify failed”. This would cause
>>         downtime to my apps. I am new to this, not sure if there is
>>         anything wrong regarding my usage or understanding. But I
>>         found this page
>>         https://www.openssl.org/docs/man1.0.2/man3/SSL_CTX_load_verify_locations.html,
>>         it says the exact behavior like my test:
>>
>>         If several CA certificates matching the name, key identifier,
>>         and serial number condition are available, only the first one
>>         will be examined. This may lead to unexpected results if the
>>         same CA certificate is available with different expiration
>>         dates. If a "certificate expired" verification error occurs,
>>         no other certificate will be searched. Make sure to not have
>>         expired certificates mixed with valid ones.
>>
>>         So I am wondering how to rotate cert in such a case? It would
>>         be very helpful if anyone could help on this. Thanks.
>>
>>         BTW, I tested the same cert file with CURL (compiled with
>>         gnutls), it works fine.
>>
>>         Regards
>>         Dingping
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20201223/ca6bc9c3/attachment-0001.html>