Deploying Offline Root CA in Windows Server 2019 - cfloquetprojects/homelab GitHub Wiki
Introduction:
Certificate Authorities play a critical role in securing any enterprise infrastructure, namely through the use of encryption and verifying the identity of a certain party or individual through a trusted third party.
We will be deploying Active Directory Certificate Services onto a Windows Server Desktop 2019
box, which will function as our offline root certificate authority (CA).
This root certificate authority will be used to provide certificates to our domain-joined Subordinate Certificate Authority
, which will remain online and be used to issue certificates as they are requested.
Pre-Flight Check:
Installed Windows Server Desktop 2019 box with atleast 8gb memory, this is preferably a physical box that can be stored in a secure physical location, but since we are in a lab environment we are just running a VM with a virtual NIC that has a configured IP to receive updates, as well as to the initial exchange of certificates.
Be sure to set the proper hostnames of both your Subordinate CA
as well as your Root CA
, as these cannot be changed once ADCS has been installed on the server.
Retrieved all necessary updates (as well as automatic ones if needed), and keep in mind that our Root CA will not be joined to any domain, so any security policies like password-complexity enforcement that would normally be enforced via GPO should be applied locally manually.
If you are operating in a production environment, it's highly recommended that you use an external flash drive as a means of storing the Root CA VM (or better yet, and unused laptop), however we won't be covering these steps within the scope of today's lab.
Installing Active Directory Certificate Services (ADCS) on Windows Server Core 2019:
💣 Ensure that your Standalone Root CA is not and has not been joined to any domain, as we want to limit access to this host as much as possible, and keep it completely offline after initial installation & use.
Open notepad on your Standalone Root CA
and create your CAPolicy.inf
, using the template shown below as an example. The most important field to change here is the URL
, which is what you will be working with long term so make sure the name you choose is one that is canonically correct.
[Version]
Signature="$Windows NT$"
[PolicyStatementExtension]
Policies=InternalPolicy
[InternalPolicy]
OID= 1.2.3.4.1455.67.89.5
Notice="Legal Policy Statement"
URL=http://crl.domain.local/pki/cps.txt
[Certsrv_Server]
RenewalKeyLength=2048
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=20
CRLPeriod=weeks
CRLPeriodUnits=26
CRLDeltaPeriod=Days
CRLDeltaPeriodUnits=0
LoadDefaultTemplates=0
AlternateSignatureAlgorithm=0
Now that our CAPolicy.inf
has been set, we are able to add and configure the ADCS feature, be sure you change the "CACommonName" to what you'd like your RootCA to be named, probably just your hostname.
PS> Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools
PS> Install-AdcsCertificationAuthority –CAType StandaloneRootCA –CACommonName "LabRootCA" –KeyLength 4096 –HashAlgorithm SHA256 –CryptoProviderName "RSA#Microsoft Software Key Storage Provider"
Using the base url which you defined earlier, run the following commands to set the proper distribution point and avoid some tedious headache via the GUI menu in Server Manager.
💣 It may be tempting to employ the use of
HTTPS
here, but the reason we aren't is since it requires SSL and certificate validation. This insecure URL will only be used to download Certificate Practice Statements (CPS) as well as our Certificate Revocation List (CRL), and we will be able to configure SSL for web enrollment later on in a lab further down the road.
$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 http://crl.lab.local/pki/%3%8.crl -AddToCertificateCDP -Force
$aialist = Get-CAAuthorityInformationAccess; foreach ($aia in $aialist) {Remove-CAAuthorityInformationAccess $aia.uri -Force};
Now we are able to use the certutil
combined with the -setreg
flag to configure the overlap and validity period of our Root CA, which can be set according to your personal or wider organizations' needs:
PS> certutil -setreg CA\CRLOverlapPeriodUnits 12
PS> certutil -setreg CA\CRLOverlapPeriod "Hours"
PS> certutil -setreg CA\ValidityPeriodUnits 10
PS> certutil -setreg CA\ValidityPeriod "Years"
PS> certutil -setreg CA\AuditFilter 127
PS> restart-service certsvc
PS> certutil -crl
We should now be able to verify that exactly two CRL distribution points have been published using the following command in powershell:
PS> Get-CACRLDistributionPoint | format-list
Within File Explorer, navigate to C:\Windows\System32\CertSrv\CertEnroll
, where there should be two files created by our Certificate Authority
, one being our Certificate Revocation List (CRL) and the other being the Security Certificate. Both of these files need to be copied over to our our domain-joined Subordinate CA
(preferably over a physical USB key, but whatever method you're capable of and comfortable with is fine).
Publishing Offline Root CA Certificate to Forest
Now that we have both the .crl
as well as the .crt
file from our Offline Root CA
copied over to our Subordinate CA
, open an elevated powershell prompt (as a logged in domain admin) and enter the following commands, using the appropriate filenames for the associated files:
What we are currently doing is publishing the
Offline Root CA
information to our Active Directory domain, allowing all domain-joined clients/computers to trust ourRoot CA
, and any offline or standalone computers can be included in this by directly importing the.crt
file into their trusted certificate store.
PS> certutil –dspublish –f rootca01_YellowstoneRootCA.crt RootCA
PS> certutil –addstore –f root rootca01_YellowstoneRootCA.crt
PS> certutil –addstore –f root YellowstoneRootCA.crl
In the next guide we will cover the installation of the Enterprise Subordinate CA
, which will be used as the issuing CA, and able to field and complete requests from domain-joined hosts via an IIS Web Server
.