[RADIATOR] Trust client certificates of a specific issuing CA

[Hartmaier Alexander]

We had to add each CA cert to the EAPTLS_CAPath with both the old and
the new hash and limit the authentication using
EAPTLS_CertificateVerifyHook as Heikki suggested.

To find out the two hashes use 'openssl x509 -in CA.pem  -noout
-issuer_hash_old' and -issuer_hash and create symlinks named $hash.0 and
$oldhash.0 in the EAPTLS_CAPath directory to the CA.pem file.

This also allows to check the subject for specific OU's etc.

Best regards, Alex


On 2017-04-20 09: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.
>
> What comes to Radiator, the configuration parameters affect what is
> passed to Net::SSLeay which then talks directly to
> OpenSSL/LibreSSL/etc. This means the TLS library manual could also be
> helpful to see what and how to configure. There's also the question of
> different library versions having different behaviour.
>
> In short: you could test and see if it works.
>
> 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.
>
>> 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.
>
>> 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.
>
> Please let the list know how it goes!
>
> Thanks,
> Heikki
>



*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*