Certificate Authority - Root CA - Part 1

In order to authenticate via a Secure Environment, such as WPA2 and Computer Authentication, we’re going to configure an offline Root CA and an online Issuing CA.

Since this process is so overwhelming, I’m not going to cover it by means of screenshots.

However for other parts, I will.


How To Install Certificate Services and Deploy

Because of the length of this document, I’ve decided to keep it text wise. No screenshots as we go. On the bottom of this section, you’ll find some references you can see some examples. Please feel free to visit those links to better understand this Certificate Authority Setup.

Dependencies (Deprecated support on most ASA):

Cisco ASA 55xx LDAPS Function (port 636) only allows at max: SHA256 2048 Key Strength. This means, do not create a 4096 bits Root Certificate. For other purposes or if they don’t have these dependency’s, I strongly recommend you do use a 4096 Encryption Key.

This guide contains instructions for installing a standalone offline root CA, and an enterprise issuing CA (two-tier PKI hierarchy).

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.



A Windows 2016 Stand Alone server, not domain-joined.

This server will be used to deploy our offline Root CA.

Domain Member:

A Windows 2016 Server, domain member server as your Issuing CA.


Installing the standalone offline root CA:

To complete this installation we will be performing below steps:

Prepare the CAPolicy.inf for the standalone root CA

Install the standalone root CA

Configure the Root CA Authority Information Access and Certificate Distribution Point 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 prepare the CAPolicy.inf for the standalone root CA


User Accounts: compmgmt.msc

Set unguesable password for the Admin account and put on USB Disk/Virtual Floppy, not lastpass.


Rename Administrator / Guest Account

Computer Configuration > Windows Settings > Security Settings > Local Policies > Security options

Accounts: Rename Administrator/Guest Account

  1. Admin: CA_ADMIN

Interactive logon: Do not display last username:

  1. Clear last username at logon

Computer Configuration > Windows Settings > Security Settings > Local Policies > Audit Policy

CONFIGURE ALL FOR / success - failure

Computer configuration > Administrative Templates > Windows Components > AutoPlay Policies

Disable autoplay functions > All Drives

Right Mouse on Start Button > Run


And logon with altered Administrator Account Name.

Open Windows PowerShell

Type: notepad c:\Windows\CAPolicy.inf and press ENTER.

When prompted to create a new file, click Yes.Enter the following as the contents of the file:



Signature="$Windows NT$"





Notice="Legal Policy Statement"













# Very Important Note: for above CAPolicy.inf in regards to the ROOT CA.

# The Time of CRLPeriod will determine if you Issuing CA is valid to start. If set to 3 day's, and your RootCA is offline, you need to re-authenticate with the RootCA.

# Therefor, it's wise to set it at least to 1 year, or maybe in your case, or depending if the algorithm is cracked, to 5 years, and respond accordingly to information found online.


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.


In the above example there is an OID (object identifier) noted from Microsoft.

Individual organizations should obtain their own OIDs.

The preferred way to obtain a root object identifier (OID) is to request one from an International Standards Organization (ISO) Name Registration Authority. This is a one-time action; when you have obtained a root OID, the OID space it defines is yours and you can administer it yourself.

For this tutorial, we will be using Microsoft's OID.


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

For more information about about CAPolicy.inf file syntax and purposes, check out: http://technet.microsoft.com/library/cc728279.aspx

Save the file as C:\Windows\CAPolicy.inf, make sure to save it in the ANSI encoding format.


To install the standalone Root CA Role:

  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 RootCA 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.

The necessary files have now been installed for our Certificate Services Role.

Configuring Active Directory Certificates Services on the destination server.

  1. When the binary file installation is complete, click the Configure Active Directory Certificate Services on the destination server link.

2 On the Credentials screen, you should see that the RootCA\CA_ADMIN is displayed in the Credentialsbox. Click Next.

  1. 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.

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

  1. In the CA Type screen, Root CA is selected by default. Click Next.
  2. On the Private Key screen, leave the default selection to Create a new private key selected. Click Next.
  3. 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.

Do not select the Allow administrator interaction when the private key is accessed by the CAcheckbox. 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.

  1. On the CA Name screen, in the Common name for this CA text box, type MyRootCA and then clickNext.
  2. On the Validity Period screen, enter 20 for the number of years for the certificate to be valid.
  3. On the CA Database screen, leave the default locations for the database and database log files. Click Next.
  4. On the Confirmation screen, click Configure.
  5. 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.

Configuring Certificate Revocation Lists and Authority Information Access

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

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

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

In the Certification Authority console tree, right-click MyRootCA and then click Properties.

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

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.

Now configure our AIA and CDP url's and additional expiry information.

This should be done in powershell.

Lines starting with a hashtag are comments.

# The Server name is: %1 and should be removed, depending on your situation.

# For references: this was the original command: certutil -setreg CA\CACertPublicationURLs "1:$env:windir\system32\CertSrv\CertEnroll\%1_%3%%4.crt\n2:http://pki.contoso.com/certenroll/%1_%3%4.crt\n3:ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11"

Perform this on you RootCA

$aialist = Get-CAAuthorityInformationAccess; foreach ($aia in $aialist) {Remove-CAAuthorityInformationAccess $aia.uri -Force};

$crllist = Get-CACrlDistributionPoint; foreach ($crl in $crllist) {Remove-CACrlDistributionPoint $crl.uri -Force};

certutil -setreg CA\CACertPublicationURLs "1:$env:windir\system32\CertSrv\CertEnroll\%3%%4.crt\n2:http://pki.contoso.com/certenroll/%3%4.crt\n3:ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11"

certutil -setreg CA\CRLPublicationURLs "1:$env:windir\system32\CertSrv\CertEnroll\%3%8%9.crl\n2:http://pki.contoso.com/certenroll/%3%8%9.crl\n3:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10"

certutil -setreg CA\CRLPeriodUnits 3

certutil -setreg CA\CRLPeriod "Years"

certutil -setreg CA\CRLOverlapUnits 3

certutil -setreg CA\CRLOverlapPeriod "Days"

certutil -setreg CA\CRLDeltaPeriodUnits 0

certutil -setreg ca\ValidityPeriodUnits 10

certutil -setreg ca\ValidityPeriod "Years"

certutil -setreg CA\AuditFilter 127

Net stop certsvc Net start certsvc Certutil -CRL


# Copy the root CA certificate and CRL to removable media (usb stick) and paste in the CDP and / or AIA location

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

# 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:

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

# Now log in to your domain server that will become your subordinate certificate authority and insert your removable media

# Publish the "RootCA.crt" certificate into the configuration container of AD, this will make all machines on the domain trust this certificate without need for group policy distribution.

# ldap:///CN=ROOT CA Trusted Root,CN=AIA,CN=Public Key Services,CN=Services,CN=Configuration,DC=my,DC=domain,DC=net?cACertificate


certutil –dspublish –f "RootCA.crt" RootCA


# Add the "RootCA.crt" certificate to the local certificate store, normally this happens at next group policy update, but this speeds up the process


certutil –addstore –f root RootCA.crt
certutil –addstore –f root RootCA.crl


# Don't forget to create dns records and check if the CDP and AIA urls are reacheable.


Configuring a Webserver for CRL and CPS


MBSRV1 Hyper-V PKI Server IIS Webserver

Certificate Authority + PKI Website


PKI met root certificate and crl in Default Website PKI Virtual directory


  1. Now you need create a DNS record for the host that will be publishing your online CA information. In this case it’s D002MISC01, and per my previous steps I stuck with ‘www’ as the site name. I’m assuming the proper DNS zone already exists, since you have a domain with Active Directory up and running. This must be configured prior to continuing, as the subordinate will fail to properly configure if the CRL file is not available.
  1. We need to install IIS, since we will be distributing the CPS and CRL via the HTTP. On the VM which will be your online CA, run the following command:

Install-WindowsFeature Web-WebServer -IncludeManagementTools

  1. Open an elevated PowerShell and enter the following commands. If you have an official CPS, then you can skip the second command and just copy your cps.txt file to the directory. For security purposes I’d recommend putting the files on the D: drive, so you aren’t serving content from the OS drive.


new-item -path D:\CertEnroll -type directory


write-output "This is a sample CPS. Modify as needed." | out-file D:\CertEnroll\cps.txt


new-smbshare -name CertEnroll D:\CertEnroll -FullAccess SYSTEM,"CONTOSO\Domain Admins" -ChangeAccess "CONTOSO\Cert Publishers"
  1. Open the IIS Manager and add a Virtual Directory as shown below.
  1. Verify pki is selected in the left pane, then single click Authentication in the middle pane, and in the right Actions pane click on Edit Permissions.
  1. Select the Security tab and select Edit. Add the Cert Publishers group with Modify permissions (which will add several others under it).
  1. In the same dialog box, click add but change the from this location to the local computer. Manually enter IIS AppPool\DefaultAppPool. Leave the default permissions. If you use the user/group browser this will not be listed, so please manually enter it.
  1. At this point any anonymous browser can now read your CPS statement and see the public root certificate. You can test this by going to http://pki.contoso.com/certenroll/cps.txt and verify the sample file opens.
  1. In the middle pane, with pki still selected, click once on Request Filtering. In the right pane click on Edit Feature Settings and check the box next to Allow double escaping.
    1. Run iisreset from an elevated Powershell command.