Security optimize

Ultimate wireless security guide: Self-signed certificates for your RADIUS server

Enterprise wireless LAN security is a persistent concern for every system administrator and CIO. This article, part of the TechRepublic ultimate guide to enterprise wireless LAN security, describes self-signed digital certificates, which can be implemented to avoid the use of public or private Certificate Authorities.

The complete TechRepublic Ultimate Wireless Security Guide is available as a download in PDF form.

Self-signed digital certificates is a way avoiding the use of public or private Certificate Authorities. They have long been used by developers for the purpose of testing secure Web servers and code signing but have not been used in production systems. Few people know of this method or use it for RADIUS PEAP authentication and it has been difficult to find any documentation anywhere on the Internet or books explaining how to do this.

The concept of self-signed digital certificate is similar to Pretty Good Privacy (PGP) because it doesn't use the Certificate Authority model. Although both PKI and PGP are part of the broader umbrella of PKC, digital certificates were designed to conform to the PKI trust model made up of centrally trusted CAs while PGP used a freeform peer-to-peer method of establishing trust.

For example, a PGP user would generate their own public and private key pair and then post the public key to their own public Website for all to verify. Because of this model of establishing trust, there is no need for a public or private CA which is the biggest impediment to secure authentication protocols such as SSL and PEAP.

To create a self-signed digital certificate, one would simply use a utility (shown in next section) to generate a digital certificate with a digital signature. The difference here is that instead of using an external trusted CA (analogous to a Notary) to sign the digital certificate, the utility would simply sign the certificate itself.

Once the digital certificate is generated, a pubic version of the digital certificate containing the only the public key called a "root certificate" can be exported and be made publicly accessible. The root certificate can be distributed by any means (even on a public Website) without fear of compromising the certificate since the private key is kept private. As with any PKC technology such as PGP or PKI, there is no practical method of deriving the private key from the public key. Once a self-signed digital certificate, users can securely authenticate against that RADIUS server using PEAP authentication.

Microsoft IIS 6.0 Resource Kit

As soon as I thought of using self-signed digital certificates for PEAP authentication, I began looking for a simple utility for creating self-signed digital certificates. After an extensive search, I found within the Microsoft IIS 6.0 Resource Kit an interesting command line utility called SelfSSL.exe which can create self-signed digital certificates. Although it's intended to be used for Microsoft IIS 6.0 SSL Web server testing, it works for many other applications as well including PEAP since the certificate it generates is a standard X.509 certificate. After a quick test in the lab, it became obvious that this was a good alternative to building a PKI Certificate Authority to simplify PEAP authentication. Download a copy of the Microsoft IIS 6.0 Resource kit here

When you install it, you only need to install the 332 KB SelfSSL 1.0 component of the Resource Kit. (Figure A)

Figure A

SelffSSL 1.0 Installation Wizard

The SelfSSL.exe tool should work with most RADIUS/AAA Authentication Servers and I've verified this on Microsoft IAS server. On your Authentication Server, open up a command prompt and go to the directory where you installed it (default -- C:\Program Files\IIS Resources\SelfSSL). You then type the following command.

selfssl /N:CN=ServerName.YourDomain.com /K:1024 /V:1825 /S:1 /P:443
  • /N:CN should be set to your ServerName and your fully qualified domain name.
  • /K: typically set to 1024. 1024 is the number of bits allocated to the RSA key.
  • /V: is the number of days before the certificate expires. 1825 days is 5 years.
  • /S: is the site number in IIS.
  • /P: is the TCP port number. 443 is the standard SSL port.

Note that /S: and /P: are irrelevant in our case since you don't need IIS running on your Authentication Server. As a general rule of thumb for security sake, you run as few services on your server as possible. If you don't have IIS installed, executing the SelfSSL command as shown above will end with an error message "Error opening metabase: 0x80040154". That just means the IIS site was not found but you can ignore that error message since the Certificate you need for PEAP authentication will have already been generated.


Creating the root certificate

Once the digital certificate has been generated on your authentication server, you will need to export the root certificate for this Self Signed Certificate. The digital certificate is different from the root certificate. The digital certificate contains the public and private key pairs. The root certificate only contains the public key and a self proclamation that "I am a root certificate". You will need this root certificate for publication on a Web-server or file-server for manual root certificate deployment or you can import it in to your Active Directory Group Policy for automatic root certificate Deployment.

To begin, you'll need to open an MMC console by clicking Start | Run. Then type "mmc" and OK. You will see the following console appear (Figure B). From there, you'll click "ADD/Remove Snap-in...".

Figure B

MMC Console

You'll then see this screen (Figure C). Click on the "ADD" button.

Figure C

Add/Remove Snap-in

On this screen (Figure D), highlight "Certificates" and click on "Add" again.

Figure D

Certificates

Select "Computer account" and click "Next". (Figure E)

Figure E

Computer account

Then select "Local computer" as shown below in Figure F and click "Finish".

Figure F

Local computer

You will see the resulting console appear. (Figure G)

Figure G

Console root

Expand "Certificates (Local Computer) to reveal the following. Right click on "MyAuthServ.MyDomain" or whatever you used for your SelfSSL "/N:CN" argument, hit "All Tasks" and then choose "Export". (Figure H)

Figure H

Export

You will see the following wizard (Figure I). Choose "Next".

Figure I

Certificate Export Wizard

For this step, make sure you DO NOT export the "Private Key" because that must be kept private on the server. If you use the "Yes, export the private key" feature, that allows you to make a backup of the digital certificate but you want to guard that file in a protected area. Anyone who gets that file compromises your digital certificate because they now have a copy of your private key. Exporting the private key also lets you take that digital certificate and copy it to a redundant RADIUS server so you can import it there without having to generate a second key. If you have more than one RADIUS authentication server, make sure you copy the certificate over and don't generate a second key unless you want to complicate deployment matters by having to deploy two root certificates. (Figure J)

Figure J

Not the private key

Use the "DER" format because it is compatible with Windows and Windows Mobile devices (Figure K). Windows doesn't care what format it's in but Windows Mobile does.

Figure K

File format

Give the certificate a path and file name. (Figure L) You'll need to note the name for later use.

Figure L

Path and file name

Hit "Finish" and you've just exported your Self Signed root certificate to a file. (Figure M)

Figure M

Finish

Now you're have a self-signed root certificate ready to be deployed to the clients automatically or manually along with the digital certificate on your authentication server ready to use. We'll discuss how you actually use this certificate on our Microsoft IAS RADIUS server configuration guide.


21 comments
djclick
djclick

When I enable "Validate Server Certificate" in client, appear the error "reason-code=16" in IAS server. When I uncheked "Validate Server Certificate" option worked.

edelucas
edelucas

But before install the self-signed option do i must add the certification server module for windows 2003 server? If is that, what kinkd of certificate do i should select. First time working with certificates. I want to implement a radius server. Thanks!

beanxyz
beanxyz

One question, if I create the certificate in a sub-domain, will it affect those other root certificates in the forests? thank you.

scotter
scotter

I have been successfully using this setup with Cisco AP's, Server 2003 IAS and a self-signed cert (http://articles.techrepublic.com.com/5100-10878_11-6148560.html) We have been rolling with just the one RADIUS server for some time. In attempt to be proactive I am trying to add a secondary RADIUS sever on Server 2008. First I learned its called NPS now, there are a lot parts to it and it sets up significantly different (from what I can tell). I have the Cisco AP's looking at two RADIUS's (one server group, 1 minute deadtime before the AP contacts the next RADIUS) aaa group server radius Server-group-1 server 192.168.1.50 auth-port 1645 acct-port 1646 server 192.168.1.51 auth-port 1645 acct-port 1646 IOS config looks like above, with .51 as the '08 Server. Unfortunately, that is about as far as I have gotten. Has anyone gotten things to work based on the 03/IAS settings above but in 2008? I have gotten as far as creating the policy on the NPS server but find some confusion regarding setting up PEAP/MSCHAP on the policy (this is not the user GPO for wifi), the self-signed cert (it is from the .50 server, can I import and use it on the .51 or do I need to generate another cert and add it to the GPO?) and finally the 'conditions' portion - in IAS there are 2, NAS port type and the Windows groups (in my case). In NPS there isnt enough 'detail' in NAS Port Type to configure the security. There is a constraints section, but it seems a little confusing as well. Anyone get this situation to work on 2008?

hmooc
hmooc

Hello George, Thank you very much for all the articals you have posted on implementing secure wireless network. I have a question and a problem and was wondering if you can help me out. I administer a Small Business server and to be honest with you I did followings another set of instructions to set up wireless network for SB server but now it appears I have 2 same Trusted domains when I was selecting the server authentication certificate installed for IAS to add to the wireless access policy. How do I go about getting rid of the second Trusted Domain certificate. I believe that was generated because I have a backup domain controller and that might have replicated somehow. Would it be wise to just follow your instruction to install the self sign SSL and ignore the 2 doman certificates I created? If possible I like to get rid of the 2 trusted domain cert, would uninstalling the CA be a good idea at this time? Thanks, helen

n.christofferson
n.christofferson

I have created a cert and have imported it into my wireless group policy, but it is not showing up in the trusted CA list like the article shows. Any ideas?

rmlounsbury
rmlounsbury

One thing I'm not completely clear on. When I create a backup RADIUS Server I need to export with the private key my original cert used on my primary RADIUS server. I then copy this information over to my backup RADIUS Server and install the cert. I also go through and add the wireless clients in IAS. Do i also need to create another Wi-Fi access policy on the backup RADIUS Server? Or does the policy on the primary RADIUS Server cover the entire domain?

deathinc70
deathinc70

How can I have self signed certificates for use with multiple RADIUS servers with the same self-signed root certificate? It appears that I would need to have a separate root certificate for every radius server in our environment. Every RADIUS server has a different name. Thank You. Also - it appears that Microsoft does not support using wildcard certificates with PEAP on the client side. I tried that to allow me to purchase just one certificate for all of our RADIUS servers. RASTLS.LOG on Windows says "'*' is not allowed in server name.". The certificate is for *.someplace.com

rjs6143
rjs6143

how do I deploy the self-signed server cert via group policy? My wireless clients can connect to radius server and authenticate, but only when connected by ethernet cable.. any ideas?

deathinc70
deathinc70

You need to create the wi-fi policy on all of your radius servers.

msg2mb-tr
msg2mb-tr

Were you able to get past the"'*' is not allowed in server name." error? I am seeing the same error in my RASTLS.LOG. Thanks! From Previous Post: Also - it appears that Microsoft does not support using wildcard certificates with PEAP on the client side. I tried that to allow me to purchase just one certificate for all of our RADIUS servers. RASTLS.LOG on Windows says "'*' is not allowed in server name.". The certificate is for *.someplace.com

georgeou
georgeou

You can use the same cert with the same common name or CN. The CN isn't usally checked by the client by default unless the user or admin specifically types in the CN that needs to match. But even if the client checks the CN, the CN is stamped on the Digital Certificate so it doesn't matter what the actual name of the server is. We're not talking about HTTPS SSL where the actual fully qualified server name is checked against the CN on the cert.

mike
mike

Just so this is clear (cause George, this was an eye-opener... had no idea this was possible): If I name my cert "wireless.toyota.ca", but not one of my radius servers is named "wireless", I can export that .cer (with the private key) to multiple servers? And if I self-sign a cert on my first radius server, is it automatically imported at creation? or do I still need to open an MMC and import it, as with any 3rd party cert? Also... we use cisco aironet 1200 AP's. In the web app I note two places (SSID Manager, and Server Manager) where I can list the IP of the EAP Authentication server. Are both required? Preciate your thoughts.

deathinc70
deathinc70

I did some testing, and it works as you said. I did enable the checking of the server name on the PEAP config for Windows, and now the certificate name needs to match the server name specified in the client config, but it doesn't actually need to match the name of the radius server. Will the fully qualified server name ever be checked, or is there a reason why it isn't? I just want to make sure that this will continue to work, and that Microsoft won't break it with a security update or wireless update where it checks the fully qualified radius server name against the name of the certificate like true SSL and breaks everything. Thanks in advance.

bobaster
bobaster

First of all, many thanks for a great wireless article. I have created a self-signed cert and imported it successfully and applied it my Wi-FI access policy on the primary radius. I did not export the private key in the servername.domain.cer file. Now I want to be able to use this same cert on 2 additional backup radius servers. I can only export in the pfx format, can I still use that cert or will I have to start over and create another? Thanks in advance

georgeou
georgeou

Actually, it's often only locked down by the signing authority. The wireless client only looks at the cert name if the client has it specified under server name.

georgeou
georgeou

You can use the same cert on any number of RADIUS servers being used within the company. RADIUS server name has nothing to do with it and only the name on the Cert counts. The Wireless Client only looks at the name on the cert to see if it's trusted or not.

scotter
scotter

The GPO'd clients all have the cert in Trusted Roots and when I setup the first IAS server and configured the NAS type, the EAP properties listed just server under 'certificate issued:' - which wasnt a problem since we had just the one RADIUS server. Now I am adding a backup (NPS/Win2k8) and although this server has the FIRST cert in its own trusted root list the settings for EAP in the NPS server ONLY show the local server with authority coming from our forrest CA. I understand that the clients are only going to check against the cert as trusted and not necessarily do a FQDN on it, but do I have to somehow physically get the original cert onto the new 2k8 server?

georgeou
georgeou

You can use the same cert on any number of RADIUS servers being used within the company. RADIUS server name has nothing to do with it and only the name on the Cert counts. That's a good thing.