Troubleshooting Certificate-Based Validation

Troubleshooting Certificate-Based Validation

Troubleshooting certificate validation for EAP-TLS authentication consists of verifying the wireless client s computer and user certificates and the computer certificates of the IAS servers (as discussed in the following sections).

Validating the Wireless Client s Certificate

In order for an IAS server to validate the certificate of a wireless client, the following must be true for each certificate in the certificate chain sent by the wireless client:

• The current date is within the validity dates of the certificate.

  When certificates are issued, they are issued with a range of valid dates, before which they cannot be used and after which they are considered expired.

• The certificate has not been revoked.

  Issued certificates can be revoked at any time. Each issuing certification authority (CA) maintains a list of certificates that should no longer be considered valid by publishing an up-to-date certificate revocation list (CRL). By default, the IAS server checks all the certificates in the wireless client s certificate chain (the series of certificates from the wireless client certificate to the root CA) for revocation. If any of the certificates in the chain have been revoked, certificate validation fails. This behavior can be modified with registry settings described later in this chapter.

  To view the CRL distribution points for a certificate in the Certificates snap-in (as shown in Figure 16-1), double-click the certificate in the contents pane, click the Details tab, and then click the CRL Distribution Points field.

  

  Figure 16-1. The CRL Distribution Points field.

  The certificate revocation validation works only as well as the CRL publishing and distribution system. If the CRL is not updated often, a certificate that has been revoked can still be used and considered valid because the published CRL that the IAS server is checking is out of date.

• The certificate has a valid digital signature.

  CAs digitally sign certificates they issue. The IAS server verifies the digital signature of each certificate in the chain (with the exception of the root CA certificate) by obtaining the public key from the certificate s issuing CA and mathematically validating the digital signature.

The wireless client certificate must also have the Client Authentication certificate purpose (also known as Enhanced Key Usage [EKU]) and must contain either a UPN of a valid user account or a fully qualified domain name (FQDN) of a valid computer account in the Subject Alternative Name field of the certificate.

To view the EKU for a certificate in the Certificates snap-in (as shown in Figure 16-2), double-click the certificate in the contents pane, click the Details tab, and then click the Enhanced Key Usage field.

Figure 16-2. The Enhanced Key Usage field.

To view the Subject Alternative Name field for a certificate in the Certificates snap-in (as shown in Figure 16-3), double-click the certificate in the contents pane, click the Details tab, and then click the Subject Alternative Name field.

Figure 16-3. The Subject Alternative Name field.

Finally, to trust the certificate chain offered by the wireless client, the IAS server must have the root CA certificate of the issuing CA of the wireless client certificate installed in its Trusted Root Certification Authorities Local Computer store.

NOTE
In addition to performing normal certificate validation, the IAS server verifies that the identity sent in the initial EAP-Response/Identity message is the same as the name in the Subject Alternative Name property of the received certificate. This prevents a malicious user from masquerading as a different user or computer from that specified in the EAP-Response/Identity message.

By default, IAS performs certificate revocation checking on the certificate received from the wireless clients. The following registry settings in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\13 on the IAS server can modify certificate revocation behavior:

• IgnoreNoRevocationCheck

  When set to 1, IAS accepts EAP-TLS authentications, even when it does not perform or cannot complete a revocation check of the client s certificate chain (excluding the root certificate). Typically, revocation checks fail because the certificate does not include CRL information.

  IgnoreNoRevocationCheck is set to 0 (disabled) by default. IAS rejects an EAP-TLS authentication unless it can complete a revocation check of the client s certificate chain (including the root certificate) and verify that none of the certificates have been revoked.

  Set IgnoreNoRevocationCheck to 1 to accept EAP-TLS authentications when the certificate does not include CRL distribution points, such as those from third-party CAs.

• IgnoreRevocationOffline

  When set to 1, IAS accepts EAP-TLS authentications, even when a server that stores a CRL is not available on the network. IgnoreRevocationOffline is set to 0 by default. IAS rejects an EAP-TLS authentication unless it can access CRLs and complete a revocation check of their certificate chain and verify that none of the certificates has been revoked. When it cannot connect to a location that stores a CRL, EAP-TLS considers the certificate to have failed the revocation check.

  Set IgnoreRevocationOffline to 1 to prevent certificate validation failure due to poor network conditions that inhibit revocation checks from completing successfully.

• NoRevocationCheck

  When set to 1, IAS does not perform a revocation check on the wireless client s certificate. The revocation check verifies that the wireless client s certificate and the certificates in its certificate chain have not been revoked. NoRevocationCheck is set to 0 by default.

• NoRootRevocationCheck

  When set to 1, IAS does not perform a revocation check of the wireless client s root CA certificate. This entry eliminates only the revocation check of the client s root CA certificate. A revocation check is still performed on the remainder of the wireless client s certificate chain. NoRootRevocationCheck is set to 0 by default.

  You can use NoRootRevocationCheck to authenticate clients when the root CA certificate does not include CRL distribution points, such as those from third-party CAs. Also, this entry can prevent certification-related delays that occur when a certificate revocation list is offline or is expired.

All these registry settings must be added as a DWORD (a registry data type composed of hexadecimal data with a maximum allotted space of 4 bytes) type and have the valid values of 0 or 1. The Windows wireless client does not use these settings.

Validating the IAS Server s Certificate

In order for the wireless client to validate the certificate of the IAS server, the following must be true for each certificate in the certificate chain sent by the IAS server:

• The current date must be within the validity dates of the certificate.

  When certificates are issued, they are issued with a range of valid dates, before which they cannot be used and after which they are considered expired.

• The certificate has a valid digital signature.

  CAs digitally sign certificates they issue. The wireless client verifies the digital signature of each certificate in the chain, with the exception of the root CA certificate, by obtaining the public key from the certificate s issuing CA and mathematically validating the digital signature.

Additionally, the IAS server computer certificate must have the Server Authentication EKU (object identifier [OID] 1.3.6.1.5.5.7.3.1). To view the EKU for a certificate in the Certificates snap-in, double-click the certificate in the contents pane, click the Details tab, and then click the Enhanced Key Usage field.

Finally, to trust the certificate chain offered by the IAS server, the wireless client must have the root CA certificate of the issuing CA of the IAS server certificate installed in its Trusted Root Certification Authorities Local Computer store.

Notice that the wireless client does not perform certificate revocation checking for the certificates in the certificate chain of the IAS server s computer certificate. The assumption is that the wireless client does not yet have a physical connection to the network and therefore cannot access a Web page or other resource in order to check for certificate revocation.