CA Chain

[Jeffrey Sewell]

Thank you for your reply.

We are (with the exception of some prototype tests) going to be
completely EAP-TLS.

Your answer brings me back to my original issue--the CA_path does not
exist in the eap.conf file. If I add it, it doesn't seem to work (on
1.1.4).

Just adding additional certs to the CA_file seems to work, but I'd
prefer to have proper signed (c_reshash) sym-links.

That's a useful CRL script, thanks for the link.

>
> CA_path = ${raddbdir}/certs/trustedCAs/
>
> with c_rehash generated fingerprint symlinks for a directory of trusted CA
> certificates for EAP-TLS (with client authentication by client certificates).
>
> Or
>
> CA_file = ${raddbdir}/certs/trustedCAs.pem
>
> a file with possibly multiple PEM formatted CA certificates for EAP-TLS
> (with client authentication by client certificates).
>
> My point was that the chain of the radius-server-certificate is actually to
> be *added* to the file with the radius-server-certificate itself.
>
> And that if you want to do plain EAP- *T* TLS and only EAP-TTLS to be
> carefull to leave CA_file and CA_path nulled/empty.
>
> I remember that the inline documentation of the eap.conf file suggests to
> put the CA certificate issuing the radius-servers server-certificate into
> the CA_file which could open up unwanted EAP-TLS client authentication by
> client certificates if this CA issued client certificates.
>
> If you configure radiusd to do EAP-TLS also make sure to use the check_crl =
> yes option and have up-to-date CRLs available in the CA_path. Make sure
> c_rehash is building the fingerprint symlinks here as well.
>
> To automatically freshen/download CRLs by e.g. cron there is a neat script
> with some build-in CRL checking etc available at
> http://dist.eugridpma.info/distribution/util/fetch-crl/
>
> HTH
>
> --
> Kind Regards
>