RADSEC - ERROR: TLS Alert read:fatal:unknown CA

[Alan DeKok]

On Apr 26, 2021, at 7:12 AM, Michael Cullen <michael.cullen at 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.