[RADIATOR] Trust client certificates of a specific issuing CA

[Heikki Vatiainen]

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

-- 
Heikki Vatiainen <hvn at open.com.au>

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, 
NetWare etc.