How many user/supplicant certificates are needed for WPA2 enterprise on a small network?

I am running WPA2 enterprise for wireless access and I followed the instructions in /etc/raddb/certs/README and the freeRadius site howto. I also read the instructions in the privacywonk site.

The question is, the FreeRadius instructions and the site seems to suggest using only one (self-signed) certificate for all the supplicants, whereas the privacywonk website suggests the use of separate certificates for each supplicant.

Is there an advantage of one vs. the other?

One advantage I can think of is to be able to revoke a specific user account (which you can do when you have several certificates, one for each supplicant). Any others?

Also, how do you tie the specially created certificate to the specific user in the users file?

Solution 1:

Sharing certificates is basically the same as sharing passwords. If the one certificate is compromised, you have to go and reconfigure all the clients in order to change the certificate, whereas if you have a certificate per client you can simply revoke the compromised certificate. Also, the shared certificate may mean that clients can decrypt traffic sent to and from other clients, whereas separate certificates means that clients can only decrypt their own traffic. If you're going to the effort of setting up WPA2 with certificates I suggest you do it properly and generate certificates for each client.

I'm assuming that you're using EAP-TLS here, in which case you don't specifically configure users in the users file. The fact that a client has a certificate and key signed by the CA (i.e. the CA_file parameter) and is not in the CRL means that it has access.

With EAP-TLS the user provides a username, certificate and private key (possibly protected with a password). Note that there is no password with which the username can be authenticated with (i.e. users can enter any username they want). If you want to use the username to make policy decisions you need to validate that the username which the user provided is correct. I think that this is done by setting the username you want to use as the Common Name in the certificate when it is generated, and enabling the check_cert_cn parameter. This will cause the server to reject the request if the Common Name in the certificate provided by the user does not match the username they provided. You can then add entries to the users file matching User-Name to define your policy.