Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
up vote 2 down vote accepted

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.

share|improve this answer
So, for FreeRADIUS using the configuration/howto mentioned on the freeradius site (see and this entails changing the client.cnf file and re-generating client certificates using make client.pem for each client, correct? – Sonny Jul 24 '12 at 11:45
@Sonny And configuring eap.conf with your root CA; otherwise yes. – mgorven Jul 24 '12 at 16:28
So, in eap.conf, turning on check_cert_cn = %{User-Name} for each username used for generating the client.p12s? What is this username (is it different from the commonName in client.cnf)? Is it the same as the Username used in users? Do we have to include the username/password (I see and it appears like it could be the distinguishedName from client.cnf). Could you point me to some documentation for this part of the config? – Sonny Jul 24 '12 at 16:56
@Sonny I've expanded my answer. I don't have any documentation for this other than the config file, so I'm mostly guessing here ;-) – mgorven Jul 24 '12 at 18:41
I added my solution at‌​t-less-setup-on-a-mixed-network-xp-sp3?lq=1. – Sonny Jul 26 '12 at 1:33

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.