Installing Enterprise Subordinate Certificate Authority on Windows Server 2019 - cfloquetprojects/homelab GitHub Wiki

This article assumes you have read and completed the steps outlined in the previous iteration of this series: Deploying an Offline Root CA on Windows Server 2019

We will continue on on journey to securing local network communications using certificates by installing and configuring a Subordinate Certificate Authority (CA), which will be used to issue certificates to requesting users and devices.

In this lab we will be installing Active Directory Certificate Services (ADCS) on Windows Server 2019, as well as the Internet Information Services (IIS) feature to allow us to field certificate requests from other hosts on the network.

Note: the hostnames I will be using for my root and subordinate CAs are respectively rootca01 and issuingca01 with my subordinate CA being joined to a fictional domain called yellowstone.local, be sure to replace these names with the corresponding hostnames/domain in your environment throughout the lab.

Installed Windows Server Desktop 2019 box with at least 8gb memory, and added proper DNS/network configuration, and make sure the host is joined to the proper domain.

Set your desired hostname of the Subordinate CA, as this should not be changed once ADCS has been installed on the server.

Ensure that you have a forward and reverse lookup A record within your local DNS server for both the CRL as well as the Subordinate CA host, which will be used for publishing your online CA info. For just lab purposes I kept it simple and stuck with just issuingca01 as the hostname and crl for our CRL.

💣 Failure to add both of these A Records will result in an unsuccessful deployment of PKI in your environment, so double check this step has been completed and is confirmed working prior to moving on.

As a best practice, lastly make sure you've retrieved all necessary operating system and security updates.

First thing we need to do is install IIS, which will be used to delegate Certificate Practice Statement (CPS) as well as Certificate Revocation List (CRL) information to requesting clients over http.

Log into your Subordinate CA as the local administrator and run the following command in powershell to install IIS, as well as the tools required to manage the web server:

PS> Install-WindowsFeature Web-WebServer -IncludeManagementTools

Now open an elevated PowerShell prompt, and create a new directory called pki within the C:\ directory using the following:

PS> new-item -path C:\pki -type directory

If you already have an existing CPS drafted that you would like to use, you can skip the next step and just copy and paste that into our C:\pki directory, however if you dont than you can just create a sample one using the following:

PS> write-output "This is a sample CPS." | out-file C:\pki\cps.txt
PS> new-smbshare -name pki C:\pki -FullAccess SYSTEM,"YELLOWSTONE\Domain Admins" -ChangeAccess "YELLOWSTONE\Cert Publishers"

Within Server Manager on your Subordinate CA open the IIS Manager and right click on Default Web Site to add a virtual directory, which is shown below:

Configure the virtual directory to map to the physical path of the directory we just created a few steps earlier, shown below:

Navigate to the pki folder under Default Web Site in IIS Manager and edit the permissions of the Authentication option on the middle menu, like below:

Under the Security tab choose to Edit the group permissions, and add the Cert Publishers group

Click OK and then make sure to check the box to allow Modify permissions for the Cert Publishers group.

Now that our Cert Publishers group is added, we need to add a user to have regular (read only) permissions for pki, which is the DefaultAppPool user within IIS AppPool, shown below:

💡 Note: You will need to change the Location of the User or Group search from your domain to the local computer, which is also shown below.

Confirm that the DefaultAppPool identity has been added to the permissions for pki, notably without modification privileges, finally click Apply:

It's a good time to quickly restart your IIS Webserver from the Default Web Site page, before checking that you've properly configured your C:\pki folder by viewing your CPS file through the web application.

The last leg of configuring IIS is just enabling double escaping, which if you are curious of the security implications of there is a solid Stack Overflow post about this configuration on IIS linked here, however since this is just in a lab/learning environment, we will proceed normally. Execute the following commands in an escalated command prompt to enable double escaping, before finally resetting our IIS Web Server.

💡 Remember that our Subordinate CA will act as our online issuing CA, which will field requests from other domain-joined hosts on our network, and be online 100% of the time. It's important that we monitor the integrity of this system later on, ideally using an advanced Security Incident and Event Management (SIEM) platform like Splunk, which will be discussed and potentially deployed for this purpose in later articles down the road.

Let's start the installation process in a manner similar to what we did to install ADCS on our Root CA, by configuring a CAPolicy.inf file and storing it on our C:\Windows folder to be used in the installation, shown below are the contents of the CAPolicy.inf file for our Subordinate CA:

[Version]
Signature="$Windows NT$"
[PolicyStatementExtension]
Policies=InternalPolicy
[InternalPolicy]
OID= 1.2.3.4.1455.67.89.5
Notice="Legal Policy Statement"
URL=http://crl.yellowstone.local/pki/cps.txt
[Certsrv_Server]
RenewalKeyLength=2048
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=10
LoadDefaultTemplates=0
AlternateSignatureAlgorithm=0

Now as a named domain-administrator open up a Powershell prompt and run the following commands to install ADCS as well as the required features to have automatic web-enrollment for domain-joined computers.

PS> Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools
PS> Add-WindowsFeature Adcs-web-enrollment
PS> Add-WindowsFeature Adcs-Enroll-Web-Svc

After the installation has completed, open up Server Manager and click on the notification for Post-deployment Configuration of Active Directory Certificate Services. This process can be done via graphic user interface (GUI) or via a simple powershell command (which I have also included below):

Powershell One-Liner (change parameters to fit your requirements and environment):

PS> Install-ADCSCertificationAuthority –Credential (Get-Credential) -CAType [EnterpriseCA] `
–CACommonName “ISSUINGCA01” –CADistinguishedNameSuffix “DC=yellowstone,DC=local” `
–CryptoProviderName “RSA#Microsoft Software Key Storage Provider” -KeyLength 2048 `
–HashAlgorithmName SHA256 –ValidityPeriod Years –ValidityPeriodUnits3 `
–DatabaseDirectory “C:\windows\system32\certLog” –LogDirectory “c:\windows\system32\CertLog” –Force

Graphical Installation using Windows Server Post-Deployment Configuration Wizard: Now that the installation has completed, we need to configure the ADCS feature before we can begin to use it, as I mentioned above, we will begin the process by going into Server Manager and clicking on the notification for Post-deployment Configuration of Active Directory Certificate Services.

Configure the credentials that will be used for this configuration, since this is our Enterprise Subordinate Certificate Authority, we will be using domain-admin credentials for this installation, rather than local ones.

Be sure to select the Certificate Authority as well as the Certificate Authority Web Enrollment role service so we are able to actually configure auto-enrollment for our domain clients down the road:

Our last lab covered the installation of the Standalone CA, so on this next step make sure that Enterprise CA is selected since that is what we are currently configuring.

In a similar manner as the previous step, choose the option opposite of the previous lab, in this case we are installing the Subordinate CA rather than the Root CA, which has already been installed, and will be used later in this lab to complete the request that we will create at the end of the installation.

Choose Create a new private key, if you do not already have one.

For security purposes it's important to choose modern hash algorithms and robust key lengths to avoid potential issues down the road, I have chosen a 2048 bit key length along with the SHA256 hash algorithm, respectively.

The next step allows us to configure the common and distinguished names of our CA, which ultimately relies on your own organizations name convention policy, but a fairly standardized one is the default one, which works as follows:

<DomainName>-<CAHostName>-CA

Specify the name of the .req file that we will send to our Root CA to be issued back to our Subordinate CA in the form of a .crt file.

Lastly, we will just need to confirm the settings that we configured throughout the process, and also close the dialog once the configuration for ADCS completed successfully.

💡 Note that the "configuration succeeded with warnings" is normal in these circumstances, and shouldn't present a serious issue within the context of this lab down the road. The reason it is warning us is that we still need to copy it to our parent Root CA, which is what we will do right now.

Now that we have our .req file, copy it to our Root CA host (preferably over a physical storage device like USB key) to create the certificate request on that server.

In order to create the new request, type the following command into an esclated powershell prompt on your Root CA server, which will use the certreq command to issue a new certificate request using the .req file you copied over from our Subordinate CA.

PS> certreq -submit .\path\to\issuingca01.domain.local_domain-ISSUINGCA01-CA-1.req

Within Server Manager, or MMC (open some GUI based way to manage your pending and issued certificate requests) on your Root CA server, navigate to Pending Requests and choose the one corresponding to the Request # that was given in response to your certreq command.

There should only be one on your Root CA, or however many subordinate/issuing CAs you have. Right click before going to All Tasks and hit Issue to approve the pending request.

Now that we have approved the request from our Subordinate CA, we can retrieve the certificate from the same escalated PowerShell prompt using the following command:

PS> certreq -retrieve 2 C:\issuingca01.yellowstone.local_issuingca.crt

This command will fetch the certificate of the corresponding RequestID: 2, and store it in the output directory of C:\

Now all that is left to do is copy this certificate back to our Subordinate CA and install it onto the server using the commands shown below:

PS> certutil –installcert C:\issuingca01.yellowstone.local_issuingca.crt
PS> start-service certsvc
PS> copy C:\Windows\system32\certsrv\certenroll\*.cr* c:\pki\

Within Server Manager on our Subordinate CA there should be a yellow notification/warning icon in the top right hand corner, which is prompting us to configure the installed Certificate Enrollment Web Service (CES).

Click on the configuration button, same as earlier in the lab, and choose to configure the Certificate Enrollment Web Service (CES), shown below:

Certificate Enrollment Web Service (CES), requires us to name a certificate authority that will be issuing the certificates requested through this IIS Web Server, which would be a different host if we were in a more complex or production environment.

These next two steps are critical for configuring the authentication mechanisms for getting access to the certificate request portal, which will be hosted on our Subordinate CA.

Ensure you use the Built-in Application Pool Identity option on the Service Account configuration step.

Hit Configure to confirm the configuration.

One of the last big steps in this process is setting up Certificate Distribution Points (CDPs) for our Enterprise Subordinate CA, which are used to specify file locations for certificates as well as locations on LDAP directory servers where the Subordinate CA publishes the CRL.

From a elevated powershell on your Subordinate CA, enter the following commands to configure the proper distribution points:

PS> $crllist = Get-CACrlDistributionPoint; foreach ($crl in $crllist) {Remove-CACrlDistributionPoint $crl.uri -Force};
PS> Add-CACRLDistributionPoint -Uri C:\Windows\System32\CertSrv\CertEnroll\%3%8%9.crl -PublishToServer -PublishDeltaToServer -Force
PS> Add-CACRLDistributionPoint -Uri http://crl.yellowstone.local/pki/%3%8%9.crl -AddToCertificateCDP -Force
PS> Add-CACRLDistributionPoint -Uri file://\\issuingca01.yellowstone.local\pki\%3%8%9.crl -PublishToServer -PublishDeltaToServer -Force
PS> $aialist = Get-CAAuthorityInformationAccess; foreach ($aia in $aialist) {Remove-CAAuthorityInformationAccess $aia.uri -Force};
PS> Add-CAAuthorityInformationAccess -AddToCertificateAia http://crl.yellowstone.local/pki/%1_%3%4.crt -Force

Now use the certutil command to set important parameters for our issued certificates like CRLPeriodUnits, CRLOverlapPeriodUnits, as well as ValidityPeriodUnits.

PS> certutil -setreg CA\CRLPeriodUnits 2
PS> certutil -setreg CA\CRLOverlapPeriodUnits 12
PS> certutil -setreg CA\ValidityPeriodUnits 5
PS> certutil -setreg CA\AuditFilter 127
PS> restart-service certsvc
PS> certutil -crl

It'd be a good idea to reboot the Subordinate CA after applying these changes for them to take effect.

Upon reboot, we should be able to navigate to the hostname of our Subordinate CA appended by the /certsrv directory and be asked to authenticate using domain credentials before being greeted with the following screen: