openssl in head returning "certificate expired" when it has not expired

Rick Macklem rmacklem at uoguelph.ca
Tue Feb 2 03:48:08 UTC 2021


Benjamin Kaduk wrote:
>On Tue, Feb 02, 2021 at 12:46:25AM +0000, Rick Macklem wrote:
>> I've recently been testing the daemons that do the
>> non-application data stuff for nfs-over-tls with the
>> openssl in head.
>>
>> These daemons work fine with both ports/security/openssl (openssl-1.1.1h)
>> and ports/security/openssl-devel (openssl3-alpha).
>>
>> However, when linked to the openssl in head, the basic handshake
>> and KTLS works, but the peer certificate from the client is reported
>> as expired by SSL_get_verify_result(), although it is still valid.
>> I added some debug output and the "notAfter" field of the
>> certificate looks correct, so the certificate doesn't seem to be
>> corrupted.
>>
>> I tried backporting the changes in crypto/x509 in head back
>> into ports/security/openssl and it still worked, so those changes
>> do not seem to have caused the problem.
>> There are several differences in the configured options, but I cannot
>> see any other differences between ports/security/openssl and
>> what is in head that could cause this.
>> (The options that differ seem related to old encryption types, etc.)
>>
>> Any other ideas for tracking this down?
>
>Is it perhaps related to https://github.com/openssl/openssl/issues/14036 ?
Well, it is definitely due to a change in behaviour between 1.1.1h and 1.1.1i.
I notices that ports/security/openssl has been upgraded to 1.1.1i and it
exhibits the "expired" behaviour.

However, in my case, the certificate has not expired.
The notAfter date is in 2022, but SSL_get_verify_results() returns
X509_V_ERR_CERT_HAS_EXPIRED.

rick

-Ben
_______________________________________________
freebsd-current at freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"



More information about the freebsd-current mailing list