[Updated 8-Nov-2021]

With the Server 2019 VM built for the certificate authority, the next step is to create the Certificate Authority (CA).  To make sure you understand what I cover in this article, you should understand a few terms. Microsoft provides a document that explains all the terms used in a Microsoft CA. You should take a few minutes to review that document.

Before we begin, I want to thank my friend and mentor, Michael B. Smith, who helped with this article and answered my numerous emails and questions. Michael helped make sure the information in this article was correct.

We perform the following steps in this article.

1. Join the CA server to the domain
2. Install and configure the CA
3. Create Files for Group Policy
4. Create a Server Certificate Template
5. Back up the CA to get a .p12 file

Item 5 was added 11-Jun-2021 after working on the IGEL Management Server article

Joining the Domain

The first thing we need to do is join our CA server to the domain.

From Part 14, I place all my Microsoft infrastructure servers in a specific OU.

Lab

Infrastructure

Microsoft

Open a PowerShell session and type in the following from one of the domain controllers, as shown in Figure 1.

Get-ADOrganizationalUnit -filter {Name -eq "Microsoft"}

Copy the DistinguishedName property to the clipboard.

We use PowerShell to install and configure the CA.

Use mstsc to remote into the VM that is our CA.

Exit Server Manager and start an elevated PowerShell session, as shown in Figure 2.

Copy and paste the following into the elevated PowerShell session and press Enter. The process took less than the blink of an eye to happen, which is why there is no screenshot.

Remember to set the values you need.

Note: Lines may wrap

#Join the computer to the domain

add-computer -Credential LabADDomain\Administrator `
-DomainName "LabADDomain.com" `
-OUPath "OU=Microsoft,OU=Infrastructure,OU=Lab,DC=LabADDomain,DC=com" `
-Force `
-Restart

#server reboots

After the VM restarts, log in using the domain’s Administrator account and password.

Start an elevated PowerShell session.

We start by installing the necessary Roles and Features.

• Active Directory Certificate Services
  • Certification Authority
  • Certification Authority Web Enrollment
• Web Server (IIS)
  • Web Server
    • Common HTTP Features
      • Default Document
      • Directory Browsing
      • HTTP Errors
      • Static Content
      • HTTP Redirection
    • Health and Diagnostics
      • HTTP Logging
      • Logging Tools
      • Request Monitor
      • Tracing
    • Performance
      • Static Content Compression
    • Security
      • Request Filtering
      • Windows Authentication
    • Application Development
      • ASP
      • ISAPI Extensions
    • Management Tools
      • IIS Management Console
      • IIS 6 Management Compatibility
        • IIS 6 Metabase Compatibility
      • Remote Server Administration Tools
        • Role Administration Tools
        • Active Directory Certificate Services Tools
          • Certification Authority Management Tools
        • Telnet Client

Install and Configure the CA

Copy and paste the following into the elevated PowerShell session and press Enter, as shown in Figure 3.

#setup new CA

Install-WindowsFeature ADCS-Cert-Authority, Telnet-Client, ADCS-Web-Enrollment -IncludeManagementTools

The configuration for the CA is:

• The validity period is 10 years (you can make this 20 years or longer. I joke to the IT admin to make it past their retirement year, so it is someone else’s problem later.)
• The CA’s name is LabDomain CA Root
• The certificate key length is 2048 characters
• Use SHA256
• Use Web Enrollment

Copy and paste the following into the elevated PowerShell session and press Enter, as shown in Figure 4.

Install-AdcsCertificationAuthority `
-ValidityPeriod Years `
-ValidityPeriodUnits 10 `
-CACommonName "LabDomain CA Root" `
-CAType EnterpriseRootCA `
-KeyLength 2048 `
-HashAlgorithmName SHA256 `
-Force

Install-AdcsWebEnrollment -Force

By default, the lifetime of a certificate that an  Enterprise CA issues is two years. We need to update our CA to handle the ten-year validity period. I am using the information from the Microsoft article Change the expiration date of certificates that Certificate Authority issues.

From the elevated PowerShell session, enter the following, as shown in Figure 5.

New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\LabDomain CA Root" `
-Name 'ValidityPeriodUnits' `
-Value 10 `
-PropertyType DWORD `
-Force

Stop-Service -Name "certsvc"
Start-Service -Name "certsvc"

You can verify the update using the registry editor. Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CAname>, and look at the ValidityPeriodUnits key, as shown in Figure 6.

Create Files for Group Policy

We need to gather the CA’s Root and Intermediate certificate files for use in the group policy we create in the following article.

From the elevated PowerShell session, enter the following, as shown in Figure 7.

md c:\CACertFiles

In the elevated PowerShell session, type in mmc and press Enter.

Either Click File, click Add/Remove Snap-in…, or press Ctrl+M (my preference), as shown in Figure 8.

Double-click Certificates as shown in Figure 9.

Select Computer account and click Next, as shown in Figure 10.

Select Local computer and click Finish, as shown in Figure 11.

Click OK, as shown in Figure 12.

The next step is to export the files we need for the group policy.

Expand Certificates and Trusted Root Certification Authorities and Intermediate Certification Authorities, as shown in Figure 13.

Under Intermediate Certification Authorities, click on Certificates, and in the right pane, click on <CAname> (for me, that is LabDomain CA Root), as shown in Figure 14.

Right-click <CAname>, click All Tasks and click Export…, as shown in Figure 15.

Click Next, as shown in Figure 16.

Click DER encoded binary X.509 (.CER) and click Next, as shown in Figure 17.

Click Browse, as shown in Figure 18.

Browse to the folder created earlier in Figure 7, as shown in Figure 19, and give the file a meaningful name. Click Save when complete.

Click Next, as shown in Figure 20.

Click Finish, as shown in Figure 21.

Click OK, as shown in Figure 22.

Under Trusted Root Certification Authorities, click on Certificates, and in the right pane, click on <CAname> (for me, that is LabDomain CA Root), as shown in Figure 23.

Note: You see two domain root certificates with the same name. They are identical, and it doesn’t matter which one you use for the export.

Repeat the export process for the domain’s root certificate. When completed, you have two .cer files, as shown in Figure 24. We use these two files in the following article.

Exit the MMC console. You may save the console if you want. I save it to my server’s desktop.

On the domain controllers, repeat the steps shown in Figures 8 through 12 to open the Certificates MMC snap-in. Expand Certificates and Trusted Root Certification Authorities and Intermediate Certification Authorities, as shown in Figure 13.

Notice that the DCs already have the CA’s Root and Intermediate certificates installed with no Group Policy or extra work, as shown in Figures 25 and 26 from LabDC1.

Leave the MMC console opened on both DCs. The console is used later in this article.

Create a Server Certificate Template

A certificate template defines the CA’s policies and rules when a request for a certificate is received. You use a custom certificate template to customize the template’s options to a specific need.

Open the Certification Authority console.

Click the Start button, expand Windows Administrative Tools, and click Certification Authority, as shown in Figure 27.

Expand <CAname>, right-click Certificate Templates, and click Manage, as shown in Figure 28.

Microsoft supplies 33 Certificate Templates,  as shown in Figure 29 in the middle pane.

For this article series and this lab, we are only concerned with the Computer template.

If you would like to use Microsoft CA to generate certificates for use with vCenter and ESXi hosts, there are several excellent articles to guide you in that process.

• SSL Certificate Replacement – Hybrid Mode (my personal favorite)
• Obtaining vSphere certificates from a Microsoft Certificate Authority
• How to replace default vCenter VMCA certificate with Microsoft CA signed certificate
• Creating a Microsoft Certificate Authority Template for SSL certificate creation in vSphere 6.x/7.x

We can’t edit a Microsoft-supplied template; we first make a copy of the template.

Create the template

Right-click the Computer template and click Duplicate Template, as shown in Figure 30.

We go through every tab.

Compatibility Tab

Because the CA uses SHA256, in Compatibility Settings, change the Certification Authority to Windows Server 2012 R2 and click OK on the popup, as shown in Figures 31 and 32.

Note: There is a known issue if you select anything higher than Windows Server 2012 R2. Please see Cannot select Windows Server 2016 CA-compatible certificate templates from Windows Server 2016 or later-based CAs or CEP servers.

Workaround

To work around this issue, follow these steps:

• Configure the compatibility settings of the certificate template as follows:
  • Certificate Authority: Windows Server 2012 R2
  • Certificate recipient: Windows 8.1 / Windows Server 2012 R2

For the Certificate recipient, select the option that matches the lowest client operating system in your environment. My lab servers are all Windows Server 2019, and all clients are Windows 10, but as stated in the Known Issue mentioned above, select Windows 8.1 / Windows Server 2012 R2 from the dropdown list and click OK on the popup shown in Figures 33 and 34.

General Tab

As shown in Figure 35, enter the following information:

• A meaningful Template display name,
• Make the Template name the same as the Template display name,
• Select a Validity period (must be less than the lifespan of the CA’s Root certificate),
• Leave the Renewal period alone, and
• Select Publish certificate in Active Directory

Note 1: From Michael B. Smith.

Usually, Microsoft’s Template Name is the Template Display Name without spaces (there are some notable exceptions).

Since most reports show the Template Display Name, but certificate requests use the Template Name, it makes good sense for the two names to be similar.

Note 2: You can’t select a Validity period longer than the CA’s Root certificate lifespan or a period past the CA’s Root certificate lifespan.

Note 3: Michael B. Smith says that you should always select Publish certificate in Active Directory for computer certificates.

Request Handling Tab

Select Allow private key to be exported and leave all other options at their default values, shown in Figure 36.

Cryptography Tab

Leave all options at their default values, as shown in Figure 37.

Key Attestation Tab

There is nothing configurable, as shown in Figure 38.

Superseded Templates Tab

There is nothing to configure, as shown in Figure 39.

Extensions Tab

Click Application Policies and click Edit…, as shown in Figure 40.

Click Client Authentication and click Remove, as shown in Figure 41.

Click OK, as shown in Figure 42.

Security Tab

There is nothing to configure, as shown in Figure 43.

Subject Name Tab

Select Supply in the request, as shown in Figure 44.

Click OK, as shown in Figure 45.

Server Tab

Verify that neither option is selected, as shown in Figure 46.

Issuance Requirements Tab

Verify that neither option is selected, as shown in Figure 47.

Finally, click OK, and the new Server Template template is created, as shown in Figure 48.

Exit the Certificate Templates Console.

Configure the CA to Issue the New Template

In the Certification Authority console, right-click Certificate Templates, click New, and click Certificate Template to Issue, as shown in Figure 49.

Click on the new template and click OK, as shown in Figure 50.

The new template now shows in the list of published templates, as shown in Figure 51.

Using the New Certificate Template to Create a Server Certificate

Requesting a computer certificate from the new template is done via the command line.

On both DCs, create a folder on the C drive named CertFiles, as shown in Figure 52.

On the first DC, save the following to a file name c:\CertFiles\computer-request.inf, as shown in Figure 53.

I want to thank Michael B. Smith for creating this INF file for me.

Use the data needed for your environment.

LabDC1 = the name of your domain controller
LabADDomain.com = your domain name
"LabCA\LabDomain CA Root" = the name of your CA server and the name of your CA.

;----------------- computer-request.inf -----------------
; LabDC1.LabADDomain.com
;
; certreq -new computer-request.inf computer-request.req
; certreq -submit -config "LabCA\LabDomain CA Root" computer-request.req computer-request.cer
; certreq -accept -config "LabCA\LabDomain CA Root" computer-request.cer
;

[Version]
Signature="$Windows NT$"

[NewRequest]
Subject = "CN=LabDC1.LabADDomain.com" ; replace with the FQDN of the DC
FriendlyName = "Computer (Machine) for LabDC1.LabADDomain.com"
KeyLength = 2048
; Can be 1024, 2048, 4096, 8192, or 16384.
; Larger key sizes are more secure but have a greater impact on performance.
KeySpec = 1                     ; AT_KEYEXCHANGE
Exportable = TRUE               ; private-key is exportable
MachineKeySet = TRUE            ; goes in machine store instead of user's personal store
SMIME = False                   ; cannot be used for signing S/MIME messages
PrivateKeyArchive = FALSE
HashAlgorithm = sha256          ; "certutil -oid 1 | findstr pwszName" -- gives a list (including sha1)
UserProtected = FALSE
UseExistingKeySet = FALSE       ; we are not renewing a key that already exists
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12               ; for ProviderName and ProviderType, see "certutil -csplist"
RequestType = PKCS10            ; if empty or set to "CERT" then a self-signed cert is created
KeyUsage = 0xa0                 ; 0xa0 - CERT_DIGITAL_SIGNATURE_KEY_USAGE + CERT_KEY_ENCIPHERMENT_KEY_USAGE

[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1 ; this is for Server Authentication - PKIX_KP_SERVER_AUTH

[Extensions]
; Note: 2.5.29.17 is the OID for a SAN extension.

2.5.29.17 = "{text}"
_continue_ = "dns=LabDC1.LabADDomain.com"

[RequestAttributes]
CertificateTemplate = "Server Template"
;-----------------------------------------------

On the first DC, open an elevated command prompt. I expanded the command prompt window size vertically to ensure I had visual space to capture all the output for screenshots.

Click the Start button, expand Windows System, right-click Command Prompt, click More, and click Run as administrator, as shown in Figure 54.

Type in cd c:\CertFiles and press Enter, as shown in Figure 55.

The three commands we need to run are at the top of the computer-request.inf file.

Type in notepad computer-request.inf and press Enter, as shown in Figure 56.

Copy the line certreq -new computer-request.inf computer-request.req, paste it in the elevated command prompt, and press Enter, as shown in Figure 57, along with the command results.

Copy the line certreq -submit -config “LabCA\LabDomain CA Root” computer-request.req computer-request.cer, paste it in the elevated command prompt, and press Enter, as shown in Figure 58, along with the command results.

Note: If you get a warning like the following, you can ignore the warning. The warning tells you that the certificate request validity period is past the lifetime of the CA’s root certificate lifespan.

Certificate retrieved(Issued)Issued The certificate validity period will be shorter than the Server Template Certificate Template specifies because the template validity period is longer than the maximum certificate validity period allowed by the CA.  Consider renewing the CA certificate, reducing the template validity period, or increasing the registry validity period.

Copy the line certreq -accept -config “LabCA\LabDomain CA Root” computer-request.cer, paste it in the elevated command prompt, and press Enter, as shown in Figure 59, along with the command results.

Testing the New Certificate

Let’s verify that the new certificate works.

In the command prompt window, type in ldp.exe and press Enter.

Click Connection and click Connect, as shown in Figure 60.

For Server, type the FQDN of the DC, type 636 for Port, and click OK, as shown in Figure 61.

You should see ldaps:// followed by information for the DC, a ldap_open using the secure port of 636, and DN: (RootDSE), as shown in Figure 62.

Repeat the process shown in Figures 52 through 62 for the other DC. Remember to change the DC name in the computer-request.inf file.

Back-Up the Certificate Authority

After this article was published, I started work on the Create an IGEL Management Server article. I needed the CA’s root certificate and key pair for the IGEL UMS Console and IGEL’s Web App console. To get the required .p12 file, we backup the CA server.

First, create a folder, C:\CABackup, as the backup process requires an empty folder.

From the Certification Authority console, right-click the CA Root, click All Tasks, and click Back up CA… as shown in Figure 63.

Click Next, as shown in Figure 64.

Select Private key and CA certificate, type in C:\CABackup for the backup location, and click Next, as shown in Figure 65.

Enter and confirm a Password to protect the backup file and click Next, as shown in Figure 66.

Click Finish, as shown in Figure 67.

As shown in Figure 68, we now have a .p12 file.  That file contains the CA’s root certificate and key files. When an application wants the pair of files, .crt and .key, we can use this .p12 file.

If you wish, you can copy this file to the C:\CACertFiles folder to keep all files are in one place.

This file allows you to import the required key pair into the Universal Management Suite console if you use IGEL.

Exit all open consoles and windows.

Up next: Create Initial Group Policy Objects.

Landing page for the article series