Carl Webster Accessibility Statement

Carl Webster is committed to facilitating the accessibility and usability of its website, carlwebster.com, for everyone. Carl Webster aims to comply with all applicable standards, including the World Wide Web Consortium’s Web Content Accessibility Guidelines 2.0 up to Level AA (WCAG 2.0 AA). Carl Webster is proud of the efforts that we have completed and that are in-progress to ensure that our website is accessible to everyone.

If you experience any difficulty in accessing any part of this website, please feel free to email us at info@carlwebster.com and we will work with you to provide the information or service you seek through an alternate communication method that is accessible for you consistent with applicable law (for example, through telephone support).

  • 15 Building Webster’s Lab V2 – Create a Microsoft Certificate Authority

    June 11, 2021

    Active Directory, PowerShell

    [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"}
    Figure 1
    Figure 1

    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.

    Figure 2
    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
    Figure 3
    Figure 3

    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
    Figure 4
    Figure 4

    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"
    Figure 5
    Figure 5

    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.

    Figure 6
    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

    Figure 7
    Figure 7

    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.

    Figure 8
    Figure 8

    Double-click Certificates as shown in Figure 9.

    Figure 9
    Figure 9

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

    Figure 10
    Figure 10

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

    Figure 11
    Figure 11

    Click OK, as shown in Figure 12.

    Figure 12
    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.

    Figure 13
    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.

    Figure 14
    Figure 14

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

    Figure 15
    Figure 15

    Click Next, as shown in Figure 16.

    Figure 16
    Figure 16

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

    Figure 17
    Figure 17

    Click Browse, as shown in Figure 18.

    Figure 18
    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.

    Figure 19
    Figure 19

    Click Next, as shown in Figure 20.

    Figure 20
    Figure 20

    Click Finish, as shown in Figure 21.

    Figure 21
    Figure 21

    Click OK, as shown in Figure 22.

    Figure 22
    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.

    Figure 23
    Figure 23

    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.

    Figure 24
    Figure 24

    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.

    Figure 25
    Figure 25
    Figure 26
    Figure 26

    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.

    Figure 27
    Figure 27

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

    Figure 28
    Figure 28

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

    Figure 29
    Figure 29

    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.

    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.

    Figure 30
    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
    Figure 31
    Figure 31
    Figure 32
    Figure 32

    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.

    Figure 33
    Figure 33
    Figure 34
    Figure 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.

    Figure 35
    Figure 35

    Request Handling Tab

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

    Figure 36
    Figure 36

    Cryptography Tab

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

    Figure 37
    Figure 37

    Key Attestation Tab

    There is nothing configurable, as shown in Figure 38.

    Figure 38
    Figure 38

    Superseded Templates Tab

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

    Figure 39
    Figure 39

    Extensions Tab

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

    Figure 40
    Figure 40

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

    Figure 41
    Figure 41

    Click OK, as shown in Figure 42.

    Figure 42
    Figure 42

    Security Tab

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

    Figure 43
    Figure 43

    Subject Name Tab

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

    Figure 44
    Figure 44

    Click OK, as shown in Figure 45.

    Figure 45
    Figure 45

    Server Tab

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

    Figure 46
    Figure 46

    Issuance Requirements Tab

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

    Figure 47
    Figure 47

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

    Figure 48
    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.

    Figure 49
    Figure 49

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

    Figure 50
    Figure 50

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

    Figure 51
    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.

    Figure 52
    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"
;-----------------------------------------------
    Figure 53
    Figure 53

    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.

    Figure 54
    Figure 54

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

    Figure 55
    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.

    Figure 56
    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.

    Figure 57
    Figure 57

    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.

    Figure 58
    Figure 58

    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.

    Figure 59
    Figure 59

    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.

    Figure 60
    Figure 60

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

    Figure 61
    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.

    Figure 62
    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.

    Figure 63
    Figure 63

    Click Next, as shown in Figure 64.

    Figure 64
    Figure 64

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

    Figure 65
    Figure 65

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

    Figure 66
    Figure 66

    Click Finish, as shown in Figure 67.

    Figure 67
    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.

    Figure 68
    Figure 68

    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







    About Carl Webster

    Carl Webster is an independent consultant specializing in Citrix, Active Directory, and technical documentation. Carl (aka “Webster”) serves the broader Citrix community by writing articles (see CarlWebster.com) and by being the most active person in the Citrix Zone on Experts Exchange. Webster has a long history in the IT industry beginning with mainframes in 1977, PCs and application development in 1986, and network engineering in 2001. He has worked with Citrix products since 1990 with the premiere of their first product – the MULTIUSER OS/2.

    View all posts by Carl Webster →

    Comments are closed.