This is the root-cause follow-up to the "CRL: cannot read CRL from file" report (GitHub #1103, PR #1104, which Arne rightly called a symptom fix).
Traced with gdb on OpenVPN 2.7.0 and master against OpenSSL 3.5.5: the entry that misleads the CRL reload is left by cipher_get() being asked for the cipher "none". That is the pre-negotiation key_type every server without --cipher gets (BF-CBC default, not in --data-ciphers), and every new client instance walks it in do_init_crypto_tls() and the frame/OCC calculations. cipher_kt_block_size()'s CBC-sibling probe and md_valid() have the same shape. Patch 1 makes those probing lookups leave the queue as they found it (ERR_set_mark/ERR_pop_to_mark, with a wolfSSL fallback in openssl_compat.h). Patch 2 is the earlier CRL-side change, kept as hardening: the EOF test now looks at the error PEM_read just raised rather than the oldest queued one, so no other leftover can produce the warning either. Validated on an aarch64 Ubuntu 26.04 server (DCO) with UDP, TCP and CHACHA20-POLY1305 clients: the queue is empty at multi_create_instance() and at backend_tls_ctx_reload_crl() entry, three CRL replacements give three clean reloads (unpatched: three warnings), and a garbage CRL still fails with "loaded 0 CRLs" / "VERIFY ERROR: CRL not loaded". Not compile-tested against wolfSSL; the shim is two static inlines. Drew Blokzyl (2): Drop the OpenSSL errors a failed cipher/digest lookup leaves behind Make CRL reload EOF detection independent of stale error queue entries src/openvpn/crypto_openssl.c | 16 +++++++++++++++- src/openvpn/openssl_compat.h | 18 ++++++++++++++++++ src/openvpn/ssl_openssl.c | 13 +++++++++++-- 3 files changed, 44 insertions(+), 3 deletions(-) -- 2.53.0 _______________________________________________ Openvpn-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openvpn-devel
