Public Key Certificate

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

In Windows 2000 and Windows Server 2003, you can use Certificate Services to automatically manage computer certificates for IPSec throughout the certificate lifecycle. Certificate Services is integrated with Active Directory and Group Policy, and it simplifies certificate deployment by enabling certificate auto-enrollment and renewal and by providing configurable certificate templates. In addition, by publishing the computer certificate as an attribute of the domain computer account, Certificate Services allows you to use IPSec to restrict network access to a server.

Use a public key certificate in situations that include access to corporate resources, external business partner communications, or computers that do not run the Kerberos V5 authentication protocol. This requires that at least one trusted root CA is configured on your network and that client computers have an associated computer certificate.

IPSec supports the use of a variety of third-party X.509 public key infrastructure (PKI) systems, in addition to Windows 2000 Server or Windows Server 2003 Certificate Services. Windows Server 2003 IKE has basic compatibility with several certificate systems, including those offered by Microsoft, Entrust, VeriSign, and Netscape. If you are using a third-party PKI system, the PKI system must be able to issue certificates to computers and store their certificates in the Windows Cryptographic Application Programming Interface (CryptoAPI) computer certificate store.

Note

• Certificates obtained from Certificate Services with the advanced option set for Enable strong private key protection do not work for IKE authentication because a personal identification number (PIN) cannot be entered to access the private key during IKE negotiation.

General certificate authentication considerations

IKE’s use of certificate authentication is compatible with many different PKI architectures, and IKE places relatively few requirements on the contents of a certificate. Typically, computers that have a common trusted root, or whose certificates can chain through a cross-certification trust relationship, can successfully use IKE authentication. To use certificates for IKE authentication, you define an ordered list of acceptable root CA names in the authentication method. This list controls the certificates that IKE can select and the certificates that IKE will select. If IKE authentication fails, you cannot retry the authentication using a different method. For this reason, before you apply an IPSec policy that can use certificates for authentication, make sure that all target computers have the correct root CA certificates and relevant cross-certificates in the CryptoAPI PKI stores, as well as valid computer certificates. Additionally, to ensure that certificate authentication works as intended, test your PKI infrastructure with various IPSec policy configurations before deployment.

The following sections describe the IKE certificate selection and acceptance process. If you decide to use certificates for IKE authentication, understanding this process and its requirements is integral to ensuring proper deployment.

IKE certificate selection process

When IKE negotiates to use certificates for authentication, the following process is used to select a computer certificate:

1. The list of trusted roots is prepared. This list is the list of the CA root names provided by the peer in the Certificate Request Payloads (CRPs), and it matches the CA root names configured in the list of trusted roots in the appropriate authentication method of the IPSec policy. If there are no matching CA root names, all trusted CA root names from the appropriate authentication method are used.

2. IKE searches the computer store for an IPSec certificate that chains to any of the trusted CA roots identified in step 1. An IPSec certificate contains an Enhanced Key Usage (EKU) attribute with a value equal to the IP security IKE intermediate object identifier (OID) 1.3.6.1.5.5.8.2.2.

3. For each certificate chain found, the following checks are performed to verify that:

   • The certificate chain does not have any trust errors.

   • The certificate chain is not a root-only chain.

   • The computer certificate has a private key.

   • The computer certificate has an RSA type public/private key pair.

   • The computer certificate has a public key length that is greater than 512 bits.

   • The computer certificate has a Digital Signature key usage.

   • The computer certificate is not a CA signing certificate that is used to issue certificates.

   • The certificate chain passes certificate revocation list (CRL) checking, which is performed by default or if the value of the StrongCrlCheck registry key is set to 1 or 2. For more information about CRL checking, see "CRL Checking" later in this chapter.

   If all of these checks succeed, IKE selects the certificate chain to be sent to the IPSec peer. If any of these checks fails, IKE continues to search for another IPSec type certificate, using the same list of root CA names.

4. If a valid computer certificate chain is not located, IKE retries the process, from step 2. Although the same list of root CA names is used, IKE does not search for an IPSec type certificate.

5. If a valid computer certificate chain is still not found and if the list of root CA names in step 1 is a subset of the names allowed by the local IPSec policy, IKE retries, from step 2. This time, IKE uses the entire list of root CA names allowed by the local authentication method.

   This step is required for successful authentication when cross-certificates are used to establish trust relationships.

6. After IKE selects a computer certificate, it includes all intermediate certificates in the chain up to the root, except for the root CA certificate. A certificate chain in PKCS#7 format is then sent to the IPSec peer. If there are no intermediate CAs, only the computer certificate is sent.

   If a computer certificate cannot be selected, the authentication fails.

Note

• If IKE negotiates with another computer running Windows Server 2003, or with other Microsoft IKE implementations that use IPSec NAT-T (such as Microsoft L2TP/IPsec VPN Client), a special method to avoid fragmentation of ISAKMP UDP packets might be implemented. Otherwise, the ISAKMP message that contains the certificate chain will likely be fragmented as the packet is transmitted.

IKE certificate acceptance process

1. IKE receives the peer’s certificates or certificate chains and verifies that the peer’s certificates chain up to any of the root CAs in the appropriate authentication method of the local IPSec policy.

2. For each peer certificate chain, the following checks are performed to verify that:

   • The computer certificate Subject Name or Subject AltName is consistent with the peer’s ID field passed in the IKE negotiation.

   • The computer certificate chain does not have any trust errors. If there is a trust error, the peer authentication fails.

3. If the two checks in step 2 succeed, the following checks are performed for the peer certificate chain to verify that:

   • The certificate chain passes CRL checking, which is performed by default or if the value of the StrongCrlCheck registry key is set to 1 or 2.

   • The computer certificate has an RSA type public/private key pair.

   • The computer certificate has a public key length that is greater than 512 bits.

   • The computer certificate has a Digital Signature key usage.

   If any of these checks fails, the peer authentication fails.

4. If certificate-to-account mapping is enabled in the IPSec policy for the certificate root CA of the peer, IKE calls the Windows secure channel (Schannel) APIs to perform the mapping. Schannel completes the mapping and builds an access token for the computer account. This access token is automatically evaluated against the Access this computer from the network or the Deny this computer access from the network logon right defined in Group Policy Security settings.

   If the logon right evaluation fails, the peer authentication fails.

Editing Default Certificate Templates to Include the Subject Name

The IP Security Monitor snap-in, Event Viewer, and most IPSec diagnostics report the Subject Name attribute of the IPSec peer certificate. In Windows Server 2003 Certificate Services, the default version 2 certificate template for IPSec certificates does not include the computer name in the Subject Name field (the version 1 certificate templates cannot be modified). To aid in deployment and troubleshooting, edit the default IPSec certificate template to include either the FQDN or the common name of the computer in the Subject Name field. To do this, use the following procedure (note that you must be logged on as a member of the Enterprise Admins group or the root domain’s Domain Admins group in Active Directory):

To edit the default IPSec certificate template

1. Open the Certificate Templates snap-in (Certtmp.msc).

2. Right-click the certificate template that you want to modify, and then click Properties.

3. On the Subject Name tab, click Build from this Active Directory Information, and then click Common Name or Fully Distinguished Name.

4. Enter the common name or FQDN as required.

If you choose to enter the common name of the computer, the name in the Subject Name field of the certificate will appear as CN=< FQDN>. If any FQDN is greater than 64 characters, select Fully Distinguished Name, not Common Name. After you complete this procedure, all subsequently issued computer certificates will contain the FQDN in the Subject Name field of the certificate. If you have already completed enrollment for computer certificates by using the default certificate template, create a new certificate template and configure it to supersede the existing template. Doing this will automatically update all computer certificates so that the blank name in the Subject Name field is replaced with the FQDN of the computer. If the existing certificate template is not superseded, each computer will have two computer certificates that can be used for IKE authentication. IKE can choose either one.

Auditing IKE Negotiation Successes and Failures

You can view the success or failure of IKE negotiations in the Event Viewer security log. To view these events, enable success or failure auditing for the Audit logon events audit policy for your domain or local computer. If auditing is enabled for IKE events, and IKE authentication fails, event 547 is recorded. If IKE authentication succeeds, event 541 is recorded.

When you enable success or failure auditing for the Audit logon events audit policy, IPSec records the success or failure of each main mode and quick mode negotiation and the establishment and termination of each negotiation as separate events. In many cases, it might be necessary to enable success auditing for the Audit logon events audit policy, to track user activity. Keep in mind, however, that enabling this type of auditing can cause the security log to fill with IKE events. You can disable auditing of IKE events by modifying the registry.

To disable auditing of IKE events in the security log, do the following:

1. Set the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Audit\DisableIKEAudits registry setting to a value of 1.

   The DisableIKEAudits key does not exist by default and must be created.

2. Do one of the following:

   • Restart the computer

   • Stop, and then restart the IPSec service by running the net stop policyagent and net start policyagent commands at the command prompt.

     Note

Stopping and restarting the IPSec service can disconnect all of the computers that are using IPSec from the computer on which the IPSec service is stopped, and it can prevent further communication with that computer. If you restart the IPSec service immediately, TCP-based communication might resume, due to the retransmit behavior of TCP, after new IKE and IPSec SAs are established.

CRL Checking

By default, in Windows XP and Windows Server 2003, IPSec CRLs are automatically checked during IKE certificate authentication, but a fully successful CRL check is not required for the certificate to be accepted. However, if enhanced security is required, a fully successful CRL check is also required. CRL checking can cause delays in authentication or unnecessary failures, and some third-party PKI systems might not support it. You can disable IPSec CRL checking or specify a stronger level of IPSec CRL checking by using the Netsh IPSec context or by modifying the registry.

To disable IPSec CRL checking or specify a different level of IPSec CRL checking by using the Netsh IPSec context, use the following command:

netsh ipsec dynamic set config strongcrlcheck value={0 | 1 | 2}

To disable IPSec CRL checking or specify a different level of IPSec CRL checking

1. Under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\PolicyAgent\, add a new Oakley key, with a DWORD entry named StrongCRLCheck.

2. Assign this entry any value from 0 through 2, where:

   • A value of 0 disables CRL checking.

   • A value of 1 enables the default level of CRL checking for Windows Server 2003 IKE. When this level of CRL checking is performed, certificate validation fails only if the certificate is revoked.

   • A value of 2 enables strong CRL checking, which means that certification validation fails if any error is encountered during CRL processing.

3. Do one of the following:

   • Restart the computer.

   • Stop, and then restart the IPSec service by running the net stop policyagent and net start policyagent commands at the command prompt.

Caution

• Do not edit the registry unless you have no alternative. The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back it up first and see the Windows Server 2003 Resource Kit Registry Reference on the Windows Server 2003 Deployment Kit companion CD or at https://www.microsoft.com/reskit.

Note that IPSec CRL checking does not guarantee that certificate validation fails immediately when a certificate is revoked. There is a delay between the time that the revoked certificate is placed on an updated and published CRL and the time when the computer that performs the IPSec CRL checking retrieves this CRL. The computer does not retrieve a new CRL until the current CRL has expired or until the next time the CRL is scheduled to be published. By default, IKE requests that Crypto API (CAPI) waits 15 seconds to complete the CRL retrieval. If the CRL cannot be retrieved at that time, IKE either ignores the error (if the value of the StrongCRLCheck registry key is set to 1, or it causes authentication to fail (if the value of StrongCRLCheck is set to 2). CRLs are cached in memory and in \Documents and Settings\UserName\Local Settings\Temporary Internet Files by CAPI. Because CRLs persist across computer restarts, if a CRL cache problem occurs, restarting the computer does not resolve the problem. For more information about CRLs, see the Troubleshooting Certificate Status and Revocation link on the Web Resources page at https://www.microsoft.com/windows/reskits/webresources.

Certificate-to-Account Mapping

In Windows Server 2003, a specific group of computers can be authorized to use IPSec when either Kerberos V5 or certificates are used for IKE authentication. This capability enables much stronger peer authentication and IPSec to be used to restrict network access to a server. When you enable IPSec certificate-to-account mapping, the IKE protocol associates (that is, maps) a computer certificate to a computer account in an Active Directory domain or forest, and then retrieves an access token, which includes the list of computer security groups. This process ensures that the certificate offered by the IPSec peer corresponds to an active computer account in the domain, and that the certificate is one that should be used by that computer.

Certificate-to-account mapping can only be used for computer accounts that are in the same forest as the computer performing the mapping. This provides much stronger authentication than simply accepting any valid certificate chain. For example, you can use this capability to restrict access to computers that are only within the same forest. Certificate-to-account mapping, however, does not ensure that a specific trusted computer is being allowed IPSec access.

Certificate-to-account mapping is especially useful if the certificates come from a PKI that is not integrated with your Active Directory deployment, such as if business partners obtain their certificates from third-party providers. You can configure the IPSec policy authentication method to map certificates to a domain computer account for a specific root CA. You can also map all certificates from an issuing CA to one computer account. This allows IKE certificate authentication to be used to limit which forests are allowed IPsec access in an environment where many forests exist and each perform autoenrollment under a single internal root CA. If the certificate-to-account mapping process is not completed properly, authentication will fail and IPSec-protected connections will be blocked. For more information about establishing certificate-to-account mapping, see the Windows Security Collection of the Windows Server 2003 Technical Reference (or see the Windows Security Collection on the Web at https://www.microsoft.com/reskit).

Excluding the CA Name from Certificate Requests

If you use certificate authentication to establish trust between IPSec peers, you can also use Windows Server 2003 to exclude CA names from certificate requests. Excluding the CA name prevents a malicious user from learning sensitive information about the trust relationships of a computer, such as the name of the company that owns the computer and the domain membership of the computer (if an internal PKI is being used). Although excluding the CA name from certificate requests enhances security, computers with multiple certificates from different roots might require the CA root names to select the correct certificate. Also, some third-party IKE implementations might not respond to a certificate request that does not include a CA name. For these reasons, excluding the CA name from certificate requests might cause IKE certificate authentication to fail in certain cases.