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.