Certificate Revocation and EAP-TLS Authentication

By default, the authenticating server checks for certificate revocation for all the certificates in the certificate chain sent by the VPN client during the EAP-TLS authentication process. If certificate revocation fails for any of the certificates in the chain, the connection fails authentication and is rejected. The certificate revocation check for a certificate can fail because of the following reasons:

• The certificate has been revoked.

  The issuer of the certificate has explicitly revoked the certificate.

• The certificate revocation list (CRL) for the certificate is not reachable or available.

  CAs maintain CRLs and publish them to specific CRL distribution points. The CRL distribution points are included in the CRL Distribution Points field of the certificate. If the CRL distribution points cannot be contacted to check for certificate revocation, the certificate revocation check fails. Additionally, if there are no CRL distribution points in the certificate, the authenticating server cannot verify that the certificate has not been revoked and the certificate revocation check fails.

• The publisher of the CRL did not issue the certificate.

  Included in the CRL is the publishing CA. If the publishing CA of the CRL does not match the issuing CA for the certificate for which certificate revocation is being checked, the certificate revocation check fails.

• The CRL is not current.

  Each published CRL has a range of valid dates. If the CRL Next update date has passed, the CRL is considered invalid and the certificate revocation check fails. New CRLs should be published before the expiration date of the last published CRL.

This behavior can be modified using the following registry settings in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\PPP
\EAP\13 on the authenticating server:

• IgnoreNoRevocationCheck When set to 1, the authenticating server allows EAP-TLS clients to connect 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 doesn’t include CRL information. IgnoreNoRevocationCheck is set to 0 (disabled) by default. An EAP-TLS client cannot connect unless the authenticating server completes a revocation check of the client’s certificate chain (including the root certificate) and verifies that none of the certificates have been revoked. You can use this entry to authenticate clients when the certificate does not include CRL distribution points, such as those from third parties.

• IgnoreRevocationOffline When set to 1, the authenticating server allows EAP-TLS clients to connect even when a server that stores a CRL is not available on the network. IgnoreRevocationOffline is set to 0 by default. The authenticating server does not allow clients to connect unless it can complete a revocation check of their certificate chain and verify that none of the certificates has been revoked. When it cannot connect to a server that stores a revocation list, EAP-TLS considers the certificate to have failed the revocation check. Setting IgnoreRevocationOffline to 1 prevents certificate validation failure because poor network conditions prevented their revocation check from completing successfully.

• NoRevocationCheck When set to 1, the authenticating server prevents EAP-TLS from performing a revocation check of the VPN client’s certificate. The revocation check verifies that the VPN 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, the authenticating server prevents EAP-TLS from performing a revocation check of the VPN client’s root CA certificate. NoRootRevocationCheck is set to 0 by default. 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 VPN client’s certificate chain. You can use this entry to authenticate clients when the certificate does not include CRL distribution points, such as those from third parties. Also, this entry can prevent certification-related delays that occur when a certificate revocation list is offline or is expired.

If they do not already exist, all these registry settings must be added as a DWORD type and have the valid values of 0 or 1. The VPN client does not perform certificate revocation checking of the authenticating server’s certificate and does not use these settings.

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

Certificate revocation checking is only as accurate as the last published CRL. For example, if a certificate is revoked, by default the new CRL containing the newly revoked certificate is not automatically published. CRLs are typically published based on a configurable schedule. This means that the revoked certificate can still be used to authenticate because the published CRL is not current; it does not contain the revoked certificate and can therefore still be used to create VPN connections. To prevent this from occurring, the network administrator must manually publish the new CRL with the newly revoked certificate.

By default the authenticating server uses the CRL distribution points in the certificates. However, it is also possible to store a local copy of the CRL on the authenticating server. In this case, the local CRL is used during certificate revocation checking. If a new CRL is manually published to the Active Directory, the local CRL on the authenticating server is not updated. The local CRL is updated when the CRL expires. This can create a situation whereby a certificate is revoked and the CRL is manually published, but the authenticating server still allows the connection because the local CRL has not yet been updated.