Than you. So if I understand this correctly, radiusd is not looking for a directory with checksum'd certificates, just one file with all the certficates in it? Our implementation is still in the design phase and is not using LDAP but we will be testing LDAP at a later date so I will keep your advice in mind. JS On 1/22/07, Reimer Karlsen-Masur, DFN-CERT <karlsen-masur@dfn-cert.de> wrote:

Jeffrey Sewell wrote:

...

In the eap.conf, tls section, the comments say to use the 'CA_path' variable in the radiusd.conf file to indicate where the trusted CA chain will reside. However, this variable isn't in the tls section of the radiusd.conf file (it is in the LDAP section, but I'm pretty sure that won't help me) or the eap.conf file (where I thought it might have moved). As an experiment, I added it to eap.conf and it loaded ok with the following output:

tls: CA_path = "/usr/local/etc/raddb/certs/rootCA" ... tls: CA_file = "(null)"

Unfortunately the CA_file is the imporant one as I discovered when I tested the link:

Fri Jan 19 09:51:05 2007 : Error: TLS Alert write:fatal:unknown CA

So where is the appropriate place for the root chain?

for eap-tls and eap-ttls in eap.conf in the eap section and thereof in the tls section put the server certificate of your radius server into the file

eap { ... tls { ... private_key_file = ${raddbdir}/certs/radius-server-key.pem certificate_file = ${raddbdir}/certs/radius-server-cert-and-chain.pem ... } ... } and then *add* the appropriate chain ca certificates to this file.

Additionally if you do *not* use eap-tls you want CA_path= point to an existing *empty* directory and you do *not* want to specify the CA_file option.

eap { ... tls { ... # CA_file = /dev/null CA_path = ${raddbdir}/certs/trustedCAs-emptydir/ verify_depth = 1 ... } ... }

If you were looking to use the radius server as *LDAP client* to a backend LDAP database above options are not relevant for the LDAP client part. In this case you need to fiddle with the options in radiusd.conf under modules and thereof under the ldap section:

modules { ... ldap { ... # start_tls = no # tls_cacertfile = ${raddbdir}/certs/trusted-root-CA-certs-for-ldap-server.pem # tls_cacertdir = ${raddbdir}/certs/trusted-root-CA-certs-dir-for-ldap-server/ # tls_keyfile = ${raddbdir}/certs/radius-ldap-client-key.pem # tls_certfile = ${raddbdir}/certs/radius-ldap-client-cert-and-chain.pem # tls_randfile = ${raddbdir}/certs/rnd # tls_require_cert = "demand" ... } ... }

HTH

-- Beste Gruesse / Kind Regards

Reimer Karlsen-Masur -- Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), DFN-CERT Services GmbH DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737

14. DFN-CERT Workshop und Tutorien, CCH Hamburg, 7.-8. Februar 2007 Infos/Anmeldung unter: https://www.dfn-cert.de/events/ws/2007/

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

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