Appendix E: Deploying a Certificate Infrastructure
Applies To: Windows Server 2003 with SP1
In a typical enterprise deployment, the certificate infrastructure is configured using single root CA in a three-level hierarchy consisting of root CA/intermediate CAs/issuing CAs. 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.
For VPN connections, issuing CAs are configured to issue computer certificates or user certificates. When the computer or user certificate is installed on the VPN client, the issuing CA certificate, intermediate CA certificates, and the root CA certificate are also installed. When the computer certificate is installed on the authenticating server, the issuing CA certificate, intermediate CA certificates, and the root CA certificate are also installed. The issuing CA for the computer certificate installed on the authenticating server can be different than the issuing CA for the VPN client certificates. In this case, both the VPN client and the authenticating server computer have all the required certificates to perform certificate validation for both IPSec and EAP-TLS authentication.
When deploying a certificate infrastructure, use the following best practices:
Plan your certificate infrastructure before deploying CAs.
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 but rather should deploy the following:
An offline root CA
Offline intermediate CAs
Online issuing CAs
This CA infrastructure provides flexibility and insulates the root CA and intermediate CAs from attempts to compromise its private key by malicious users. The offline root and intermediate CAs do not have to be Windows Server 2003 CAs. Issuing CAs can be subordinates of a third-party intermediate CA.
Backing up the CA database, the CA certificate, and the CA keys is essential 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.
You should review the concepts of security permissions and access control in Windows, because enterprise certification authorities issue certificates based on the security permissions of the certificate requester.
If you want to take advantage of auto-enrollment for computer certificates and the requesting of certificates using the Certificates snap-in, use Windows Server 2003 Certificate Services and create an enterprise CA at the issuer CA level.
For more information, see the topic titled "Checklist: Creating a certification hierarchy with an offline root certification authority" in Windows Server 2003 Help and Support.
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:
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 property of the certificate. If the CRL distribution points cannot be contacted to check for certificate revocation, then 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, then 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 wireless client's certificate. The revocation check verifies that the VPN clients 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 only eliminates 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.
All of 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 wireless 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 it expires. This can create a situation whereby a certificate is revoked, the CRL is manually published, but the authenticating server still allows the connection because the local CRL has not yet been updated.
Using Third-party CAs for EAP-TLS Authentication
You can use third-party CAs to issue certificates for EAP-TLS authentication as long as the certificates installed can be validated and have the appropriate properties.
Certificates on the Authenticating Servers
For the computer certificates installed on the authenticating servers (either the VPN servers or the IAS servers), the following must be true:
They must be installed in the Local Computer certificate store.
They must have a corresponding private key.
The cryptographic service provider for the certificates supports SChannel. If not, the certificate cannot be used and it is not selectable from the properties of the Smart Card or Other Certificate EAP type on the Authentication tab on the properties of a profile for a remote access policy.
They must contain the Server Authentication certificate purpose (also known as an Enhanced Key Usage [EKU]). An EKU is identified using an object identifier (also known as an OID). The object identifier for Server Authentication is "1.3.6.1.5.5.7.3.1".
They must contain the fully qualified domain name (FQDN) of the computer account of the authenticating server in the Subject Alternative Name property of the certificate.
Additionally, the root CA certificates of the CAs that issued the VPN client user certificates must be installed in the Trusted Root Certification Authorities certificate store of the authenticating servers.
Certificates on VPN Client Computers
For the user certificates installed on VPN client computers, the following must be true:
They must have a corresponding private key.
They must contain the Client Authentication EKU (object identifier "1.3.6.1.5.5.7.3.2").
They must be installed in the Current User certificate store.
They must contain the universal principal name (UPN) of the user account in the Subject Alternative Name property of the certificate.
Additionally, the root CA certificates of the CAs that issued the IAS server computer certificates must be installed in the Trusted Root Certification Authorities store of the VPN client computers.