"No shared cipher" error but listed in preferred ciphers
Hello, I try to recycle some old HPE switches as radius client using EAP-TLS based protocols for test only. They are using old deprecated ciphers, so i rebuild openssl for legacy suites on a raspbian (I know, it's bad idea and not secure). # openssl ciphers -v ALL | grep RC4 RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 So, when the server freeradius and the switch try to negociate, i can see in the logs that the cipher RC4-MD5 is now common for the two devices. ... Thu Nov 20 15:11:44 2025 : Debug: (26) eap_ttls: Authenticate Thu Nov 20 15:11:44 2025 : Debug: (26) eap_ttls: (TLS) EAP Continuing ... Thu Nov 20 15:11:44 2025 : Debug: (26) eap_ttls: (TLS) EAP Peer sent flags --- Thu Nov 20 15:11:44 2025 : Debug: (26) eap_ttls: (TLS) EAP Verification says ok Thu Nov 20 15:11:44 2025 : Debug: (26) eap_ttls: (TLS) EAP Done initial handshake Thu Nov 20 15:11:44 2025 : Debug: (26) eap_ttls: (TLS) TTLS - Handshake state [PINIT] - before SSL initialization (0) Thu Nov 20 15:11:44 2025 : Debug: (26) eap_ttls: (TLS) TTLS - Handshake state [PINIT] - Server before SSL initialization (0) Thu Nov 20 15:11:44 2025 : Debug: (TLS) Ignoring cbtls_msg call with pseudo content type 256, version 00000301 Thu Nov 20 15:11:44 2025 : Debug: (26) eap_ttls: (TLS) TTLS - Handshake state [PINIT] - Server before SSL initialization (0) Thu Nov 20 15:11:44 2025 : Debug: (TLS) Received 58 bytes of TLS data Thu Nov 20 15:11:44 2025 : Debug: (TLS) 01 00 00 36 03 01 cf 30 f0 07 73 5d 30 36 71 27 Thu Nov 20 15:11:44 2025 : Debug: (TLS) 65 2c ce 16 e6 41 0c 35 b4 d3 4c 9d 3a d2 8e 78 Thu Nov 20 15:11:44 2025 : Debug: (TLS) a9 5b 3d ac a5 a9 00 00 04 00 04 00 ff 01 00 00 Thu Nov 20 15:11:44 2025 : Debug: (TLS) 09 00 23 00 00 00 0f 00 01 01 Thu Nov 20 15:11:44 2025 : Debug: (26) eap_ttls: (TLS) TTLS - recv TLS 1.3 Handshake, ClientHello Thu Nov 20 15:11:44 2025 : Debug: (TLS) Ignoring cbtls_msg call with pseudo content type 256, version 00000301 Thu Nov 20 15:11:44 2025 : Debug: (TLS) Received 2 bytes of TLS data Thu Nov 20 15:11:44 2025 : Debug: (TLS) 02 28 Thu Nov 20 15:11:44 2025 : Debug: (26) eap_ttls: (TLS) TTLS - send TLS 1.0 Alert, fatal handshake_failure Thu Nov 20 15:11:44 2025 : ERROR: (26) eap_ttls: (TLS) TTLS - Alert write:fatal:handshake failure Thu Nov 20 15:11:44 2025 : ERROR: (26) eap_ttls: (TLS) TTLS - Server : Error in error Thu Nov 20 15:11:44 2025 : Debug: (26) eap_ttls: Server preferred ciphers (by priority) Thu Nov 20 15:11:44 2025 : Debug: (26) eap_ttls: (TLS) [0] TLS_AES_256_GCM_SHA384 Thu Nov 20 15:11:44 2025 : Debug: (26) eap_ttls: (TLS) [1] TLS_CHACHA20_POLY1305_SHA256 ... Thu Nov 20 15:11:44 2025 : Debug: (26) eap_ttls: (TLS) [166] RC4-MD5 Thu Nov 20 15:11:44 2025 : Debug: (26) eap_ttls: (TLS) [167] PSK-RC4-SHA Thu Nov 20 15:11:44 2025 : Debug: (26) eap_ttls: (TLS) TTLS - Client preferred ciphers (by priority) Thu Nov 20 15:11:44 2025 : Debug: (26) eap_ttls: (TLS) [0] RC4-MD5 ... But i still got an error "no shared cipher" ... Thu Nov 20 15:11:44 2025 : ERROR: (26) eap_ttls: (TLS) Failed reading from OpenSSL: ../ssl/statem/statem_srvr.c[2333]:error:0A0000C1:SSL routines::no shared cipher Thu Nov 20 15:11:44 2025 : ERROR: (26) eap_ttls: (TLS) System call (I/O) error (-1) Thu Nov 20 15:11:44 2025 : ERROR: (26) eap_ttls: (TLS) EAP Receive handshake failed during operation Thu Nov 20 15:11:44 2025 : ERROR: (26) eap_ttls: [eaptls process] = fail Thu Nov 20 15:11:44 2025 : ERROR: (26) eap: Failed continuing EAP TTLS (21) session. EAP sub-module failed ... Below, some samples of my configuration: ## cat /etc/os-release PRETTY_NAME="Raspbian GNU/Linux 13 (trixie)" ## dpkg -l | grep freeradius ii freeradius 3.2.7+dfsg-1+deb13u1+rpt1 ## mods-available/eap ## eap { default_eap_type = tls ... tls-config tls-common { ... cipher_list = "ALL@SECLEVEL=0" cipher_server_preference = no tls_min_version = "1.0" tls_max_version = "1.3" ecdh_curve = "" ... ... ## /etc/ssl/openssl_legacy.cnf ## [openssl_init] providers = provider_sect [provider_sect] default = system_default_sect legacy = legacy_sect [legacy_sect] activate = 1 MinProtocol = SSLv3 CipherString = ALL@SECLEVEL=0 [system_default_sect] activate = 1 MinProtocol = SSLv3 CipherString = ALL@SECLEVEL=0 Is this mandatory to use tls_min_version/max options since the deprecated cipher i try to use belong to SSLv3 suite ? Do you have some hints to help debug further please ? Thank you in advance. Best regards, -- Nicolas Godbert
On Nov 24, 2025, at 5:26 AM, Nicolas Godbert via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
I try to recycle some old HPE switches as radius client using EAP-TLS based protocols for test only. They are using old deprecated ciphers, so i rebuild openssl for legacy suites on a raspbian (I know, it's bad idea and not secure).
If it works...
# openssl ciphers -v ALL | grep RC4 RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5
Ugh, but OK.
So, when the server freeradius and the switch try to negociate, i can see in the logs that the cipher RC4-MD5 is now common for the two devices.
That's good.
But i still got an error "no shared cipher"
... Thu Nov 20 15:11:44 2025 : ERROR: (26) eap_ttls: (TLS) Failed reading from OpenSSL: ../ssl/statem/statem_srvr.c[2333]:error:0A0000C1:SSL routines::no shared cipher
This might be "no shared message digest", or something else. Unfortunately, this is all OpenSSL magic, and it's hard to know what's going on inside of OpenSSL.
.. cipher_list = "ALL@SECLEVEL=0" cipher_server_preference = no tls_min_version = "1.0"
That should all be good.
Is this mandatory to use tls_min_version/max options since the deprecated cipher i try to use belong to SSLv3 suite ?
Yes. You can (in theory) use some newer ciphers with TLS 1.0, or older ciphers with TLS 1.3. So you have to enable everything in order for it to work.
Do you have some hints to help debug further please ?
This is all OpenSSL magic. Unfortunately, the RC4-MD5 ciphers have been deprecated for decades. We can't help a lot here. Perhaps the OpenSSL people can help. Alan DeKok.
Not a suggestion on your entryption issue, but have you checked to see if there are firmware updates available for your old switches? The original HP (now HPE) was pretty good about providing firmware for those old switches (back in the day when they made them from real metal ;) On Mon, 24 Nov 2025, Nicolas Godbert via Freeradius-Users wrote:
Hello,
I try to recycle some old HPE switches as radius client using EAP-TLS based protocols for test only. They are using old deprecated ciphers, so i rebuild openssl for legacy suites on a raspbian (I know, it's bad idea and not secure).
# openssl ciphers -v ALL | grep RC4 RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5
So, when the server freeradius and the switch try to negociate, i can see in the logs that the cipher RC4-MD5 is now common for the two devices.
[snip...]
Do you have some hints to help debug further please ? Thank you in advance.
Best regards,
-- Dave Funk University of Iowa <dbfunk (at) engineering.uiowa.edu> College of Engineering 319/335-5751 FAX: 319/384-0549 1256 Seamans Center, 103 S Capitol St. Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527 #include <std_disclaimer.h> Better is not better, 'standard' is better. B{
participants (3)
-
Alan DeKok -
David B Funk -
Nicolas Godbert