Test Lab Guide: Deploying an AD CS Two-Tier PKI Hierarchy

 

Applies To: Windows Server 2012 R2, Windows Server 2012

The purpose of this Test Lab Guide (TLG) is to enable you to create a two-tier public key infrastructure (PKI) hierarchy using Windows Server® 2012 and Active Directory Certificate Services (AD CS).

Note

To comment on this content or ask questions about the information presented here, please use our Feedback guidance.

In this guide

This document contains instructions for extending the Windows Server 2012 Base Configuration Test Lab Guide (TLG) to include an offline root certification authority and install an online enterprise subordinate certification authority on the computer APP1 from the Base Configuration TLG. In this guide you will deploy a two-tier PKI hierarchy, configure a certificate revocation list (CRL) distribution point (CDP), automatically deploy certificates to the domain, and utilize a certificate to enable Secure Sockets Layer (SSL) communication with the APP1 web site.

Important

The configuration of the computers and network in this guide was designed to give you hands-on practice in creating a two-tier certification authority PKI hierarchy. The design decisions made in this guide were geared toward increasing your hands-on experience and do not reflect a best practices configuration. For best practice information, see Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure (https://technet.microsoft.com/library/cc772670.aspx) and PKI Design Brief Overview (https://social.technet.microsoft.com/wiki/contents/articles/pki-design-brief-overview.aspx).

Test lab overview

The test lab configuration demonstrated in this guide extends the Windows Server 2012 or Windows Server 2012 R2 Base Configuration TLG by one server computer. The additional computer will serve as an offline root CA and be named ORCA1. There are six major steps in this test lab guide to complete that include multiple subordinate procedures.

1. Complete the Base TLG Configuration

2. Configure ORCA1

3. Configure APP1 to distribute certificates and CRLs

4. Configure APP1 as an enterprise subordinate CA

5. Enable certificate auto-enrollment

6. Configure SSL for APP1

AD CS Two Tier PKI Hierarchy Network Configuration

Important

Although EDGE1 and INET1 are pictured in the figure, they are not utilized in the lab.

Hardware and software requirements

The following are the minimum required components of the test lab:

1. The product disc or files for Windows Server 2012 or Windows Server 2012 R2.

2. Three computers that meet the minimum hardware requirements for Windows Server 2012 or Windows Server 2012 R2.

   Note

   
   You will need only the DC1, APP1, and CLIENT1 computers from the Base Test Lab configuration to complete this lab. You will also build the ORCA1 computer during this lab. As previously mentioned, INET1 and EDGE1 are not utilized in this lab.

3. The product disc or files for Windows® 8 or Windows® 8.1.

4. One computer that meets the minimum hardware requirements for Windows 8 or Windows 8.1.

5. One removable media with enough free space to hold a few certificates and certificate revocation lists (about 10 kilobytes). This can be either physical or virtual removable media depending on whether your lab is using physical or virtual computers.

   Note

   
   For instructions on transferring files using a virtual floppy disk using Microsoft Windows Server™ Hyper-V, see Creating, Using, and Transferring Files using Virtual Floppy Disks (https://social.technet.microsoft.com/wiki/contents/articles/4272.aspx).

6. If you wish to deploy the Base Configuration test lab in a virtualized environment, your virtualization solution must support Windows Server 2012 or Windows Server 2012 R2 64-bit virtual machines. The server hardware must support the amount of RAM required to run the virtual operating systems included in the Base Configuration test lab and any other virtual machines that may be required by additional TLGs.

Important

Run Windows Update on all computers or virtual machines either during the installation or immediately after installing the operating systems. After running Windows Update, you can isolate your physical or virtual test lab from your production network.

Step 1: Complete the Base TLG Configuration

The Windows Server 2012 Base Configuration Test Lab Guide (TLG) is located at https://go.microsoft.com/fwlink/p/?LinkId=236358.

Tip

See Test Lab Guides for information on the location of other test lab guide files.

Step 2: Configure ORCA1

The procedures to complete the configuration of the offline root CA, named ORCA1, include:

• Install the Operating system

• Rename the computer

• Prepare the CAPolicy.inf for the standalone root CA

• Install the standalone root CA

• Configure the root CA settings

• Copy the root CA certificate and CRL to removable media

• Distribute the root CA via GPO

• Create an internal contoso.com DNS zone and www host record

To install the operating system on ORCA1

1. Do not connect this computer to a network.

2. Start the installation of Windows Server 2012 or Windows Server 2012 R2.

3. Follow the instructions to complete the installation, specifying Windows Server 2012 or Windows Server 2012 R2 (full installation) and a strong password for the local Administrator account. Sign in using the local Administrator account.

To rename the computer

1. Open Windows PowerShell®.

2. Type rename-computer orca1 and then press ENTER.

3. Type restart-computer and then press ENTER.

   After the computer restarts, sign in using the local Administrator account.

To prepare the CAPolicy.inf for the standalone root CA

1. Open Windows PowerShell, type notepad c:\Windows\CAPolicy.inf and press ENTER.

2. When prompted to create a new file, click Yes.

3. Enter the following as the contents of the file:

   [Version]
   Signature="$Windows NT$"
   [PolicyStatementExtension]
   Policies=InternalPolicy
   [InternalPolicy]
   OID= 1.2.3.4.1455.67.89.5
   Notice="Legal Policy Statement"
   URL=https://www.contoso.com/pki/cps.txt
   [Certsrv_Server]
   RenewalKeyLength=2048
   RenewalValidityPeriod=Years
   RenewalValidityPeriodUnits=20
   CRLPeriod=weeks
   CRLPeriodUnits=26
   CRLDeltaPeriod=Days
   CRLDeltaPeriodUnits=0
   LoadDefaultTemplates=0
   AlternateSignatureAlgorithm=1
   

   Warning

   
   Windows XP and Windows Server 2003 certificate clients do not support the Alternate Signature Algorithm. If you want these clients to be able to enroll for certificates, do not add the line AlternateSignatureAlgorithm=1 to the CAPolicy.inf. For more information, see Guidelines for Using Alternate Signature Formats.

   Note

   
   The OID shown in the example is the Microsoft OID. Individual organizations should obtain their own OIDs. For more information about OIDs, see Obtaining a Root OID from an ISO Name Registration Authority.

   Tip

   
   Setting the CRLDeltaPeriodUnits=0 in the CAPolicy.inf disables Delta CRL publishing, which is the appropriate setting for an offline Root CA.

4. Click Save As. Ensure the following:

   • File name is set to CAPolicy.inf

   • Save as type is set to All Files

   • Encoding is ANSI

5. When you are prompted to overwrite the file, click Yes.

   Ensure CAPolicy.inf file has appropriate settings

   Warning

   
   Be sure to save the CAPolicy.inf with the inf extension. If you do not specifically type .inf at the end of the file name and select the options as described, the file will be saved as a text file and will not be used during CA installation.

6. Close Notepad.

Important

In the CAPolicy.inf, you can see there is a line specifying the URL https://www.contoso.com/pki/cps.txt. The Internal Policy section of the CAPolicy.inf is just shown as an example of how you would specify the location of a certificate practice statement (CPS). To learn more about policy statements including CPS, see Creating Certificate Policies and Certificate Practice Statements (https://technet.microsoft.com/library/cc780454.aspx) and RFC 2527 (https://www.ietf.org/rfc/rfc2527.txt). For more information about CAPolicy.inf file syntax and purposes, see CA Policy.inf Syntax (https://technet.microsoft.com/library/cc728279.aspx).

To install the standalone root CA

1. In Server Manager, click Manage, and then click Add Roles and Features.

2. On the Before you begin screen, click Next.

3. On the Select installation type screen, ensure the default selection of Role-based or feature-based installation is selected. Click Next.

4. On the Select destination server screen, ensure that orca1 is selected and then click Next.

5. On the Select server roles screen, select the Active Directory Certificate Services role.

6. When prompted to install Remote Server Administration Tools click Add Features. Click Next.

7. On the Select features screen, click Next.

8. On the Active Directory Certificate Services screen, click Next.

9. On the Select role services screen, the Certification Authority role is selected by default. Click Next.

10. On the Confirm installation selections screen, verify the information and then click Install.

11. Wait for the installation to complete. The installation progress screen is displayed while the binary files for the CA are installed. When the binary file installation is complete, click the Configure Active Directory Certificate Services on the destination server link.

    Click Configure Active Directory Certificate Services on destination server

    Tip

    
    If you were to click Close before the installation completed, you could complete the configuration of the role service by through a link to complete the configuration in the notifications icon of Server Manager.

12. On the Credentials screen, you should see that the ORCA1\Administrator is displayed in the Credentials box. Click Next.

    Note

    
    When installing a Standalone CA, you must use an account that is a member of the local Administrators group.

13. On the Role Services screen, select Certification Authority. This is the only available selection when only the binary files for the certification authority role are installed on the server. Click Next.

14. The only selection available on the Setup Type screen is Standalone CA. This is because the account used to install is a member of the local Administrators group and the server is not a member of an Active Directory Domain Services (AD DS) domain. Click Next.

15. On the CA Type screen, Root CA is selected by default. Click Next.

16. On the Private Key screen, leave the default selection to Create a new private key selected. Click Next.

17. On the Cryptography for CA screen, ensure that the cryptographic provider is RSA#Microsoft Software Key Storage Provider, the key length is set to 2048 and the hash algorithm is set to SHA1 then click Next.

    Note

    
    Do not select the Allow administrator interaction when the private key is accessed by the CA checkbox. This setting is typically used with Hardware Security Modules (HSMs) and similar key protection devices prompt for additional information when the private key is accessed.

18. On the CA Name screen, in the Common name for this CA text box, type ContosoRootCA and then click Next.

19. On the Validity Period screen, enter 20 for the number of years for the certificate to be valid.

20. On the CA Database screen, leave the default locations for the database and database log files. Click Next.

21. On the Confirmation screen, click Configure.

22. The Progress screen is displayed during the configuration processing, then the Results screen appears. Click Close. If the Installation progress screen is still open, click Close on that screen as well.

Tip

The following Windows PowerShell commands would perform the same action as shown above Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools Install-AdcsCertificationAuthority –CAType StandaloneRootCA –CACommonName "ContosoRootCA" –KeyLength 2048 –HashAlgorithm SHA1 –CryptoProviderName "RSA#Microsoft Software Key Storage Provider"

To configure the root CA settings

1. In Server Manager, click Tools and then click Certification Authority.

2. In the Certification Authority console tree, expand ORCA1-ContosoRootCA. Right-click Revoked Certificates and then click Properties.

3. On the CRL Publishing Parameters tab, ensure that Publish Delta CRLs is cleared (not selected). Click OK.

4. In the Certification Authority console tree, right-click ORCA1-ContosoRootCA and then click Properties.

5. Click the Extensions tab. Ensure that Select extensions is set to CRL Distribution Point (CDP) and in the Specify locations from which users can obtain a certificate revocation list (CRL), review the default settings.

6. Change Select extension to Authority Information Access (AIA) and review the default settings. Click OK. If you are prompted to restart Active Directory Certificate Services, click No. You will restart the service after modifying the default paths in the next step.

7. From Windows PowerShell run the following commands:

   certutil -setreg CA\CRLPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%3%8.crl\n2:https://www.contoso.com/pki/%3%8.crl"

   certutil –setreg CA\CACertPublicationURLs "2:https://www.contoso.com/pki/%1_%3%4.crt"

   Certutil -setreg CA\CRLOverlapPeriodUnits 12

   Certutil -setreg CA\CRLOverlapPeriod "Hours"

   Certutil -setreg CA\ValidityPeriodUnits 10

   Certutil -setreg CA\ValidityPeriod "Years"

   certutil -setreg CA\DSConfigDN CN=Configuration,DC=corp,DC=contoso,DC=com

   restart-service certsvc

   certutil -crl

Note

The certutil commands above set the CDP and AIA paths respectively for the Root CA. The overlap period for CRLs is the amount of time at the end of a published CRLs lifetime that a client can use to obtain a new CRL before the old CRL is considered unusable, which is set for 12 hours. The default setting for this value is 10% of the CRL lifetime. The validity period settings are to define the number of days, weeks, months, or years that a certificate issued by the CA will be valid, which is set for 10 years in the commands above. The validity period for a certificate cannot be greater than the validity period of the CA that issued the certificate. The default value depends on the type of certificate. The default location of the CDP in also established for eventual use with Active Directory. The same configuration can be accomplished by using the following Windows PowerShell® and certutil commands: $crllist = Get-CACrlDistributionPoint; foreach ($crl in $crllist) {Remove-CACrlDistributionPoint $crl.uri -Force}; Add-CACRLDistributionPoint -Uri C:\Windows\System32\CertSrv\CertEnroll%3%8.crl -PublishToServer -Force Add-CACRLDistributionPoint -Uri https://www.contoso.com/pki/%3%8.crl -AddToCertificateCDP -Force $aialist = Get-CAAuthorityInformationAccess; foreach ($aia in $aialist) {Remove-CAAuthorityInformationAccess $aia.uri -Force}; Certutil -setreg CA\CRLOverlapPeriodUnits 12 Certutil -setreg CA\CRLOverlapPeriod "Hours" Certutil -setreg CA\ValidityPeriodUnits 10 Certutil -setreg CA\ValidityPeriod "Years" restart-service certsvc certutil -crl

To view the AIA and CDP, you can run the following commands: Get-CAAuthorityInformationAccess | format-list and Get-CACRLDistributionPoint | format-list. You can also return to the Extensions tab in certification authority properties dialog box and see the changes made to the AIA and CDP.

To copy the root CA certificate and CRL to removable media

1. From Windows PowerShell, run the command dir C:\Windows\system32\certsrv\certenroll\*.cr*, which displays the certificates and CRLs in the default certificate store.

2. Copy the CA certificate file and CRL to removable media. For example, if you were running commands to copy the certificate and CRL to a floppy disk drive (A:), you would run the following commands:

   1. copy C:\Windows\system32\certsrv\certenroll\*.cr* A:\

   2. dir A:\

   Tip

   
   Substitute the drive letter of your removable media for A: in the commands shown above. The removable media can be either physical or virtual, as discussed in Hardware and software requirements. Also, if you see an error that reads “The volume does not contain a recognized file system.” You may need to format the media. For example, if it is a floppy disk, you might need to type format a: and then press ENTER.

To distribute the root CA certificate

1. On APP1, sign in using the User1 account, which is a member of both Domain Admins and Enterprise Admins. Open Windows PowerShell as administrator. To do so, right-click the Windows PowerShell icon and then click Run as administrator. When prompted by User Account Control, click Yes.

2. Insert the removable media containing the offline root CA certificate into APP1.

3. From Windows PowerShell change to the removable media drive using the cd command (as in run cd a:\ to change to the root of drive A).

4. From the Windows PowerShell on the removable media drive, run the following commands: certutil –dspublish –f orca1_ContosoRootCA.crt RootCA certutil –addstore –f root orca1_ContosoRootCA.crt certutil –addstore –f root ContosoRootCA.crl

Note

The first command places the root CA public certificate into the Configuration container of Active Directory. Doing so allows domain client computers to automatically trust the root CA certificate and there is no additional need to distribute that certificate in Group Policy. The second and third commands place the root CA certificate and CRL into the local store of APP1. This provides APP1 immediate trust of root CA public certificate and knowledge of the root CA CRL. APP1 could obtain the certificate from Group Policy and the CRL from the CDP location, but publishing these two items to the local store on APP1 is helpful to speed the configuration of APP1 as a subordinate CA.

The public certificates, certificate revocation lists, and certificate practices statement are all to be placed in the location https://www.contoso.com/pki. Internal client computers will not be able to resolve this computer name to the internal web site (APP1) unless an appropriate DNS entry is placed on the DNS server.

To create a contoso.com DNS zone and www host record

1. On DC1, open the DNS console. In Server Manager, click Tools, then click DNS.

2. In the DNS console, expand the following in the console tree: DC1, Forward Lookup Zones.

3. Right-click the Forward Lookup Zones and then click New Zone.

4. On the Welcome to the New Zone Wizard screen, click Next.

5. By default you will see that Primary zone is selected and that the zone will be stored in Active Directory. To accept these defaults, click Next.

6. Leave the default setting and then click Next.

7. On Zone name screen, type contoso.com and then click Next.

8. On the Dynamic Update screen, leave the default setting and then click Next.

9. On the Completing the New Zone Wizard, click Finish.

10. In the console tree of the DNS console, right-click the contoso.com zone and then click New Host (A or AAAA).

    Tip

    
    You may have to click the corp.contoso.com zone one time before you are able to access the right-click options.

11. In Name (uses parent domain if left blank), type www.

12. In IP Address, type 10.0.0.3. This zone and record will direct communications from internal clients for www.contoso.com to the address of APP1. Click Add Host.

13. Click OK to confirm that the record was created. Click Done.

14. Close the DNS console

Step 3: Configure APP1 to distribute certificates and CRLs

In the extensions of the root CA, it was stated that the CRL from the root CA would be available via https://www.contoso.com/pki. Currently, there is not a PKI virtual directory on APP1, so one must be created. In a production environment, you would typically separate the issuing CA role from the role of hosting the AIA and CDP. However, this lab combines both in order to reduce the number of resources needed to complete the lab.

Tip

If a CA cannot find the CRLs of its parent CA, the AD DS service (certsvc) will fail to start on the subordinate CA. This can only be remedied by resolving the CRL distribution issue (recommended) or by changing the CA log level from the default of 3 to level 2. For more information on CA log levels, see Microsoft Knowledge Base article 305018 https://support.microsoft.com/kb/305018.

To configure APP1 to distribute certificates and CRLs

1. Ensure that you sign in using the User1 account. Run Windows PowerShell as Administrator and then run the following commands:

   New-item -path c:\pki –type directory

   write-output "Example CPS statement" | out-file c:\pki\cps.txt

   new-smbshare -name pki c:\pki -FullAccess SYSTEM,"CORP\Domain Admins" -ChangeAccess "CORP\Cert Publishers"

2. Open the IIS console. In Server Manager, click Tools, and then click Internet Information Services (IIS) Manager.

3. In the Internet Information Services (IIS) Manager console tree, expand APP1. If you are invited to get started with Microsoft Web Platform, click Cancel.

4. Expand Sites and then right-click the Default Web Site and then click Add Virtual Directory.

5. In Alias, type pki and then in physical path type C:\pki, then click OK.

6. Enable Anonymous access to the pki virtual directory. To do so:

   1. In the Connections pane, expand Default Web Site, ensure that pki is selected.

   2. On pki Home click Authentication.

   3. In the Actions pane, click Edit Permissions.

   4. On the Security tab, click Edit

   5. On the Permissions for pki dialog box, click Add.

   6. On Select Users, Computers, Service Accounts, or Groups, type Cert Publishers and then click Check Names.

   7. On Select Users, Computers, Service Accounts, or Groups, click Object Types.

   8. On Object Types, select Service Accounts and then click OK.

   9. On Select Users, Computers, Service Accounts, or Groups, click Locations.

   10. On Locations, click APP1 and then click OK.

   11. On Select Users, Computers, Service Accounts, or Groups after Cert Publishers, type ;IIS AppPool\DefaultAppPool and then click Check Names. Click OK.

       Note

       
       These steps have granted the IIS default application pool Read & execute, List folder contents, and Read permissions. IIS uses the default application pool to allow anonymous access. This will allow users to check the AIA and CDP hosted on IIS.

   12. On Permissions for pki select Cert Publishers (CORP\Cert Publishers). Under Permissions for Cert Publishers, select the Modify checkbox in the Allow column and then click OK twice.

       Note

       
       Granting modify permissions to the pki folder to Cert Publishers allows for the publishing of certificates and CRLs by CAs in the enterprise to the folder.

7. In the pki Home pane, double-click Request Filtering.

8. The File Name Extensions tab is selected by default in the Request Filtering pane. In the Actions pane, click Edit Feature Settings.

9. In Edit Request Filtering Settings, select Allow double escaping and then click OK. Close Internet Information Services (IIS) Manager.

   Note

   
   Allowing double escaping is needed if you are publishing Delta CRLs to IIS because the Delta CRL file contains a + symbol. For more information, see Microsoft Knowledge Base article 942076 (https://support.microsoft.com/kb/942076).

10. Run Windows PowerShell as an administrator. From Windows PowerShell, run the command iisreset

Step 4: Configure APP1 as an Enterprise Subordinate CA

The steps to configure APP1 as an Enterprise Subordinate CA include the following procedures:

1. Configure the CAPolicy.inf

2. Install the enterprise subordinate CA role

3. To configure the AIA and CDP

To configure the CAPolicy.inf

1. On APP1, as User1, open Windows PowerShell as Administrator and then type notepad c:\Windows\CAPolicy.inf and press ENTER.

2. When asked if you want to create the file. Click Yes.

3. Use the following information for the enterprise subordinate CA CAPolicy.inf file.

   [Version]
   Signature="$Windows NT$"
   [PolicyStatementExtension]
   Policies=InternalPolicy
   [InternalPolicy]
   OID= 1.2.3.4.1455.67.89.5
   Notice="Legal Policy Statement"
   URL=https://www.contoso.com/pki/cps.txt
   [Certsrv_Server]
   RenewalKeyLength=2048
   RenewalValidityPeriod=Years
   RenewalValidityPeriodUnits=5
   LoadDefaultTemplates=0
   AlternateSignatureAlgorithm=1
   

   Warning

   
   Windows XP and Windows Server 2003 certificate clients do not support the Alternate Signature Algorithm. If you want these clients to be able to enroll for certificates, do not add the line AlternateSignatureAlgorithm=1 to the CAPolicy.inf. For more information, see Guidelines for Using Alternate Signature Formats.

4. Click File, Save As and ensure that you are saving an ANSI file named CAPolicy.inf in the C:\Windows folder. You will have to switch the Save as type to All Files in order to get the inf extension instead of txt extension. When prompted to replace CAPolicy.inf, click Yes.

5. Close Notepad.

To install the enterprise subordinate CA role

1. On APP1, as User1, run Windows PowerShell as Administrator, and then run the following command gpupdate /force. This action ensures that the GPO for the trusted root certification authority is applied to APP1.

2. In Server Manager, click Manage, and then click Add Roles and Features.

3. On the Before you begin, click Next.

4. On the Select installation type screen, ensure the default selection of Role or Feature Based Install is selected. Click Next.

5. On the Select destination server screen, ensure that APP1 is selected and then click Next.

6. On the Select server roles screen, select the Active Directory Certificate Services role.

7. When prompted to install Remote Server Administration Tools click Add Features. Click Next.

8. On the Select features screen, click Next.

9. On the Active Directory Certificate Services screen, click Next.

10. On the Select role services screen, ensure Certification Authority is selected and then click Next.

11. On the Confirm installation selections screen, verify the information and then click Install.

12. Wait for the installation to complete. The installation progress screen is displayed while the binary files for the CA are installed. When the binary file installation is complete, click the Configure Active Directory Certificate Services on the destination server link.

    Tip

    
    If you clicked Close before the installation completed, you could complete the configuration of the role service by through a link to complete the configuration in the notifications icon of Server Manager.

13. On the Credentials screen, the credentials for User1 appear. Click Next.

14. On the Role Services screen, select Certification Authority.

15. On the Setup Type screen, ensure that Enterprise CA is selected and then click Next.

    Note

    
    If the computer is a domain member and the credentials supplied previously were for an account that is a member of the Enterprise Admins group, you can select Enterprise CA or Standalone CA. If the computer is not a domain member or credentials were entered for an account that is not a member of Enterprise Admins, then only the Standalone CA selection is available.

16. On the CA Type screen, select Subordinate CA to install an Enterprise Subordinate CA. Click Next.

17. On the Private Key screen, ensure the Create a new private key option is selected and then click Next.

18. The Cryptography for CA screen, ensure that the cryptographic provider is RSA#Microsoft Software Key Storage Provider, key length is 2048, and the hash algorithm is set to SHA1. Click Next.

19. On the CA Name screen, in Common name for this CA, type IssuingCA-APP1. You will see that the distinguished name changes to CN=IssuingCA-APP1,DC=corp,DC=contoso,DC=com. Click Next.

20. On the Certificate Request screen, notice that Save a certificate request to file on the target machine is selected. This is the correct option because we are using an offline parent CA (the root CA) in this configuration. Leave the default and click Next.

21. On the CA Database screen, leave the default database and log locations and then click Next.

22. On the Confirmation screen, click Configure.

23. On the Results screen, you see that you must take the certificate request to the ContosoRootCA in order to complete the configuration. Click Close

    Note

    
    The Windows PowerShell commands to perform the installation of the Enterprise Subordinate CA as shown in this section are: Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools Install-AdcsCertificationAuthority -CAType EnterpriseSubordinateCA -CACommonName "IssuingCA-APP1" -KeyLength 2048 -HashAlgorithm SHA1 -CryptoProviderName "RSA#Microsoft Software Key Storage Provider"

24. Copy the certificate request to removable media to take to the ORCA1. For example, if you wanted to copy the file from the C:\ drive to a floppy drive with drive letter A:\, then you could run the following command from Windows PowerShell: copy C:\*.req A:\

25. Take the removable media with the certificate request file to the ORCA1. Sign on to the root CA using an account that is a member of local Administrators.

26. On ORCA1, from Windows PowerShell, submit the request using the following command (assuming that A:\ is your removable media drive letter): certreq -submit A:\APP1.corp.contoso.com_IssuingCA-APP1.req

    Note

    
    If the removable media has a different drive letter, then substitute that letter for A:.

27. On Certification Authority List, ensure that ContosoRootCA (Kerberos) CA is selected and then click OK. You see that the certificate request is pending and the request identification number. Ensure that you note the request ID number.

28. On ORCA1, you must approve the request. You can do this using Server Manager or by using certutil from the command line.

    • To use Server Manager, click Tools, and then click Certification Authority. Expand the ContosoRootCA object and then click Pending Requests.

      Right-click the Request ID that corresponds with the one you saw when you submitted the request in the previous step. Click All Tasks and then click Issue.

      Click Issued Certificates and see the issued certificate in the Details pane.

    • To use certutil, enter Certutil resubmit <RequestId>, replace the actual request number for <RequestId>. For example, if the Request ID is 2, you would enter Certutil resubmit 2

29. From the command prompt on ORCA1, retrieve the issued certificate by running the command certreq –retrieve <RequestId> <drive>:\APP1.corp.contoso.com_corp-APP1-CA.crt. Substitute the actual number of the request when it was submitted for <RequestId> and the actual drive letter of the removable media for <drive>. For example, if the request ID where 2 and the removable media was drive A, then the request would be: certreq –retrieve 2 a:\APP1.corp.contoso.com_IssuingCA-APP1.crt. When prompted to select the CA, ensure that ORCA1-ContosoRootCA is selected and then click OK.

30. On ORCA1, run the command dir A:\ (assuming that A is the removable media drive letter, if not substitute the correct drive letter for A). You see that ContosoRootCA.crl, orca1_ORCA1-ContosoRootCA.crt, and APP1.corp.contoso.com_corp-APP1-CA.crt are now saved to the removable media. Move the removable media to APP1.

31. On APP1, in Windows PowerShell, run the following commands to copy the root CA certificate and CRL to the PKI folder (assuming that A: is the removable media drive, if not substitute the correct drive letter), install the subordinate CA certificate, start the certificate service, and copy the subordinate CA certificate and CRLs to the PKI folder:

    • copy a:\*.cr* c:\pki\

    • certutil –installcert a:\APP1.corp.contoso.com_corp-APP1-CA.crt

    • start-service certsvc

    • copy c:\Windows\system32\certsrv\certenroll\*.cr* c:\pki\

Tip

ORCA1 is no longer needed for this lab, so you can turn it off. To turn off a computer from Windows PowerShell, you can run the command stop-computer.

To configure the AIA and CDP Settings

1. On APP1, as User1, right-click Windows PowerShell, click Run as Administrator. Click Yes to confirm that you want to run Windows PowerShell as an Administrator.

2. From Windows PowerShell run the following commands:

   certutil -setreg CA\CRLPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%3%8.crl\n2:https://www.contoso.com/pki/%3%8.crl"

   certutil -setreg CA\CACertPublicationURLs "2:https://www.contoso.com/pki/%1_%3%4.crt\n1:file://\\App1.corp.contoso.com\pki\%1_%3%4.crt"

   Certutil -setreg CA\CRLPeriodUnits 2

   Certutil -setreg CA\CRLPeriod "Weeks"

   Certutil -setreg CA\CRLDeltaPeriodUnits 1

   Certutil -setreg CA\CRLDeltaPeriod "Days"

   Certutil -setreg CA\CRLOverlapPeriodUnits 12

   Certutil -setreg CA\CRLOverlapPeriod "Hours"

   Certutil -setreg CA\ValidityPeriodUnits 5

   Certutil -setreg CA\ValidityPeriod "Years"

   restart-service certsvc

   certutil -crl

Note

The same configuration can be accomplished using the following Windows PowerShell and certutil commands: $crllist = Get-CACrlDistributionPoint; foreach ($crl in $crllist) {Remove-CACrlDistributionPoint $crl.uri -Force}; Add-CACRLDistributionPoint -Uri C:\Windows\System32\CertSrv\CertEnroll%3%8%9.crl -PublishToServer -PublishDeltaToServer -Force Add-CACRLDistributionPoint -Uri https://www.contoso.com/pki/%3%8%9.crl -AddToCertificateCDP -Force Add-CACRLDistributionPoint -Uri file://\App1.corp.contoso.com\pki%3%8%9.crl -PublishToServer -PublishDeltaToServer -Force $aialist = Get-CAAuthorityInformationAccess; foreach ($aia in $aialist) {Remove-CAAuthorityInformationAccess $aia.uri -Force}; Add-CAAuthorityInformationAccess -AddToCertificateAia https://www.contoso.com/pki/%1_%3%4.crt -Force Certutil -setreg CA\CRLPeriodUnits 2 Certutil -setreg CA\CRLPeriod "Weeks" Certutil -setreg CA\CRLDeltaPeriodUnits 1 Certutil -setreg CA\CRLDeltaPeriod "Days" Certutil -setreg CA\CRLOverlapPeriodUnits 12 Certutil -setreg CA\CRLOverlapPeriod "Hours" Certutil -setreg CA\ValidityPeriodUnits 5 Certutil -setreg CA\ValidityPeriod "Years" restart-service certsvc certutil -crl

By sharing the pki folder and including the file path file://\\App1.corp.contoso.com\pki\%3%8%9.crl as a CDP extension, the CRLs and Delta CRLs will be copied to the share when you run the command certutil –crl. If you want to further restrict access to the share, you could create a separate group and include only the CAs that you want to authorize to publish to the share in that group. Then, share the pki folder only to that specific group and the SYSTEM account.

Important

A configuration item that is typically performed on production CAs that is not part of this lab is to enable Audit Object Access (https://technet.microsoft.com/library/cc776774.aspx) and then to enable all auditing events by running the following command: certutil -setreg CA\AuditFilter 127. After doing so, ensure that you regularly archive the Security Event Log and follow the Auditing Security Events Best Practices (https://technet.microsoft.com/library/cc778162.aspx).

Step 5: Configure computer certificate autoenrollment

There are two procedures in order to configure computer certificate autoenrollment:

1. Enable certificate autoenrollment through Group Policy

2. Configure a client and server authentication certificate template for autoenrollment

To enable certificate autoenrollment through Group Policy

1. On DC1, sign in as User1. In Server Manager, click Tools, and then click Group Policy Management.

2. On the console tree, expand the following objects: Forest: corp.contoso.com, Domains, corp.contoso.com.

   Note

   
   You might see a warning that any policies linked to the domain will affect all computers to which the policy is linked. If so, read it and then click OK.

3. In the console tree, right-click Default Domain Policy, and then click Edit.

4. In the console tree of the Group Policy Management Editor, under Computer Configuration, expand the following objects: Policies, Windows Settings, Security Settings, and then click Public Key Policies.

5. In the details pane, double-click Certificate Services Client - Auto-Enrollment. In Configuration Model, select Enabled.

6. Select Renew expired certificates, update pending certificates, and remove revoked certificates and Update certificates that use certificate templates. Click OK.

7. Close Group Policy Management Editor and Group Policy Management Console.

To configure a client server authentication certificate template for autoenrollment

1. On APP1, in the Certification Authority console pane, ensure that IssuingCA-APP1 is expanded.

2. Right-click Certificate Templates and then click Manage.

3. In the details pane, right-click Workstation Authentication and then click Duplicate Template.

4. Click the General tab, in Template display name, type Client-Server Authentication.

5. Click the Extensions tab, ensure Application Policies is selected, and then click Edit.

6. Click Add then click Server Authentication. Click OK twice.

7. On the Properties of New Template dialog, click the Security tab.

8. In Group or user names, click Domain Computers (CORP\Domain Computers).

9. In the Autoenroll row, select the Allow checkbox. This will cause all domain computers to automatically enroll for certificates using this template.

   Note

You would typically not assign a template both the Client Authentication and the Server Authentication enhanced key usage (EKU). Also, Server Authentication EKU are typically not configured for autoenrollment. This is done in this lab only for convenience and compatibility with other labs.

The computers also need Read permission for the template in order to enroll. However, this permission is already granted to the Authenticated Users group. All computer accounts in the domain are members of Authenticated Users, so they already have the permission to Read the template.

10. Click OK. Close the Certificate Templates Console.

11. Right-click Certificate Templates, click New, click Certificate Template to Issue.

12. In the Enable Certificate Templates dialog box, click Client-Server Authentication and then click OK. Close the Certification Authority console.

Step 6: Configuring SSL for APP1

To demonstrate how the certificates deployed through AD DS and AD CS can be used, you will secure the APP1 Web site using SSL and then connect to that secure site with CLIENT1.

Note

This part of the lab is done to demonstrate using a certificate to secure a Web site.

There are two procedures in this step:

1. Secure the APP1 Default Web Site

2. Connect to the secure web site

To secure the APP1 Default Web Site

1. On APP1, as User1, run Windows PowerShell as Administrator. Then, run the following commands:

   Gpupdate /force. Wait for the update of Group Policy to complete and then close the Command Prompt. This ensures that the autoenrollment certificate distributed through Group Policy is issued to APP1.

   cd cert:\LocalMachine\My

   dir | format-list

   You should see that you have two certificates. One was issued by ContosoRootCA, which is the APP1 CA certificate. The other certificate was issued by IssuingCA-APP1 and it can be used to secure the APP1 default web site.

2. Open the Internet Information Services (IIS) Manager console. To do so, in Server Manager, click Tools and then click Internet Information Services (IIS) Manager. In the contents pane, expand the following path APP1, Sites, and Default Web Site.

   Note

   
   If you see an Internet Information Services (IIS) Manager prompt asking if you want to get started with Microsoft Web Platform, click Cancel.

3. Click Default Web Site. In the Actions pane click Bindings.

4. In the Site Bindings dialog box, click Add.

5. In the Add Site Binding dialog box, in Type, select https.

6. Under SSL certificate, click Select.

7. In Select Certificate use the selection box to select the certificate that was issued by the IssuingCA-APP1 through the Group Policy. This will be a certificate with a long alphanumeric, as opposed one that reads IssuingCA-APP1. To verify you have the correct certificate, click View. Ensure the certificate you select shows that it was issued to APP1.corp.contoso.com and issued by IssuingCA-APP1. Once you have the correct certificate, click OK on the Certificate dialog box.

8. On Add Site Binding dialog box, click OK.

9. In the Site Bindings dialog box, click Close.

To connect to the secure web site

1. Connect CLIENT1 to the Corporate network.

2. Log on to CLIENT1 as User1.

3. Open Internet Explorer on CLIENT1.

4. In Internet Explorer, enter the address https://app1.corp.contoso.com and press ENTER. When you see the default IIS 8 web page, you are confirming that https and the SSL binding are working for the Default Web Site on APP1.

   Tip

   
   If instead you see that there is a problem with the certificate, then you probably selected an incorrect certificate in the previous procedure. You must select the certificate that was issued for the name APP1.corp.contoso.com. Also, it could be that Group Policy has not yet updated the Trusted Root Certification authorities. To ensure that the Group Policy updates are in place, open Explorer, then type cmd in the Explorer address bar. Then type gpupdate /force and press ENTER.

Important

The ORCA1 certificate revocation list (CRL) is valid for 26 weeks, which was configured using the CAPolicy.inf. The APP1 CRL must be updated weekly by default. To update the CRL, use the command: Certutil –crl, which publishes the CRL to the locations that you specified in the CA Properties Extensions tab.

Note

To comment on this content or ask questions about the information presented here, please use our Feedback guidance.

See Also

Windows Server Security Forum Active Directory Certificate Services (AD CS) Public Key Infrastructure (PKI) Frequently Asked Questions (FAQ) Windows PKI Documentation Reference and Library Windows PKI Blog