Hello,
I'm currently setting up our radsecproxy for the use with Eduroam. The TLS connection seems to be not possible though.
When I try to start the daemon, I get the following error in the log file:
sslreadtimeout: SSL: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca
My certificate is definetly valid and I've configured the right certificate chain.
When I try to connect to the federation radius server (by DFN here in Germany) manually with openssl s_client it works, but only using tls 1.0,tls 1.1 and tls 1.2. It does not work with TLS 1.3.
Any idea why this is happening? So the real problem is: It works with all other TLS versions, but not 1.3. Is there a way to force OpenSSL lib to use only 1.2 somehow?
Thank you in advance to you all.
Marc Sauer
I was also . wondering how we tell radsecproxy to only use TLS 1.2
A
On Wed, 27 Nov 2019 at 13:59, Marc Sauer m.sauer@khm.de wrote:
Hello,
I'm currently setting up our radsecproxy for the use with Eduroam. The TLS connection seems to be not possible though.
When I try to start the daemon, I get the following error in the log file:
sslreadtimeout: SSL: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca
My certificate is definetly valid and I've configured the right certificate chain.
When I try to connect to the federation radius server (by DFN here in Germany) manually with openssl s_client it works, but only using tls 1.0,tls 1.1 and tls 1.2. It does not work with TLS 1.3.
Any idea why this is happening? So the real problem is: It works with all other TLS versions, but not 1.3. Is there a way to force OpenSSL lib to use only 1.2 somehow?
Thank you in advance to you all.
Marc Sauer
-- Marc Sauer Linux Systems Administrator
Kunsthochschule für Medien Köln/ Academy of Media Arts Cologne Peter-Welter-Platz 2 50676 Köln
https://www.khm.de https://en.khm.de
radsecproxy mailing list radsecproxy@lists.nordu.net https://lists.nordu.net/listinfo/radsecproxy
Hi Marc and Alex,
On 27.11.19, 15:09, "radsecproxy on behalf of Alex Sharaz" <radsecproxy-bounces@lists.nordu.net on behalf of alex.sharaz@york.ac.uk> wrote: I was also . wondering how we tell radsecproxy to only use TLS 1.2
There is no 'way to tell it'; but there should be no need to. Radsecproxy uses whatever settings your ssl library defaults to. I've just checked a recently set up server (FreeRadius 3.0.19 on Fedora 28, openssl 1.1.0i) talking to a radsecrpxoy (1.8.1 on RHEL 7.7, openssl 1.0.2k) using radsec (radsecproxy is the originator/client). It is using TLSv1.2 (confirmed by wireshark).
At least with openssl 1.1.0, you can configure these defaults in openssl.cnf (https://www.openssl.org/docs/man1.1.0/man5/config.html). Not sure about openssl 1.0.2; it's not mentioned in the manpage of that version.
On 27.11.19, 15:00, "radsecproxy on behalf of Marc Sauer" <radsecproxy-bounces@lists.nordu.net on behalf of m.sauer@khm.de> wrote: When I try to start the daemon, I get the following error in the log file:
sslreadtimeout: SSL: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca
My certificate is definetly valid and I've configured the right certificate chain.
When I try to connect to the federation radius server (by DFN here in Germany) manually with openssl s_client it works, but only using tls 1.0,tls 1.1 and tls 1.2. It does not work with TLS 1.3.
Not sure if DFN federation servers already support TLS 1.3. This requires the latest openssl 1.1.1. But openssl should select the highest compatible version automatically. If openssl can't verify the ca, its most likely due to missing intermediates (you have to include those in the same .pem), or using CAcertificatePath but forgetting to hash (eg using c_rehash) the Cas.
Any idea why this is happening? So the real problem is: It works with all other TLS versions, but not 1.3. Is there a way to force OpenSSL lib to use only 1.2 somehow?
This is not a TLS version issue. If it was, the error message would state it (either incompatible version or incompatible cipher suites).
Best regards, Fabian
-- SWITCH Fabian Mauchle, Network Engineer Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland Phone +41 44 268 15 30, direct +41 44 268 15 39 fabian.mauchle@switch.ch, http://www.switch.ch
Freeeadius 3.0.20 lets you specify min and max versions of TLD to use with lots of comments saying you should disable using 1.0 & 1.1, just wandered if we could have the same functionality, but if it’s configursbkrbin OpenSSL that’ll do
Sent from my iPhone
On 27 Nov 2019, at 17:30, Fabian Mauchle fabian.mauchle@switch.ch wrote:
Hi Marc and Alex,
On 27.11.19, 15:09, "radsecproxy on behalf of Alex Sharaz" <radsecproxy-bounces@lists.nordu.net on behalf of alex.sharaz@york.ac.uk> wrote: I was also . wondering how we tell radsecproxy to only use TLS 1.2
There is no 'way to tell it'; but there should be no need to. Radsecproxy uses whatever settings your ssl library defaults to. I've just checked a recently set up server (FreeRadius 3.0.19 on Fedora 28, openssl 1.1.0i) talking to a radsecrpxoy (1.8.1 on RHEL 7.7, openssl 1.0.2k) using radsec (radsecproxy is the originator/client). It is using TLSv1.2 (confirmed by wireshark).
At least with openssl 1.1.0, you can configure these defaults in openssl.cnf (https://www.openssl.org/docs/man1.1.0/man5/config.html). Not sure about openssl 1.0.2; it's not mentioned in the manpage of that version.
On 27.11.19, 15:00, "radsecproxy on behalf of Marc Sauer" <radsecproxy-bounces@lists.nordu.net on behalf of m.sauer@khm.de> wrote: When I try to start the daemon, I get the following error in the log file:
sslreadtimeout: SSL: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca
My certificate is definetly valid and I've configured the right certificate chain.
When I try to connect to the federation radius server (by DFN here in Germany) manually with openssl s_client it works, but only using tls 1.0,tls 1.1 and tls 1.2. It does not work with TLS 1.3.
Not sure if DFN federation servers already support TLS 1.3. This requires the latest openssl 1.1.1. But openssl should select the highest compatible version automatically. If openssl can't verify the ca, its most likely due to missing intermediates (you have to include those in the same .pem), or using CAcertificatePath but forgetting to hash (eg using c_rehash) the Cas.
Any idea why this is happening? So the real problem is: It works with all other TLS versions, but not 1.3. Is there a way to force OpenSSL lib to use only 1.2 somehow?
This is not a TLS version issue. If it was, the error message would state it (either incompatible version or incompatible cipher suites).
Best regards, Fabian
-- SWITCH Fabian Mauchle, Network Engineer Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland Phone +41 44 268 15 30, direct +41 44 268 15 39 fabian.mauchle@switch.ch, http://www.switch.ch
Hi Fabian,
Am 27.11.2019 um 18:30 schrieb Fabian Mauchle:
This is not a TLS version issue. If it was, the error message would state it (either incompatible version or incompatible cipher suites).
Thank you for your quick and complex answer. I'll have a look into my certificate chain then.
Cheers,
Marc
Hi,
Am 27.11.19 um 18:30 schrieb Fabian Mauchle:
Not sure if DFN federation servers already support TLS 1.3. This requires the latest openssl 1.1.1.
yes, they do. Citing eduoram@dfn.de's annoncement from Nov 12:
ab sofort steht Ihnen auf beiden eduroam Föderationsservern des DFN das Protokoll TLSv1.3 zur Verfügung.
Testweise hatte ich TLSv1.3 bereits auf tld2.eduroam.de am Start.
Wen es interessiert Unterschiede zu TLSv1.2 entnehmen Sie bitte https://tools.ietf.org/html/rfc8446#page-8 z.B. “...Static RSA and Diffie-Hellman cipher suites are removed …” , “...Elliptic curve algorithms are now in the base spec, and new signature algorithms, such as EdDSA, are included …”
Sollten nun dennoch Probleme beim Verbindungsaufbau zu den RadSec Client/Server des DFN auftreten, die mir entgangen sind, kommen Sie bitte auf mich zu.
TLSv1.2 Verbindungen werden weiterhin unterstützt.
openssl s_client -connect tld2.eduroam.de:2083 -tls1_2 -showcerts oder openssl s_client -connect tld2.eduroam.de:2083 -tls1_3 -showcerts
-showcerts gibt die komplette Zertifikatskette aus.
For those who don't know German: TLS 1.2 still works, support is available in case of problems.
Regards, Martin
Having a senior moment, how do you specify tls 1.2 in openssl.cfg ?
Rgds Alex
On Thu, 28 Nov 2019 at 10:41, Martin Pauly pauly@hrz.uni-marburg.de wrote:
Hi,
Am 27.11.19 um 18:30 schrieb Fabian Mauchle:
Not sure if DFN federation servers already support TLS 1.3. This
requires the latest openssl 1.1.1.
yes, they do. Citing eduoram@dfn.de's annoncement from Nov 12:
ab sofort steht Ihnen auf beiden eduroam Föderationsservern des DFN das
Protokoll TLSv1.3 zur Verfügung.
Testweise hatte ich TLSv1.3 bereits auf tld2.eduroam.de am Start.
Wen es interessiert Unterschiede zu TLSv1.2 entnehmen Sie bitte
https://tools.ietf.org/html/rfc8446#page-8
z.B. “...Static RSA and Diffie-Hellman cipher suites are removed …” ,
“...Elliptic curve algorithms are now in the base spec, and new
signature algorithms, such as EdDSA, are included …”Sollten nun dennoch Probleme beim Verbindungsaufbau zu den RadSec
Client/Server des DFN auftreten, die mir entgangen sind, kommen Sie bitte auf mich zu.
TLSv1.2 Verbindungen werden weiterhin unterstützt.
openssl s_client -connect tld2.eduroam.de:2083 -tls1_2 -showcerts oder openssl s_client -connect tld2.eduroam.de:2083 -tls1_3 -showcerts
-showcerts gibt die komplette Zertifikatskette aus.
For those who don't know German: TLS 1.2 still works, support is available in case of problems.
Regards, Martin
-- Dr. Martin Pauly Phone: +49-6421-28-23527 HRZ Univ. Marburg Fax: +49-6421-28-26994 Hans-Meerwein-Str. E-Mail: pauly@HRZ.Uni-Marburg.DE D-35032 Marburg
radsecproxy mailing list radsecproxy@lists.nordu.net https://lists.nordu.net/listinfo/radsecproxy
On 28.11.19, 13:00, "radsecproxy on behalf of Alex Sharaz" <radsecproxy-bounces@lists.nordu.net on behalf of alex.sharaz@york.ac.uk> wrote:
Having a senior moment, how do you specify tls 1.2 in openssl.cfg ?
Without having tested it, my latest Debian stable (buster) has in /etc/ssl/openssl.cnf:
[system_default_sect] MinProtocol = TLSv1.2
According to the openssl source code, there is also a 'MaxProtocol' option.
BR, Fabian
-- SWITCH Fabian Mauchle, Network Engineer Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland Phone +41 44 268 15 30, direct +41 44 268 15 39 fabian.mauchle@switch.ch, http://www.switch.ch
Cool! many thanks
On Thu, 28 Nov 2019 at 12:23, Fabian Mauchle fabian.mauchle@switch.ch wrote:
On 28.11.19, 13:00, "radsecproxy on behalf of Alex Sharaz" < radsecproxy-bounces@lists.nordu.net on behalf of alex.sharaz@york.ac.uk> wrote:
Having a senior moment, how do you specify tls 1.2 in openssl.cfg ?Without having tested it, my latest Debian stable (buster) has in /etc/ssl/openssl.cnf:
[system_default_sect] MinProtocol = TLSv1.2
According to the openssl source code, there is also a 'MaxProtocol' option.
BR, Fabian
-- SWITCH Fabian Mauchle, Network Engineer Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland Phone +41 44 268 15 30, direct +41 44 268 15 39 fabian.mauchle@switch.ch, http://www.switch.ch
just to confirm Ubuntu 16.04 - openssl 1.1.1 yes I can restrict TLS to 1.2
Rgds alex
On Thu, 28 Nov 2019 at 13:03, Alex Sharaz alex.sharaz@york.ac.uk wrote:
Cool! many thanks
On Thu, 28 Nov 2019 at 12:23, Fabian Mauchle fabian.mauchle@switch.ch wrote:
On 28.11.19, 13:00, "radsecproxy on behalf of Alex Sharaz" < radsecproxy-bounces@lists.nordu.net on behalf of alex.sharaz@york.ac.uk> wrote:
Having a senior moment, how do you specify tls 1.2 in openssl.cfg ?Without having tested it, my latest Debian stable (buster) has in /etc/ssl/openssl.cnf:
[system_default_sect] MinProtocol = TLSv1.2
According to the openssl source code, there is also a 'MaxProtocol' option.
BR, Fabian
-- SWITCH Fabian Mauchle, Network Engineer Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland Phone +41 44 268 15 30, direct +41 44 268 15 39 fabian.mauchle@switch.ch, http://www.switch.ch
-
Alex Sharaz -
Fabian Mauchle -
Marc Sauer -
Martin Pauly