EAP-TLS with CRLs broken on RHEL 8.8

Alan DeKok aland at deployingradius.com
Mon Nov 13 21:50:28 UTC 2023

On Nov 13, 2023, at 4:14 PM, Fraser Hess via Freeradius-Users <freeradius-users at lists.freeradius.org> wrote:
> We have a working FreeRADIUS implementation. It is configured for EAP-TLS.
> Our production systems use stock rpms for FreeRADIUS and OpenSSL on CentOS
> 7.9. Current RPMs: freeradius-3.0.13-15.el7.x86_64 and
> openssl-1.0.2k-26.el7_9.x86_64
> We are moving to Red Hat Enterprise Linux 8.8. We built a test system from
> scratch, installed our RADIUS config and our tests failed. The RPMs in RHEL
> 8.8 are: freeradius-3.0.20-14.module+el8.8.0+17558+3f8a93b9.x86_64 and
> openssl-1.1.1k-9.el8_7.x86_64

  A lot has changed there.  I'm happy to blame OpenSSL, not that it helps a lot.

> The failure occurs in CRL checking. With check_crl = yes and check_all_crl
> = yes, FreeRADIUS is unable to find our root CA's CRL to validate the
> intermediate CA. Setting either check_crl or check_all_crl to no resolves
> the issue.

  FreeRADIUS asks OpenSSL to do the CRL checks, and OpenSSL says "no". :(

> (8) eap_tls: TLS-Cert-Common-Name := "Organization Intermediate CA"
> (8) eap_tls: ERROR: SSL says error 3 : unable to get certificate CRL

  That error comes from OpenSSL.  That message doesn't even appear in the FreeRADIUS source code.

> (8) eap_tls: >>> send TLS 1.2 [length 0002]
> (8) eap_tls: ERROR: TLS Alert write:fatal:unknown CA

  That may be the root cause, or it may be a side effect of the CRL issue.

> Checking the leaf certificate against the intermediate CA appears to work.
> All of the certificates in /etc/raddb/certs have the correct hashed
> symlinks.

  That's good, but perhaps not enough.  The CA certificates need to be present, and in the right order.  Plus, the CRLs need to be there.

  Perhaps see this link:  https://openssl-users.openssl.narkive.com/boVv7tIp/unable-to-get-certificate-crl

  Someone on the OpenSSL list had a similar issue, and found a fix:  "By appending the CRLs to the
CA-chain, the CRL-error 3 disappears now. (The appending of CRLs to
the chain were not descriped in the manual!)"

  Other pages also say "In the case of intermediate CA, you need to provide both, the CRL of the root CA and the CRL of the intermediate CA (the full chain). You can do this by concatenating the CRLs with the certificates"

> We have tried setting tls_min_version = 1.2 and auto_chain = no, adding the
> intermediate CA certificate to the certificate_file. The same error results.
> I can break our production servers in the same manner by removing the hash
> symlink to the root CA's CRL file. In our test system, it's as if the hash
> symlink doesn't exist. The permissions on the files are correct - radiusd
> can read them all.

  It's all weird OpenSSL magic.  Badly documented, and terrible errors.

  See also the bottom of https://www.frostsnow.net/blog/2017-09-22.html

  The CRL files have to be given very specific names.
  For FreeRADIUS, the CRLs are all loaded from ca_path.  So putting the CAs and CRLs into the same directory is fine.  So if you can get OpenSSL to like the files, then FreeRADIUS should work, too.

  Alan DeKok.

More information about the Freeradius-Users mailing list