Certificate Templates and Requirements
Applies To: Windows Server 2008, Windows Server 2008 R2
In this section
When you use Extensible Authentication Protocol (EAP) with a strong EAP type, such as Transport Layer Security (TLS) with smart cards or certificates, both the client and the server use certificates to prove their identities to each other. This process is called mutual authentication. Certificates must meet specific requirements to allow the server and the client to use them for mutual authentication.
One such requirement is that the certificate is configured with one or more purposes in Application Policies extensions, also called Enhanced Key Usage (EKU) extensions, that correlate to the certificate use. For example, a certificate used for the authentication of a client to a server must be configured with the Client Authentication purpose. Similarly, a certificate used for the authentication of a server must be configured with the Server Authentication purpose. When certificates are used for authentication, the authenticator examines the client certificate, seeking the correct purpose object identifier in Application Policies extensions. For example, the object identifier for the Client Authentication purpose is 1.3.6.1.5.5.7.3.2. When a certificate is used for client computer authentication, this object identifier must be present in the Application Policies extensions of the certificate or authentication will fail.
The Certificate Templates Microsoft Management Console (MMC) snap-in allows customization of the certificates that are issued by Active Directory Certificate Services (AD CS). Customization possibilities include both how certificates are issued and what the certificates contain, including their purposes. In the Certificate Templates snap-in, you can use a default template, such as the Computer template, to define the template that the certification authority (CA) uses to assign certificates to computers. You can also create a certificate template and assign purposes in EKU extensions to the certificate. By default, the Computer template includes the Client Authentication purpose and the Server Authentication purpose in EKU extensions.
The certificate template that you create can include any purpose for which the certificate will be used. For example, if you use smart cards for authentication, you can include the Smart Card Logon purpose in addition to the Client Authentication purpose. You can configure Network Policy Server (NPS) to check certificate purposes before granting network authorization. NPS can check additional EKUs and Issuance Policy purposes (also known as certificate policies).
Note
Some non-Microsoft CA software might contain a purpose named All, which represents all possible purposes. This is indicated by a blank (or null) EKU extension. Although All is intended to mean "all possible purposes," the All purpose cannot be substituted for the Client Authentication purpose, the Server Authentication purpose, or any other purpose related to network access authentication.
Understanding authentication with certificates
When a certificate is provided to a client or server computer as proof of identity, the authenticator must examine the certificate to determine its validity, whether it is configured with the purpose for which it is being used, and to find out whether the certificate was issued by a CA that the authenticator trusts.
Assuming that a certificate is configured properly and is valid, the most important aspect of the authentication process is the check by the authenticator that it trusts the CA that issued the certificate.
If the authenticator trusts the CA and the certificate is valid and configured properly according to the minimum server and client certificate requirements, authentication succeeds. If the authenticator does not trust the CA, authentication fails.
How trust is established
Windows-based computers keep certificates in a certificate store on the local computer. There is a certificate store for the Local Computer, for the Current User, and for individual services, such as Network Connections, Automatic Updates, and Computer Browser. In each certificate store there is a folder named Trusted Root Certification Authorities that contains certificates from every CA that is trusted, whether they are public or private CAs.
To determine trust, the authenticator checks the Trusted Root Certification Authorities certificate store for either Current User or Local Computer.
If the CA that issued the client, user, or server certificate being used for authentication has a certificate in the Trusted Root Certification Authorities certificate store on the local computer, the authenticator trusts the certificate. If the issuing CA does not have a CA certificate in the Trusted Root Certification Authorities certificate store on the local computer, the authenticator does not trust the certificate.
Important
The CA certificate must be present in the Trusted Root Certification Authorities certificate store on the local computer, whether that computer is a client or a server, for other certificates issued by the CA to be trusted.
Public CAs
Some of these trusted root CA certificates, which are issued by public trusted root certification authorities, are included by default in all installations of Windows; they are included on the product installation compact disc or they are present on computers sold by original equipment manufacturers (OEMs) that provide computers that have Windows installed on them.
For example, in the certificate store on computers running Windows XP, in the Trusted Root Certification Authorities folder, there are CA certificates from the VeriSign Trust Network CA, the Thawte Premium Server CA, and the Microsoft Root Certification Authority. If a computer running Windows XP is presented with a certificate that was issued by one of these CAs and the certificate is configured properly and is valid, the computer running Windows XP trusts the certificate.
You can purchase additional certificates from many companies, such as VeriSign and Thawte, to use in your authentication infrastructure. For example, when you deploy PEAP-MS-CHAP v2 and the Validate server certificate setting is enabled on the client, the client computer authenticates the NPS server using the NPS server certificate. If you do not want to deploy your own CA and issue your own server certificates to NPS servers, you can purchase a server certificate from a company whose CA is already trusted by client computers.
Private CAs
When an organization deploys its own public key infrastructure (PKI), and then installs a private trusted root CA, their CA automatically sends its certificate to all domain member computers in the organization. The domain member client and server computers store the CA certificate in the Trusted Root Certification Authorities certificate store. After this occurs, the domain member computers trust certificates that are issued by the organization trusted root CA.
For example, if you install AD CS, the CA sends its certificate to the domain member computers in your organization, and then the domain member computers store the CA certificate in their local Trusted Root Certification Authorities certificate store. If you also configure and autoenroll a server certificate for your NPS servers and then deploy PEAP-MS-CHAP v2 for wireless connections, all domain member wireless client computers can successfully authenticate your NPS servers by using the NPS server certificate because they trust the CA that issued the NPS server certificate.
Note
Non-domain member computers must have the private CA certificate manually installed in their local Trusted Root Certification Authorities certificate store for them to trust certificates, such as NPS server certificates, that are issued by the private CA.
Required certificates
The following table identifies the certificates that are required to successfully deploy each of the certificate-based authentication methods.
| Certificate | Required for EAP-TLS and PEAP-TLS? | Required for PEAP-MS-CHAP v2? | Details |
|---|---|---|---|
CA certificate in the Trusted Root Certification Authorities certificate store for Local Computer and Current User. |
Yes. The CA certificate is enrolled automatically for domain member computers. For non-domain member computers, the certificate must be manually imported into the certificate store. |
Yes. The CA certificate is enrolled automatically for domain member computers. For non-domain member computers, the certificate must be manually imported into the certificate store. |
For PEAP-MS-CHAP v2, The CA certificate is required for mutual authentication between client and server. |
Client computer certificate in the certificate store of the client. |
Yes. Client computer certificates are required unless user certificates are distributed on smart cards. Client certificates are enrolled automatically for domain member computers. For non-domain member computers, the certificate must be manually imported or obtained by using the Web enrollment tool. |
No. User authentication is performed with password-based credentials, not certificates. |
If you deploy user certificates on smart cards, client computers do not need client certificates. |
Server certificate in the certificate store of the NPS server. |
Yes. You can configure AD CS to autoenroll server certificates to members of the RAS and IAS servers group in Active Directory Domain Services (AD DS). |
Yes. In addition to using AD CS for server certificates, you can purchase server certificates from other CAs that client computers already trust. |
The NPS server sends the server certificate to the client computer; the client computer uses the certificate to authenticate the NPS server. |
User certificate on a smart card. |
No. This certificate is required only if you choose to deploy smart cards rather than autoenrolling client computer certificates. |
No. User authentication is performed with password-based credentials, not certificates. |
For EAP-TLS and PEAP-TLS, if you do not autoenroll client computer certificates, user certificates on smart cards are required. |
Wireless clients
How certificates are used to authenticate wireless clients varies depending on the authentication method. IEEE 802.1X authentication provides authenticated access to 802.11 wireless networks and to wired Ethernet networks. 802.1X provides support for secure EAP types, such as TLS with smart cards or certificates.
You can configure 802.1X with EAP-TLS in a variety of ways. If the Validate server certificate option is configured on the client, the client authenticates the server by using its certificate. Client computer and user authentication can be accomplished by using certificates from the client certificate store or a smart card, providing mutual authentication.
With wireless clients, PEAP-MS-CHAP v2 can be used as the authentication method. During PEAP-MS-CHAP v2 authentication, the NPS server supplies a certificate to provide proof of its identity to the connecting client. If the Validate server certificate option is configured on the Windows Vista® or Windows XP Professional client, the client uses the certificate to authenticate the NPS server. User authentication is then performed with password-based credentials rather than with a certificate. This use of password-based rather than certificate-based credentials eliminates some of the difficulty of deploying secure authentication for wireless client computers.