Intermediate-Trust certificate issues

[Alan DeKok]

On May 1, 2026, at 2:35 PM, Hector Rodriguez via Freeradius-Users <freeradius-users at lists.freeradius.org> wrote:
>  I hope everyone is well. Currently I have implemented Free Radius in a test environment with EAP-TLS mode enabled.

  Which version?

> My environment currently has a two tier PKI (CA Root and Ca Issuer within the Intune Microsoft Cloud PKI environment) . Our Free Radius server is configured to have an SSL from the CA server installed within my Free Radius Server, which is generated by the CA config. Our Root CA and Issuer CA certificates have been imported from Intune, and converted from Cer to PEM/CRT file formats, and the EAP config file has been edited to point to a bundled (full chain ) Issuer CA cert. The server's certificate store has been updated to trust the Microsoft CA and Issuer CA for our environment . I have created a configuration profile within Intune to grant machines (in my case, just a test machine) to install both CA ROOT and Issuer certs to their prespective certificate store.  Public certs are owned by the freerad user and currently have the 755 permissions

  OK.  There's always some magic fighting with certificates, but that sounds reasonable.

>   Another thing to note is that we are currently using a Unifi switch and we have set the controller profile to authenticate with Radius. I have been going a bit insane trying to figure out why the Free Radius server is not trusting my intermediate certificate when I have clearly followed the appropriate instructions. No matter what I do the intermediate cert is not trusted. Authentication only occurs when I set:reject_unknown_intermediate_ca  to No. I have been notciing that other users have a similar issue, with PKI's related to Microsoft Cloud PKI. Do you thing there will be a fix. Is there anything that I can do for this issue ? Although it seems unsafe, do you think it would be Ok, to  set reject_unknown_intermediate_ca =no  ?

  IIRC there were issues with intermediate certs at one point.  The fix is likely in commit aca3a5955d4e

  i.e. it will be in 3.2.9, which we expect to release shortly.

  Alan DeKok.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20260501/043705fb/attachment-0001.sig>