RADSEC - ERROR: TLS Alert read:fatal:unknown CA
Hi, I'm getting an unknown CA error when authenticating with RADSEC. I have EAP-TLS and EAP-TLS over TTLS working fine. This is passing locally when running eapol_test, pointing this at the running server fails with the following: Listening on auth+acct from client (10.0.2.232, 52947) -> (*, 2083, virtual-server=radsec) (0) Initiating new TLS session (0) Setting verify mode to require certificate from client (0) (other): before SSL initialization (0) TLS_accept: before SSL initialization (0) TLS_accept: before SSL initialization (0) <<< recv TLS 1.3 [length 0098] (0) TLS_accept: SSLv3/TLS read client hello (0) >>> send TLS 1.2 [length 0039] (0) TLS_accept: SSLv3/TLS write server hello (0) >>> send TLS 1.2 [length 03c6] (0) TLS_accept: SSLv3/TLS write certificate (0) >>> send TLS 1.2 [length 016d] (0) TLS_accept: SSLv3/TLS write key exchange (0) >>> send TLS 1.2 [length 00aa] (0) TLS_accept: SSLv3/TLS write certificate request (0) >>> send TLS 1.2 [length 0004] (0) TLS_accept: SSLv3/TLS write server done (0) TLS_accept: Need to read more data: SSLv3/TLS write server done (0) TLS - In Handshake Phase (0) TLS - got 1587 bytes of data (0) <<< recv TLS 1.2 [length 0002] (0) ERROR: TLS Alert read:fatal:unknown CA (0) TLS_accept: Need to read more data: error (0) ERROR: Failed in __FUNCTION__ (SSL_read): error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca (0) TLS - In Handshake Phase (0) TLS - Application data. (0) SSL_read Error (0) ERROR: Error in fragmentation logic (0) Application data status 4 Closing TLS socket from client port 52947 Client has closed connection ... shutting down socket auth+acct from client (10.0.2.232, 52947) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 11766) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 15359) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 65212) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 6123) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 59685) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 17646) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 48212) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 53313) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 36056) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 40139) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 48337) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 42353) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 22426) -> (*, 2083, virtual-server=radsec) .. . cleaning up socket auth+acct from client (10.0.2.232, 51317) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 19967) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 32633) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 39479) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 3427) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 11898) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 15455) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 26702) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 28398) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 7519) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 16029) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 24805) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 30665) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 37105) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 17261) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 23705) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 30053) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 24811) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 41416) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 25290) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 17735) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 21421) -> (*, 2083, virtual-server=radsec) Waking up in 0.8 seconds. ... cleaning up socket auth+acct from client (10.0.2.232, 15262) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 23391) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 28075) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 19519) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 8746) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 29993) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 60922) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 2533) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 50237) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 52840) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 62747) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 60782) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 17977) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 26652) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 57896) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 22108) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 6062) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 13844) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 43369) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 51246) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 54429) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 64595) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 2748) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 47575) -> (*, 2083, virtual-server=radsec) ... cleaning up socket auth+acct from client (10.0.2.232, 52947) -> (*, 2083, virtual-server=radsec) Ready to process requests The radsec configuration is: server radsec { listen { type = auth+acct ipaddr = * port = 2083 proto = tcp tls { private_key_password = whatever private_key_file = ${certdir}/server.pem certificate_file = ${certdir}/server.pem ca_file = ${certdir}/ca.pem dh_file = ${raddbdir}/dh random_file = /dev/random check_crl = no ca_path = ${cadir} cipher_list = "HIGH" ecdh_curve = "secp384r1" require_client_cert = yes auto_chain = no cache { enable = no lifetime = 24 max_entries = 255 } verify { tmpdir = /tmp/radiusd client = "/usr/bin/openssl verify -CAfile ${certdir}/ca.pem %{TLS-Client-Cert-Filename}" } } } authorize { eap } authenticate { eap } } In an attempt to fix this, I followed this guide (we are running on Alpine): https://wiki.alpinelinux.org/wiki/FreeRadius_EAP-TLS_configuration I'm interested to know whether this is really a unknown CA error or if something else is going on. Some things I'm investigating: 1. Why is the first recv TLS 1.3 and all consecutive send and recv TLS 1.2? (0) <<< recv TLS 1.3 [length 0098] (0) TLS_accept: SSLv3/TLS read client hello (0) >>> send TLS 1.2 [length 0039] (0) TLS_accept: SSLv3/TLS write server hello 2. I can see "TLS - got 1587 bytes of data", will this result in fragmentation in the handshake? (0) ERROR: Error in fragmentation logic 3. Could there be a problem with the identity being sent to the server? I'm seeing a lot of identity request and response, and we seem to be stuck in a loop. I'm using the certificate Common Name as the identity value. 57 12.824635 HewlettP_f7:de:e0 Apple_26:33:dc EAP 23 Request, Identity 551 30.363992 HewlettP_f7:de:f0 Apple_26:33:dc EAP 23 Request, Identity 553 30.400277 HewlettP_f7:de:f0 Apple_26:33:dc EAP 23 Request, Identity 558 30.433393 HewlettP_f7:de:f0 Apple_26:33:dc EAP 23 Request, Identity 560 30.466359 HewlettP_f7:de:f0 Apple_26:33:dc EAP 23 Request, Identity 562 30.499880 HewlettP_f7:de:f0 Apple_26:33:dc EAP 23 Request, Identity 564 30.531438 HewlettP_f7:de:f0 Apple_26:33:dc EAP 23 Request, Identity Kind Regards, Michael
On Apr 26, 2021, at 7:12 AM, Michael Cullen <michael.cullen@madetech.com> wrote:
I'm getting an unknown CA error when authenticating with RADSEC. I have EAP-TLS and EAP-TLS over TTLS working fine. This is passing locally when running eapol_test, pointing this at the running server fails with the following:
Listening on auth+acct from client (10.0.2.232, 52947) -> (*, 2083, virtual-server=radsec) (0) Initiating new TLS session (0) Setting verify mode to require certificate from client (0) (other): before SSL initialization (0) TLS_accept: before SSL initialization
The TLS debugging in the v3.0.x branch is a _lot_ better...
(0) <<< recv TLS 1.2 [length 0002] (0) ERROR: TLS Alert read:fatal:unknown CA
That's opaque, but meaningful. This is a TLS alert sent by the other end. It's telling you that it doesn't know about the CA which FreeRADIUS is using. You MUST use a CA which is known to both sides. This usually means configuring the other end of the CA used to create the FreeRADIUS certs. So the next question is, where did you get the certificates? If you used the fake certs in raddb/certs, then that would explain why the other end doesn't know anything about them.
In an attempt to fix this, I followed this guide (we are running on Alpine): https://wiki.alpinelinux.org/wiki/FreeRadius_EAP-TLS_configuration I'm interested to know whether this is really a unknown CA error or if something else is going on.
It really is an unknown CA error.
Some things I'm investigating:
1. Why is the first recv TLS 1.3 and all consecutive send and recv TLS 1.2?
TLS does negotiation. It's fine.
2. I can see "TLS - got 1587 bytes of data", will this result in fragmentation in the handshake? (0) ERROR: Error in fragmentation logic
Maybe use the code in v3.0.x, which creates messages which are a lot more understandable.
3. Could there be a problem with the identity being sent to the server? I'm seeing a lot of identity request and response, and we seem to be stuck in a loop.
EAP identity response has absolutely nothing to do with Radsec. Akan DeKok.
participants (2)
-
Alan DeKok -
Michael Cullen