Deploying Secure 802.11 Wireless Networks with Microsoft Windows

PKI

When installing a public key infrastructure (PKI), use the following best practices:

• Plan your PKI before deploying certification authorities (CAs).

• For enterprise organizations, the root CA should be offline, and its signing key should be secured by a Hardware Security Module (HSM) and kept in a vault to minimize potential for key compromise.

• Enterprise organizations should not issue certificates to users or computers directly from the root CA; instead, they should deploy the following:

  • An offline root CA

  • Offline intermediate CAs

  • Online issuing CAs (using Windows 2000 or Windows Server 2003 Certificate Services as an enterprise CA)

  This CA infrastructure provides flexibility and insulates the root CA from attempts to compromise its private key by malicious users. The offline root and intermediate CAs do not have to be Windows CAs. Issuing CAs can be subordinates of a third-party intermediate CA. The offline CA needs to be placed online on a preset period to publish the certificate revocation list (CRL), or else all certificate revocation checks will fail.

• Medium-sized organizations should use a two-level hierarchy consisting of root CA/issuing CAs. Small organizations can use a single CA that is both the root CA and the issuing CA.

• Back up the CA database, the CA certificate, and the CA keys to protect against the loss of critical data. The CA should be backed up on a regular basis (daily, weekly, monthly) based on the number of certificates issued over the same interval. The more certificates issued, the more frequently you should back up the CA.

• Train your users to back up their keys. Otherwise, they will have problems imaging new machines.

• You should review the concepts of security permissions and access control in Windows because enterprise CAs issue certificates based on the security permissions of the certificate requester.

For the certificates used for wireless access, use the following best practices:

• If you are using EAP-TLS authentication, use both user and computer certificates for both user and computer authentication.

• To install computer certificates in an Active Directory directory service environment, use autoenrollment.

  This process requires the use of a Windows 2000 or Windows Server 2003 Certificate Services server as an enterprise CA at the issuer CA level.

• To install user certificates in a Windows Server 2003 Active Directory environment, use autoenrollment of user certificates.

  This process requires the use of a Windows Server 2003, Enterprise Edition, or Windows Server 2003, Datacenter Edition, Certificate Services server as an enterprise CA at the issuer CA level. Only computers running Windows XP and Windows Server 2003 support autoenrollment of user certificates.

• To install user certificates when you do not have a Windows Server 2003 Active Directory environment, use a CAPICOM script.

  Alternately, use a CAPICOM script to install both computer and user certificates.

• Because certificate revocation checking can prevent wireless access due to the unavailability or expiration of CRLs for each certificate in the certificate chain, design your PKI for high availability of CRLs. For instance, configure multiple CRL distribution points for each CA in the certificate hierarchy and configure publication schedules so that the most current CRL is always available.

• Although it is possible to import a certificate by double-clicking a certificate file that is stored in a folder or sent in an email message, this works only for certificates created with Windows CAs. This method does not work for third-party CAs. The recommended method of importing certificates is to use the Certificates snap-in.