From: Ubuntu <[email protected]> Root-cause follow-up to the "CRL: cannot read CRL from file" report (GitHub #1103, PR #1104, Gerrit change 1950 for v1 of patch 1).
Changes in v2: Patch 1 takes the shape Arne suggested on the PR review: cipher_get() returns NULL for "none" before touching OpenSSL, no error marks and no wolfSSL shim, so cipher_valid_reason() keeps finding the OpenSSL reason on the queue when it reports an unknown cipher (Razvan's point on Gerrit 1950). The CBC-sibling probe in cipher_kt_block_size() and md_valid() are left as they are and named in the commit message; measured on the same rig, the entry the CHACHA20-CBC probe leaves does not survive to the next client instance. Patch 2 is unchanged. Validated again on the aarch64 Ubuntu 26.04 server (OpenSSL 3.5.5, DCO) with gdb watching the queue: five client instances (UDP, TCP, CHACHA20-POLY1305, a plain one after it, and one against a garbage CRL) enter multi_create_instance() and backend_tls_ctx_reload_crl() with an empty queue, four CRL replacements give four clean reloads, the garbage CRL still fails with "loaded 0 CRLs" / "VERIFY ERROR: CRL not loaded". Drew Blokzyl (2): Do not look up the "none" cipher in OpenSSL Make CRL reload EOF detection independent of stale error queue entries src/openvpn/crypto_openssl.c | 9 +++++++++ src/openvpn/ssl_openssl.c | 13 +++++++++++-- 2 files changed, 20 insertions(+), 2 deletions(-) -- 2.53.0 _______________________________________________ Openvpn-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openvpn-devel
