Alan Buxey wrote:

anyway, in summary, your RADIUS server has to answer to the old clients and the new clients. What is the best practice way or configuration to ensure that your RADIUS server can be both people...old servercert+old_CA and new servertcert+new_CA so that it can deal with both types of clients.

Stick your fingers in your ears and go "la la la la la". It's a big problem with certificates and PKI. The best solution is: 1) CA cert, 4K bit key, many many years of validity 2) server cert, 2K bit key, a smaller validity period 3) give the CA cert to clients, and not the server cert 4) LONG before the CA expires, hand them a new CA that is still valid. 5) when everyone has the new CA, switch to using it. 6) anyone still using the old CA is screwed. Tough.

I'm thinking 2 virtual servers....one with old eap.conf and the other with neweap.conf with each virtual server ready to deal with each type of client - but then how to direct the incoming EAP to the right way.

You can't. The SSL session setup is invisible to EAP. Even if it wasn't, the SSL session setup depends on the certs... and you can't switch certs once you've set up a session based on them. Alan DeKok.

Hi Alan, First, I don't profess to be an eap expert and what follows is based upon my understanding of how eap and RADIUS work.. I'm also interested to see if anyone else has any other thoughts..

anyway, in summary, your RADIUS server has to answer to the old clients and the new clients. What is the best practice way or configuration to ensure that your RADIUS server can be both people...old servercert+old_CA and new servertcert+new_CA so that it can deal with both types of clients.

I'm not sure if this is best practice and it certainly doesn't apply to all environments, but we control WiFi settings on our laptops using A/D group policy. This way, we can quickly push out changes and/or new certificates. Then, if the RADIUS server certificate changes, it requires that the user logon via wired network to get policy updates before they can connect to our WiFi network. As far as dual certificates, we do that, but for a different reason. I use one virtual server and some unlang to direct the request at a specific eap instance (I have 2 instances). I use one eap instance for internal WiFi networks (i.e., Corporate machines connecting to our internal network) and present an internally signed cert. I have another eap instance for guest users which presents a publicly signed cert (to avoid the cumbersome process of distributing our internal CA's cert to the guests and teaching them how to install it on their system). I determine which eap instance to call based upon the SSID to which they are connecting (which is in a request attribute). So, it is possible to accomplish this with one server. However, unless you have a way to distinguish between machines that have received the new cert and machines that haven't, I can't think of a way for you to accomplish what you want. If it's WiFi authentication, perhaps you could create a new SSID and have machines with the new cert connect to the new SSID (not difficult if you're changing which SSID is automatic and what cert. is acceptable through an automated method, e.g. A/D group policy). The problem you have is that it's not FR that is causing the rejection. Rather, the client is rejecting the RADIUS server's certificate which causes the eap tunnel creation to fail. You can't force the client to try again in this case and even if you could, how would you know that the 2nd try should go to a different eap instance (it's a new request and you can't make decisions based upon the results of historical requests that I know of).

I'm thinking 2 virtual servers....one with old eap.conf and the other with neweap.conf with each virtual server ready to deal with each type of > client - but then how to direct the incoming EAP to the right way.

One or 2 virtual servers could work. Your last question is the issue - you need a way to determine whether the client connecting has the new cert. because if you present the wrong one, the SSL connection will fail. Once the tunnel creation fails, the client would need to send a new request in order to try again.

I cant see the normal fall-through group working --because the client has to create the EAP tunnel... or would a normal fallthrough system work... we send it to eap1 and if it fails send it to eap2 (which should be okay if client config okay!) ?

I don't think so because the client is causing the tunnel creation to fail because the certificate wasn't acceptable. If this were possible, then someone could create an SSID that matches yours and keep trying various certificates until it found one you liked. The purpose of the server certificate validation is to reduce the probability that someone can spoof your infrastructure (which is why using internal certs is better because someone on the outside, in theory, couldn't digitally sign a cert. from your internal CA, but they could easily get a cert. from Verisign).

I can envisage fronting it with a.n.other RADIUS solution which will proxy the request through a remote server list UNTIL it doesnt get a REJECT back.. but i dont want additional software in the mix

I don't think this will help for the reasons I described above..