Microsoft Active Directory Certificate Services (AD CS) using Azure Blob Storage

Deploying an Active Directory Certificate Services is a straightforward way for enterprises to build their PKI infrastructure. But it does have its shortcomings, such as
To overcome this, organizations need to deploy region-specific PKI infrastructure, which can be harder to maintain and introduces complexity to the whole infrastructure.
But using Azure, organizations can deploy a PKI infrastructure that can be operated worldwide with low latency and high availability.
In this article, we will be showing you how your own PKI architecture on Azure.
Note: If this is your first time deploying a PKI, I recommend following ADCS Two Tier PKI Hierarchy Deployment as it is a more straightforward approach and also touches the basics.
[NOTE: This is a test scenario. As such, CDP and AIA points may not match your requirements. Do use values that are appropriate as per your requirements.]
We will create blob storage that will act as our CDP/AIA points for our PKI infrastructure. We will also associate it with our custom domain to redirect it to our blob.
First, we would need to log into our Azure account and navigate to Storage Accounts
We will be creating a new storage account. So click Create on the top left corner.
Provide the necessary details on the basics. For Redundancy, I would recommend at least Zone-redundant Storage (ZRS)
On the Advanced tab, leave everything on default and click next
On the Networking tab, it is recommended to have public access from selected virtual networks and IP addresses and select the Virtual network where all the virtual machines will be deployed. If no virtual network exists, do create one.
This will create the blob storage. Next, we will associate this blob storage with our custom domain and ensure it is accessible via HTTP.
For this step, you would need a custom domain. Once you log in, you can navigate to DNS settings
Now we need to retrieve the hostname for your storage account. For this, we can navigate Settings > Endpoints on the left pane and copy the static website under Static Website. It should be something like https://pkitest.z13.web.core.windows.net (https://
Remove the https:// and additional /. It would look like pkitest.z13.web.core.windows.net, which is our hostname
Now in the DNS settings, for the hostname of the custom domain, provide pkitest and for the hostname, provide the hostname of the storage endpoint
Click to create a record
Navigate to Azure Storage account, click on Networking under Security + Networking and select Custom Domain on the tab above.
Provide the subdomain you created.
Click Save. After successful validation, you will get a validation notification
For this blob being a CDP/AIA point, we need HTTP access to the blog, which is why we would need to turn off the secure transfer. If enabled, HTTP access would not be possible; our PKI wouldn’t be able to use this blob as CDP/AIA point.
Navigate to Configuration under Settings
Set Secure Transfer Required to Disabled
Click Save
This section will ensure our storage account is accessible via a custom domain.
First, we would create a container and upload a file to it
Navigate to Containers under Data Storage
On the top left corner, click
Provide the name, set public level access as a blob, and click Create
The container will be created
Click on the name and navigate inside it
On the top left corner, click
Select any file for testing (preferably a pdf or txt file)
Click Upload, and once uploaded, it should be available in the container
Now, we will try to access the file using a custom domain. The URL should be
http://<subdomain.customdomain>/<mycontainer>/<myblob>
So for us, the domain should be
http://pkitest.encryptionconsulting.com/pkitest/TestFile.pdf
Ensure the file is opened in HTTP and it does display the file or downloads it
This concludes our section on preparing CDP and AIA points. Next, we will begin creating our PKI. Now you may delete the test file from the container as it would only contain the cert and CRLs.
This Step-by-Step guide uses an Active Directory Domain Services (AD DS) forest named encon.com. DC01 functions as the domain controller.
Firstly, we will deploy a VM on Azure. Ensure both the IPs are static.
While deploying, ensure,
Public IP Address is static
Once the VM is created, navigate to Networking under Settings and click on the Network Interface
Click on ipconfig1 on the menu and change IP private settings to Static from Dynamic
Provide other parameters as per your requirement and create the VM.
Once the VM is created, log in and follow the steps below
For Alternate DNS, provide 8.8.8.8 or any other public DNS service you want.
After installation, either
Click on Promote this server to a domain controller on Add Roles and Features Wizard
Or, click on Promote this server to a domain controller on Post Deployment Configurations in Notifications
On Deployment Configuration, choose to Add a new forest and provide the root domain name (“encon.com”)
Login to DC01 as encon\
The standalone offline root CA should not be installed in the domain. It should not even be connected to a network at all.
We will be creating this Root CA on-premises. I will create this on Proxmox, but you can use VMware or VirtualBox for this installation.
After installing Windows Server 2019, follow the steps below
Type in the following as contents of the file.
[Version] Signature="$Windows NT$" [Certsrv_Server] RenewalKeyLength=2048 ; recommended 4096 RenewalValidityPeriod=Years RenewalValidityPeriodUnits=20 AlternateSignatureAlgorithm=0
To define the Active Directory Configuration Partition Distinguished Name, run the following command from an administrative command prompt
Certutil -setreg CA\DSConfigDN "CN=Configuration,DC=Encon,DC=com"
To define CRL Period Units and CRL Period, run the following commands from an administrative command prompt:
Certutil -setreg CA\CRLPeriodUnits 52
Certutil -setreg CA\CRLPeriod "Weeks"
Certutil -setreg CA\CRLDeltaPeriodUnits 0
To define CRL Overlap Period Units and CRL Overlap Period, run the following commands from an administrative command prompt:
Certutil -setreg CA\CRLOverlapPeriodUnits 12
Certutil -setreg CA\CRLOverlapPeriod "Hours"
To define Validity Period Units for all issued certificates by this CA, type the following command and then press Enter. In this lab, the Enterprise Issuing CA should receive a 20-year lifetime for its CA certificate. To configure this, run the following commands from an administrative command prompt:
Certutil -setreg CA\ValidityPeriodUnits 20
Certutil -setreg CA\ValidityPeriod "Years"
Multiple methods are configuring the Authority Information Access (AIA) and certificate revocation list distribution point (CDP) locations. The AIA points to the public key for the certification authority (CA). You can use the user interface (in the Properties of the CA object), certutil, or directly edit the registry. The CDP is where the certificate revocation list is maintained, which allows client computers to determine if a certificate has been revoked. This lab will have three locations for the AIA and four locations for the CDP.
A certutil command is a quick and common method for configuring the AIA. The certutil command to set the AIA modifies the registry, so ensure that you run the command from a command prompt run as administrator. When you run the following certutil command, you will be configuring a static file system location, a HTTP location for the AIA, and a lightweight directory access path (LDAP) location. Run the following command:
certutil -setreg CA\CACertPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt\n2:http://pkitest.encryptionconsulting.com/pkitest/%1_%3%4.crt\n2:ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11"
Note: You need to modify the http address on the AIA location. For this scenario, our http container address was http://pkitest.encryptionconsulting.com/pkitest/, which can vary for you.
The certutil command to set the CDP modifies the registry, so ensure that you run the command from a command
certutil -setreg CA\CRLPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl\n2:http://pkitest.encryptionconsulting.com/pkitest/%3%8%9.crl \n10:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10"
Note: You need to modify the http address on the CDP location. For this scenario, our http container address was http://pkitest.encryptionconsulting.com/pkitest/, which can vary for you.
At an administrative command prompt, run the following commands to restart Active Directory Certificate Services and publish the CRL
net stop certsvc && net start certsvc
certutil -crl
Enterprise CAs must be joined to the domain. Before you install the Enterprise Issuing CA (CA02), you must first join the server to the domain. Then you can install the Certification Authority role service on the server.
Firstly, we will deploy a VM on Azure. Ensure both the IPs are static.
While deploying, ensure,
Public IP Address is static
Once the VM is created, navigate to Networking under Settings and click on the Network Interface
Click on ipconfig1 on the menu and change IP private settings to Static from Dynamic
Provide other parameters as per your requirement and create the VM.
Only change the DNS Server Address, and provide the private IPv4 of DC01 (if both belong to the same region), or provide the public IP address of DC01 (if they belong to different regions)
Changer PC name to CA02 and provide domain name in the domain. Provide credentials for DC01 and wait until you get a success message
Type in the following as contents of the file.
[Version] Signature="$Windows NT$" [PolicyStatementExtension] Policies=InternalPolicy [InternalPolicy] OID= 1.2.3.4.1455.67.89.5 URL= http://pkitest.encryptionconsulting.com/pkitest/cps.txt [Certsrv_Server] RenewalKeyLength=2048 RenewalValidityPeriod=Years RenewalValidityPeriodUnits=10 LoadDefaultTemplates=0
Copy the CRLs and Certificates present
Paste the files into the C drive in CA02
Note: If you are using RDP, you can copy and paste directly
On CA02, to publish Encon Root CA Certificate and CRL in Active Directory, run the following commands at an administrative command prompt.
certutil -f -dspublish "C:\CA01_Encon Root CA.crt" RootCA certutil -f -dspublish "C:\Encon Root CA.crl" CA01
To add Fabrikam Root CA Certificate and CRL in CA02.Fabrikam.com local store, run the following command from an administrative command prompt.
certutil -addstore -f root "C:\CA01_Encon Root CA.crt" certutil -addstore -f root "C:\Encon Root CA.crl"
Ensure you are logged in as Encon User in CA02
Click Start, and then click Server Manager
Click Manage, and then click Add Roles and Features
Click Next on Before you Begin
On Installation Type, click Next
On Server Selection, click Next
On Server Roles, choose Active Directory Certificate Services, click on Add Features when prompted and click Next
On Features, click Next
On AD CS, click Next.
On Role Services, Choose Certificate Authority Web Enrollment, click on Add Features when prompted, and click Next
On Web Server Role (IIS) and Role Services, click Next
On Confirmation, click Install
Click on Configure Active Directory Certificate Services on the destination server in Add Roles and Features Wizard
Or, click on Configure Active Directory Certificate Services on Notification Center
Under Role Services, choose both Certificate Authority as well as Certificate Authority Web Enrollment
On Setup type, ensure Enterprise CA is chosen and click Next
On CA Type, choose Subordinate CA, and click Next
On Private Key, choose to Create a new private key
On Cryptography, leave defaults and click Next
On CA Name, provide Common Name as Encon Issuing CA and leave the everything default value.
On Certificate Request, ensure Save a certificate request to file is selected and click Next
On Certificate Database, click Next
On Confirmation after reviewing, Click Configure
Issuing CA should now be configured. Click Close.
After Issuing CA is configured, a file will appear on the C drive. Copy this file to C drive in Root CA.
Run the command
certreq -submit "C:\CA02.encon.com_encon-CA02-CA.req"
Select Root CA from the Certification Authority List
Once a request is submitted, you will get a RequestID
Open Certificate Authority from Tools in Server Manager
Navigate to Pending Requests
Right Click on the RequestID that you got while submitting the request, click All Tasks, and click Issue
Once issued, navigate to the command prompt again, and run
certreq -retrieve 2 "C:\CA02.encon.com_Encon Issuing CA.crt"
Select Root CA from the Certification Authority List
Once retrieved, the successful message is displayed
Copy the issued certificate from Root CA to CA02
Login to CA02 as an Encon user and copy the certificate to the C drive
Open Certificate Authority from Tools in Server Manager
Right-click on Encon Issuing CA, click on All Tasks, and click Install CA Certificate
Navigate to C drive, and select All files beside File name until the copied certificate is visible
Select the issued certificate and click Open
Right-click on Encon Issuing CA, click on All Tasks, and click Start Service
To define CRL Period Units and CRL Period, run the following commands from an administrative command prompt:
To define CRL Overlap Period Units and CRL Overlap Period, run the following commands from an administrative command prompt:
To define Validity Period Units for all issued certificates by this CA, type the following command and then press Enter. In this lab, the Enterprise Issuing CA should receive a 20-year lifetime for its CA certificate. To configure this, run the following commands from an administrative command prompt:
Multiple methods are configuring the Authority Information Access (AIA) and certificate revocation list distribution point (CDP) locations. The AIA points to the public key for the certification authority (CA). You can use the user interface (in the Properties of the CA object), certutil, or directly edit the registry.
The CDP is where the certificate revocation list is maintained, which allows client computers to determine if a certificate has been revoked. This lab will have three locations for the AIA and three for the CDP.
A certutil command is a quick and common method for configuring the AIA. The certutil command to set the AIA modifies the registry, so ensure that you run the command from a command prompt run as administrator.
When you run the following certutil command, you will be configuring a static file system location, a HTTP location for the AIA, and a lightweight directory access path (LDAP) location. Run the following command:
certutil -setreg CA\CACertPublicationURLs “1:C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt\n2:http://pkitest.encryptionconsulting.com/pkitest/%1_%3%4.crt\n2:ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11”
Note: You need to modify the http address on the AIA location. For this scenario, our http container address was http://pkitest.encryptionconsulting.com/pkitest/, which can vary for you.
The certutil command to set the CDP modifies the registry, so ensure that you run the command from a command
certutil -setreg CA\CRLPublicationURLs “65:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl\n2:http://pkitest.encryptionconsulting.com/pkitest/CertEnroll/%3%8%9.crl\n79:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10”
Note: You need to modify the http address on the CDP location. For this scenario, our http container address was http://pkitest.encryptionconsulting.com/pkitest/, which can vary for you.
Also, as per the CDP point, the CertEnroll folder will exist inside the pkitest container in Azure Blob. This is because the folder will be recursively copied from the CertSrv folder to the blob storage
At an administrative command prompt, run the following commands to restart Active Directory Certificate Services and publish the CRL
net stop certsvc & &net start certsvc
certutil -crl
Per our CDP and AIA points, the certificates would be available at the blob storage in Azure. If we run PKIView.msc at Issuing CA, we will run into errors where the certificates or CRLs are not found
To resolve this, we need to upload
Issuing CA CRLs will be uploaded using a script we will run next.
To upload the files, copy them from their respective machines and keep them handy on your host machine. You can find these files at C:\Windows\System32\certsrv\CertEnroll on both Root CA and issuing CA.
Note: Do not copy the CRLs of Issuing CA.
Once copied, follow the steps below
Navigate to the storage account, and click on the pkitest you created
Click on Containers under Data Storage
Click on Upload on the top left
Click on the browse icon and select all the files that need to be uploaded and click Open
Check to Overwrite if files already exist and then click Upload
After uploading, all the files should be available
Once the files are uploaded, navigate to CA02 and open PKIView.msc again. Now CDP points of Root and Issuing CA should be available, but the AIA point would still show an error as we didn’t copy those files to the pkitest folder
Before we begin, we need to download AzCopy. Once downloaded, extract the app into C:\ to be accessible. We will be using this location on our script. Change the script’s path if you intend to store the application in a different location.
Now you would also need a folder to store the code. I would recommend creating a folder on C drive as AZCopyCode. Download the script from below and store it there. We would need to make some changes to make it work.
Note: This code was initially created by dstreefkerk. As per Windows Server 2022, this code does work. I have made some changes and fixed a few bugs.
Github Gist to be embedded:
<script src=”https://gist.github.com/coffee-coded/4cbeb0de02628bc2da6b182dc11bad0b.js”></script>
Navigate to the storage account, and click on the pkitest you created
Click on Containers under Data Storage
Click on Shared Access Token under Settings. Provide appropriate permissions, and choose an expiry date (preferably one year)
Paste the SAS token for the variable
$azCopyDestinationSASKey
Once copied, it will show how many files are copied, with 100% and all done with 0 Failed
Open PKIView.msc, and now no errors should be visible
The overall PKI should be healthy.
For this scenario, we suppose you get an error
Copy the URL by right-clicking on the location and copying it to a notepad. It should look something like this
http://pkitest.encryptionconsulting.com/pkitest/Encon%20Root%20CA.crl%20
If you try opening this on the browser, it would still give an error as there is a trailing %20 at the end, indicating a space at the end. To resolve this, CDP and AIA points need to be changed on Root CA, and the issuing CA needs to be recreated again.
We would automate this script using Task Scheduler to run this script every week. You can tweak this as per your requirements.
Left click on Task Scheduler (local) and click on Create a Basic Task
Provide name and description for the Task
Task Trigger is configured to weekly
Select Data and Time when the script will run
On Action, select Start A program and click Next
Under Start, a Program, In Program/Script write
powershell -file "C:\AZCopyCode\Invoke-UpdateAzureBlobPKIStorage.ps1"
Click yes on the prompt
Check the Open Properties dialog and click Finish
Once completed, AZ Copy should be available in Task Scheduler Library.
Right Click AZ Copy and click Run
Refresh and check History Tab. Action Completed should appear in History
This concludes our AD CS installation with Azure Blob Storage. It is easier to manage, but we also achieve high availability using Azure’s Blob Storage. This will help organizations create PKI that can be operational worldwide with minimal latency and high performance no matter where you are. If you face any issues, do remember to reach out to info@encryptionconsulting.com