Hello, I have a set of FR 2.2.5 servers which are currently handling PEAP connections. We now want to add EAP-TLS authentication, which is pretty straightforward. The only stumbling block I have is that the EAP-TLS client certs are signed by a root CA different from the one that signed the server certificate currently used for PEAP authentication. While that is not a problem in itself it makes client devices configuration more troublesome than I would like because it forces the user to install two root CA certs. So I am trying to write a configuration that would support two eap configurations. Instantiating two modules is not the problem, it’s more a matter of finding how to select a configuration to be used while maintaining backwards compatibility for the existing PEAP clients. Assuming the following modules: eap { […] tls { certdir = ${confdir}/certs cadir = ${confdir}/certs private_key_file =${certdir}/server.key certificate_file = ${certdir}/server.crt CA_file = ${certdir}/ca_PEAP.crt dh_file = ${certdir}/dh random_file = /dev/urandom cipher_list = "DEFAULT" make_cert_command = "${certdir}/bootstrap” […] } eap eap-tls { [..] tls { certdir = ${confdir}/certs cadir = ${confdir}/certs private_key_file = ${certdir}/ca.key private_key_password = whatever certificate_file = ${certdir}/ca.pem dh_file = ${certdir}/dh random_file = /dev/urandom cipher_list = "DEFAULT" make_cert_command = "${certdir}/bootstrap" CA_file = ${certdir}/ca.pem […] } This does not seem to work: authorize { # assuming an instance called eap-tls eap-tls { updated = return } # else eap { ok = return } […] } And since things like EAP-Type are detected by the eap module itself I also can’t seem to do if (EAP-Type && (EAP-Type == EAP-TLS)) { eap-tls { ok = return } } else { eap { ok = return } } Which leaves me with a chicken and egg type of situation. Is this doable in FR 2? Am I just missing the obvious? Thank you for your help. -- Louis Munro lmunro@inverse.ca :: www.inverse.ca +1.514.447.4918 x125 :: +1 (866) 353-6153 x125 Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org)