[RADIATOR] Trust client certificates of a specific issuing CA

[Philip Brusten]

On 20/04/2017 9:44, Heikki Vatiainen wrote:
> On 19.4.2017 17.17, Philip Brusten wrote:
>
>> Assume you have a PKI like:
>>
>> root CA
>>    - intermediate CA 1
>>       - issuing CA 1
>>    - intermediate CA 2
>>       - issuing CA 2
>>
>> If you only want to trust endpoint certificates for EAP-TLS issued by 
>> "issuing CA 2", would it be sufficient to *only* trust "issuing CA 2" 
>> in EAPTLS_CAFile?
>
> Possibly yes. I think that in X.509 the trusted CAs, or trust anchors 
> as they are called, do not need to have subject and issuer that is 
> equal. This is what the current practice is with root CA certificates 
> (you need to put something in issuer so own name is used).
>
> In other words, you could try using any CA certificate as a trust 
> anchor by configuring it as trusted. What is unsure, the "possibly" 
> part, refers to the question if the software can be configured to do so.
Unfortunataly not.
Radiator returns: EAP TLS certificate verification failed: unable to get 
local issuer certificate,  29215: 1 - error:140890B2:SSL 
routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned

OpenSSL added a new feature in 1.0.2 to accept a partial chain.

It can be set using this flag X509_V_FLAG_PARTIAL_CHAIN which you could 
set using the Net::SSLeay::X509_STORE_set_flags

Perhaps you could make a EAPTLS-setting for this flag in Radiator?

>
> In addition to this, you could consider EAPTLS_CertificateVerifyHook 
> to see that the client certifcate's issuer is "issuing CA 2". This 
> could provide a good belt + suspenders configuration even if trusting 
> "issuing CA 2" would work by itself.
>
For now we will have to perform an extra check via the hook to validate 
the issuer of the client certificates.
>> Or is it required to trust the entire chain: "root CA" + 
>> "intermediate CA 2" + "issuing CA 2"?
>> If you do the latter and a supplicant device has a certificate issued 
>> by "issuing CA 1" and sends its entire certificate chain up to the 
>> root CA during the handshake, will it be validated as well?
>
> I'd say there's potential for this to happen. In this case you could 
> use the hook I mentioned above to see that everything else except of 
> certificates issued by "issuing CA 2" get grounded and rejected.
It does get validated if the client sends its chain up to the trusted 
root CA.
>
>> The documentation 
>> https://www.open.com.au/radiator/ref/EAPTLS_CAFile.html#EAPTLS_CAFile 
>> is not entirely clear on that.
> I think we'd need to say that TLS library manual would be the 
> canonical source of information for these options.
The sentence "So, EAPTLS_CAFile must contain all the CA root and 
intermediate certificates required to validate all the various client 
certificates that may be installed on your supplicant devices." is not 
entirely true. If you do not trust the intermediate certificates, but 
the client sends them along during the handshake, the trust can still be 
established. I agree that it is a best practice to add them, but it is 
not required. Otherwise you could falsely conclude that there is no 
trust when the entire chain is *not* present.

Regards,
Philip