EAP-PEAPv0 (EAP-MSCHAPv2) requires a server certificate be installed on the RADIUS server in order to establish a secure TLS tunnel. Client computer and user certificates are not required as EAP-MSCHAPv2 is password-based. If Mutual Authentication is configured, the server certificate must be trusted by the client. This will require the CA certificate be installed on the client. See Mutual Authentication below for further information. Server, Client Computer, User, and CA certificates are defined below.

Server Certificate
Issued to RADIUS server by a public or private Certificate Authority (CA). Used to establish a secure TLS tunnel and when the RADIUS server needs to prove its identity to the client. EAP-PEAPv0 (EAP-MSCHAPv2) requires a server certificate be installed on the RADIUS server.

Client Computer Certificate
Issued to client computers by a public or private CA and used when the client computer needs to prove its identity to the RADIUS server. Again client computer certificates are not required because EAP-PEAPv0 (EAP-MSCHAPv2) is password based.

User certificate
Issued to individuals by a public or private CA and typically distributed as a certificate that is embedded on a smart card. The certificate on the smart card is used, along with a smart card reader that is attached to the client computer, when individuals need to prove their identity to RADIUS servers during the authentication process. Again user certificates are not required because EAP-PEAPv0 (EAP-MSCHAPv2) is password based.

CA Certificate
When present on client and server computers, tells the client or server that it can trust other certificates, such as certificates used for client or server authentication that are issued by this CA. If Mutual Authentication is configured, the server certificate must be trusted by the client. This will require the CA certificate be installed on the client. See Mutual Authentication below for further information.

Deploying RADIUS Server Certificates

There are two alternatives for deploying RADIUS Server certificates:

  1. Purchasing a certificate from a public root certificate authority (CA) such as VeriSign that is already trusted by the client.
  2. Deploying a private Certificate Authority on your network by leveraging something such as Microsoft Active Directory Certificate Services.

There are advantages and disadvantages to each.

Advantages of purchasing a certificate from a public root certificate authority (CA) such as VeriSign that is already trusted by the client are as follows:

  • Installing purchased certificates does not require as much specialized knowledge as deploying a private CA on your network, and can be easier to deploy in networks that have only a few RADIUS Servers.
  • Using purchased certificates can prevent specific security vulnerabilities that can exist if the proper precautions are not taken when deploying a private CA on your network.
  • There is no requirement to distribute private CA certificates to clients. The RADIUS Server is trusted by the client because the client already trusts the public root CA that issued the RADIUS Server certificate. This is required for mutual authentication.

Disadvantages of purchasing a certificate from a public root certificate authority (CA) such as VeriSign that is already trusted by the client are as follows:

  • This solution does not scale as well as deploying a private CA on your network because you must purchase a certificate for each RADIUS Server, your deployment costs increase with each RADIUS Server you deploy.
  • Purchased certificates have recurring costs, because you must renew certificates prior to their expiration date.

Advantages of deploying a private Certificate Authority on your network by leveraging something such as Microsoft Active Directory Certificate Services are as follows:

  • AD CS is included with Windows Server.
  • This solution scales very well. After you have deployed a private CA on your network, AD CS can automatically distribute certificates to all Microsoft RADIUS/Network Policy Servers (NPS) in your domain with no incremental increases in cost, even if you later add NPS Servers to your network.
  • AD CS can automatically distribute a server certificate to new NPS Servers that you add to your network.
  • AD CS automatically distributes its private CA certificate to domain users and computers in the Trusted Root Certificate Authorities store of the user and computer.  The NPS Server is trusted by the client because the client trusts the private CA that issued the NPS Server certificate. This is required for mutual authentication.
  • If you later decide to change your authentication infrastructure from secure password authentication using PEAP to one that requires client certificates and uses either EAP-TLS or PEAP-TLS, you can do so by using your AD CS-based private CA.

Disadvantages of deploying a private Certificate Authority on your network by leveraging something such as Microsoft Active Directory Certificate Services are as follows:

  • Deploying a private CA on your network requires more specialized knowledge than purchased certificates, and can be more difficult to deploy.
  • It is possible to expose your network to specific security vulnerabilities if the proper precautions are not taken when deploying a private CA on your network.
  • Non-domain computers must have the private CA certificate manually installed in the Trusted Root Certification Authorities store for them to trust the NPS Server certificate that was issued by the private CA. This is required for mutual authentication.

Mutual Authentication
Mutual authentication requires not only the server authenticate the client but also the client authenticate the server. In order to configure mutual authentication, where the client authenticates the RADIUS Server in addition to the RADIUS Server authenticating the client, the RADIUS Server for example Microsoft NPS must have a server certificate installed, the client must trust the server certificate, and the client must be configured to validate the server certificate. In addition to validating the server certificate to reduce potential risks against man-in-the-middle and password-based attacks, the client should be configured by the administrator to connect to specific authentication servers, limit the trusted root CAs available for use with PEAP, and to ”not prompt user to authorize new servers or trusted certification authorities”. Although client computer and user certificates are not required with EAP-PEAPv0 (EAP-MSCHAPv2), in order for the client to trust the server certificate, the private CA certificate from the CA that issued the RADIUS Server certificate must be installed in the Trusted Root Certification Authorities store on the client. Ideally these settings and the private CA certificate are distributed to the clients using Mobile Device Management/Onboarding soft ware or Microsoft group policy and AD CS. Alternatively a certificate purchased from a public root certificate authority such as VeriSign that is already trusted by the client could be installed on the server and therefore it would not be required to distribute private CA certificates to the clients. If the steps noted above to reduce potential risks against man-in-the-middle and password-based attacks are not taken, it is generally trivial to introduce a fake/rogue access point which allows gathering MS-CHAPv2 handshakes. These can be cracked in a matter of seconds with readily available tools.

Example Microsoft Windows 7 recommended settings to reduce potential risks against man-in-the-middle and password-based attacks (validate server certificate, only allow connections to specific RADIUS servers, limit trusted root CAs, do not prompt user to authorize new servers or trusted CAs). Again it is recommended these setting be pushed out and enforced by Mobile Device Management/Onboarding software or Microsoft Group Policy and NOT left to the end user/client to configure themselves.

Need more background on EAP-PEAP? Check out our EAP-PEAP A Closer Look blog.