Multiple CAs

Jonathan Gazeley jonathan.gazeley at
Wed Oct 4 15:23:19 CEST 2017

On 04/10/17 13:15, Alan DeKok wrote:
> On Oct 4, 2017, at 6:16 AM, Jonathan Gazeley <Jonathan.Gazeley at> wrote:
>> We (the network infrastructure sysadmins) have been put in a situation where there are EAP-TLS clients on the network with certs issued by two different CAs. From talking to management, this is unavoidable and we must accommodate this with our RADIUS servers. (It's something to do with the way Azure AD does provisioning).
>    i.e. they screwed up and don't want to admit it.
>    There's just no reason for one AD server to have two different CAs.
It's two different AD solutions - the traditional on-premises AD and a 
new cloud-hosted Azure AD. I don't see why they can't have the same CA, 
but the people responsible for this new hybrid solution disagree. User 
systems are split between the two ADs.
>> My understanding is that a decision about which EAP module to use must be made in the outer server based on attributes in the RADIUS packet and then the correct EAP module can be used for that CA.
>    Yes.
>> Am I correct in thinking it is not possible to do something like:
>> authorize {
>>    eap_module_1
>>    eap_module_2
>> }
>> and expect that FreeRADIUS tries each EAP module in turn until it finds one with the right CA?
>    That's not how those protocols work.
>> Also that it is not possible to check SSL cert attributes in the outer server to determine the correct CA?
>    By the time the server gets that data, it's already chosen one CA, and can't swap mid-stream.
>    If the outer identity is anonymous with no realm, you have no data with which to select an EAP module.
Alas, all these systems have the same anonymous outer realm in the outer 
identity and from what I can see, no other distinguishing attributes 
that I could use to filter on. I will ask about getting the clients on 
Azure AD set to use a different realm.
>    if there outer realm has a real name or realm, you can use that to select the EAP module.
>    *Or* if all of the end user systems have *both* CAs provisioned and enabled, then the situation is simple: just use one EAP module, and put both CAs into "ca_file".

Sadly not. There are two types of end user system out in the wild and 
they have either one CA or the other. They are managed differently but 
they all use the same realm.

Thanks for confirming my beliefs. I'll go back to management and tell 
them the author of the RFCs says their design won't work.


More information about the Freeradius-Users mailing list