Skip to content

Fix compatibility with upcoming OpenSSL 4.0#70

Merged
DDvO merged 5 commits intomasterfrom
fix_OpenSSL_4_0_compat
Jan 15, 2026
Merged

Fix compatibility with upcoming OpenSSL 4.0#70
DDvO merged 5 commits intomasterfrom
fix_OpenSSL_4_0_compat

Conversation

@DDvO
Copy link
Member

@DDvO DDvO commented Jan 14, 2026

Unfortunately, OpenSSL 4.0 plans to deprecate X509_cmp_timeframe() and X509_cmp_time().
To work around this, introduce UTIL_cmp_timeframe() and CRL_check() making use of the newly exported X509_check_certificate_times() function where needed.

Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This pull request addresses upcoming compatibility issues with OpenSSL 4.0, which plans to deprecate X509_cmp_timeframe() and X509_cmp_time(). The changes introduce new wrapper functions UTIL_cmp_timeframe() and CRL_check() that abstract the version-specific implementations and use the newly exported X509_check_certificate_times() function for OpenSSL 4.0+.

Changes:

  • Introduced UTIL_cmp_timeframe() wrapper function to handle time frame checking across OpenSSL versions
  • Added CRL_check() function for consistent CRL validity checking
  • Renamed parameter uri to src across certificate and CRL checking functions for better clarity

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 6 comments.

Show a summary per file
File Description
src/libsecutils/src/storage/files.c Added unused parameter suppressions for OPENSSL_NO_ENGINE builds
src/libsecutils/src/credentials/store.c Replaced local crl_expired() with UTIL_cmp_timeframe() call
src/libsecutils/src/credentials/cert.c Implemented UTIL_cmp_timeframe() with version-specific logic and updated CERT_print() for OpenSSL 4.0
src/libsecutils/src/certstatus/crls.c Introduced CRL_check() function and added src parameter to check_cert_crls()
src/libsecutils/src/certstatus/certstatus.c Updated check_cert_crls() call with new signature
src/libsecutils/include/secutils/credentials/cert.h Added UTIL_cmp_timeframe() declaration and updated parameter names from uri to src
src/libsecutils/include/secutils/certstatus/crls.h Added CRL_check() declaration and updated check_cert_crls() signature

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated no new comments.


💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

#elif OPENSSL_VERSION_NUMBER < 0x40000000L
return X509_cmp_timeframe(vpm, start, end);
#else
X509 *dummy_cert = X509_new(); /* needed as a workaround for OpenSSL API restriction */
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if i got this correctly, we just want to check if time A is between start time B and end time C.
so:

if B - A < 0 we are after the start time (100 - 101 = -1) -> certificate valid
else we are before B and the certificate is not yet valid

and if C - A < 0 we are after the end time -> certificate expired
else we are before the end time and certificate is valid

this should be realizable farely easy with time.h difftime.

why not use such an approach instead?

Copy link
Member Author

@DDvO DDvO Jan 15, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for having a look at this and your comment.

I agree there should be a fairly easy way to do this,
but unfortunately things are tricky because the ASN1_TIME values may be invalid and need to be converted to time_t, or likely better int64_t, before being able to do the comparisons.

I've just extended this way my yesterday's complaint about that recent OpenSSL move:
openssl/openssl#29638 (comment)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we wait with merging until this is clarified?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question.
So far it is very unclear to me when and how the OpenSSL colleagues will react to that issue.

I suggest that we tentatively merge this PR,
and if/when there is good reason to adapt UTIL_cmp_timeframe(), we can do in a follow-up PR.
The new workaround code anyway will not take effect until someone uses OpenSSL 4.0.

I'm glad that I came across the issue some time before the release, so there is some chance to get it fixed by then.

@DDvO DDvO force-pushed the fix_OpenSSL_4_0_compat branch from 83e3b04 to 98be68c Compare January 15, 2026 10:55
@DDvO DDvO merged commit 3e3d777 into master Jan 15, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants