Author: Anish Bhattacharya

Troubleshooting LDAP issues can seem tricky, which is where this blog should help you on your troubleshooting journey. We will discuss 2 scenarios that should solve your LDAP errors.

Scenario 1

This scenario takes into consideration that your certificate was not published in Active Directory. To resolve this issue run the commands:

To resolve AIA issues:     certutil -dspublish -f <path to root certificate> RootCA

To resolve CDP issues:    certutil -dspublish -f <path to root crl> <hostname>

If the issue exists for Issuing CA, you need to replace RootCA with SubCA and use the issuing CA’s hostname.

After this, you can check if the certificate is present in Active Directory or not.

For that, log in to Domain Controller, and open adsiedit.msc, connect to Configuration, and then we can navigate to Services > Public Key Services > AIA and check the present certificates. If the certificates are present and you still receive that error, then follow Scenario 2.

Scenario 2

If Scenario 1 does not fix the issue, then it may be possible that LDAP URL was incorrectly configured while configuring the AIA points on your Root CA.

To resolve this, first open PKIView.msc to check which LDAP URL your PKI is looking for. For this scenario, my PKI is looking for:

ldap:///CN=Encon%20Root%20CA,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=ROOTCAOCS,CN=Configuration,DC=Encon,DC=com?cACertificate?base?objectClass=certificationAuthority

But the certificate is published on:

CN=Encon Root CA,CN=AIA,CN=Public Key Services,CN=Services,CN=Configuration,DC=encon,DC=com

You can check the distinguished name on the object present in ADSIedit.msc.

To resolve this, we would follow the steps:

1. Create a new Container Structure in your Domain partition

   CN=Encon%20Root%20CA,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=ROOTCAOCS,CN=Configuration,DC=Encon,DC=com

2. Create an Object under Configuration

   

3. Choose the object class “container”

   

4. Provide the exact value ROOTCAOCS as highlighted above

   

5. Click Finish

   

6. Follow steps 2-5 to create further containers in ROOTCAOCS > Services > Public Key Services > AIA

   

7. Run the command on Domain Controller to extract the published object

   LDIFDE -d ” CN=Encon Root CA,CN=AIA,CN=Public Key Services,CN=Services,CN=Configuration,DC=encon,DC=com” -f c:\export.txt

   

8. Make changes to export.txt where you replace the existing dn with the LDAP URL your PKI is looking for

   CN=Encon Root CA,CN=AIA,CN=Public Key Services,CN=Services,CN=ROOTCAOCS,CN=Configuration,DC=encon,DC=com

   You also need to remove GUID, USN Information, and other details.

   

9. Publish the u ldifde -i -f c:\export.txt

   

10. Object should now be in new place

    

11. PKI View should show no errors

    

Conclusion

Issues with CDP and AIA LDAP locations can be tricky. Misconfiguration can often cause issues, which can be harder to track. This should solve all the LDAP URL issues that you may face in your PKI environment. LDAP issues can be tricky at times, but if Scenario 1 does not fix your issue, Scenario 2 definitely will.

Read Time: 5 minutes

Active Directory (AD) is a critical component of many organizations’ IT infrastructure. It provides a central repository for a user, group, and computer accounts, as well as a variety of other objects, such as shared resources and security policies. In order for AD to function properly, certain ports must be opened on the firewall to allow communication between AD servers and clients.

Ports required for AD communication

The following ports are required for basic AD communication:

• TCP/UDP port 53: DNS
• TCP/UDP port 88: Kerberos authentication
• TCP/UDP port 135: RPC
• TCP/UDP port 137-138: NetBIOS
• TCP/UDP port 389: LDAP
• TCP/UDP port 445: SMB
• TCP/UDP port 464: Kerberos password change
• TCP/UDP port 636: LDAP SSL
• TCP/UDP port 3268-3269: Global catalog

In addition to these ports, other ports may be required depending on your AD environment’s specific components and features. For example, if you are using Group Policy, the following ports will also be required:

• TCP port 80: HTTP
• TCP port 443: HTTPS
• TCP port 445: SMB

If you are using ADFS (Active Directory Federation Services) for single sign-on, the following ports will also be required:

• TCP port 80: HTTP
• TCP port 443: HTTPS
• TCP port 49443: ADFS

Ports required for PKI communication

In order for a PKI to function properly, certain ports need to be opened on the firewall to allow communication between the various components of the PKI system. These ports include:

1. TCP port 80

   This port is used for HTTP communication, which is required for clients to access the certificate revocation list (CRL) and other information from the certificate authority (CA) server.

2. TCP port 389

   This port is used for LDAP communication, which is required for clients to access the certificate database on the CA server.

3. TCP port 636

   This port is used for LDAPS communication, a secure version of LDAP that uses SSL/TLS for encryption. This is required if you are using LDAP over a public network.

4. TCP port 9389

   This port is used for the Web Services for Management (WS-Management) protocol, which is required for clients to access the CA server using the Certificates snap-in in the Microsoft Management Console (MMC).

In addition to these ports, you may also need to open other ports depending on your PKI system’s specific components and configuration. For example, if you are using Online Certificate Status Protocol (OCSP) to check the status of certificates, you will need to open TCP port 2560.

Troubleshooting firewall issues with PKI

To troubleshoot common firewall issues with a PKI, you can follow these steps:

• Verify that the necessary ports are open on the firewall. You can do this by using the netstat command to list all of the open ports on the system and compare the results with the list of ports that are required for your PKI system.
• Check the firewall logs to see any entries related to the PKI system. This can help you to identify any specific rules or settings that may be blocking the necessary ports.
• Test the connectivity between the PKI components to ensure they can communicate properly. You can do this by using the ping, telnet, or tracert commands to test the connectivity between the client and the CA server and between other components of the PKI system.
• If you are still having issues with the firewall, try temporarily disabling the firewall to see if this resolves the problem. This will help you to determine whether the firewall is the cause of the issue or if there is a problem with another component of the PKI system.

Conclusion

Maintaining the proper firewall configuration is important in ensuring that your Active Directory and PKI system functions properly. By verifying that the necessary ports are open and troubleshooting any firewall issues that may arise, you can help to keep your Active Directory and PKI system secure and reliable.

Read Time: 10 Minutes

CDP and AIA Points can sometimes be confusing but are the most important pillars of a functional PKI environment. Configuration of proper CDP and AIA points can result in a better and healthy PKI environment, and debugging those issues can be equally tricky. This article intends to be a way to stop any CDP/AIA issues that one may face during the PKI configuration and debugging stages.

Configuration of CDP/AIA Points

Proper configuration of CDP and AIA points can be tricky. It involves proper permission of where CRL needs to be published and where they would be accessed.

Improper configuration of CDP can result in two scenarios

• CRL fails to be published, or
• CRLs cannot be accessed

Configuration of AIA

AIA is the easiest to configure. If OCSP is used, the AIA decimal point may include 34; otherwise, it’s always 2.

Decimal Value 1 is included when publishing in the %windir%\System32\certsrv\CertEnroll location. It can also be included to publish directly onto the AIA location if proper permissions are provided.

[Note: If the location is behind a load balancer, the CA cannot access both servers and may cause failure. Please do not publish on those locations; instead manual copy is recommended]

Decimal Value 2 is included when the URL is to be added to the issued certificates. These URLs act as the AIA points from where the certificates can be extracted.

Configuration of CDP

Configuration of CDP can depend on how the CA is configured, how the CRLs are published and accessed, and if Delta CRLs are published.

Decimal values are used accordingly based on how the CDP needs to be configured.

Decimal Value 1 is mostly used to publish CRLs to %windir%\System32\certsrv\CertEnroll location or to those locations where CA has proper permissions to access. If Delta CRLs are also published, 65 (1+64) is used.

[Note: If the location is behind a load balancer, the CA cannot access both servers and may cause failure. Please do not publish on those locations; instead manual copy is recommended]

Decimal Value 2 includes the URL or location and lets it act as a CDP location from where base or delta CRLs are accessed.

Example

Decimal Value 79 = CRLs are published at that location (1) + Location is added to CDP (2) + Delta CRL location (4) + Include in all CRLs (8) + Publish Delta CRL at this location (64)

Decimal Value 65 = Publish CRL at this location (1) + Publish Delta CRL at this location (64)

Decimal Value 6 = Location is added to CDP (2) + Delta CRL location (4)

CRL Replacement Tokens

In the above examples, you may have noticed %1, %3, %4, %8, and %9. This represents how the CA is configured and what the file’s name should be. If the files are renamed, the AIA and CDP points may fail as the naming convention doesn’t match.

Based on the mapping value, the AIA and CDP points are given a naming convention to find the correct file from those locations.

Debugging CDP/AIA location issues

If the CDP/AIA locations are properly configured, these steps will temporarily help resolve the issues. For example, we will use AIA issues, which will also work for CDP issues.

After we open and check PKIView.msc, we can see where the issue is. We can copy the URL to a notepad for further investigation.

The AD doesn’t have our certificate if the issue is on the LDAP location. This is quite an easy fix.

Certificates retrieved via LDAP are retrieved from Domain Controller. If we open Domain Controller and ADSIEdit.msc, then we can navigate to Services > Public Key Services > AIA and check the present certificates. Since our Issuing CA Certificate is absent, the PKI environment cannot retrieve the certificate from that location.

To resolve this, we navigate to our issuing CA and run the command
certutil -dspublish -f <path to certificate> SubCA

Once the command runs successfully, we can refresh our PKIView.msc to check if the issue is resolved, and we should see a clean slate

However, if the AIA location #2, or the HTTP location is causing errors, this error is because the certificate isn’t present at that server endpoint.

To resolve this, we copy the certificate from %windir%\System32\certsrv\CertEnroll location to our web server, which hosts our certificate.

This would resolve our issue, which we can check on PKIView.msc again.

Conclusion

Issues with CDP and AIA locations can be tricky. Misconfiguration can often cause issues, which can be harder to track. With this guide, we hope to make the configuration of CDP/AIA points much easier with debugging steps to support any technical issues.

If you need help with your PKI environment, feel free to email us at info@encryptionconsulting.com.

Read Time: 7 minutes

Issuing CA often needs to be decommissioned for a variety of reasons, such as

• The operating system is reaching the end of its life
• CA might be compromised
• CA is having operational issues and is too complicated to clean up.

No matter the reason, migrating to a new issuing CA can seem easy. Still, it can come with new challenges, such as mitigating risks, minimizing operational impact, etc.

While migrating issuing CAs, we need to ensure,

1. The current certificates that are issued remain operational until their validity runs out.
2. The old issuing CA should not issue any more certificates.
3. We can move to other CDP/AIA points according to the required changes, but the issuing CA would have a minimal operation and no impact on the PKI infrastructure.

Prerequisites

Before we begin, you need a new server that will act as the new issuing CA. The server should be configured, and issuing CA should be installed.

Steps to Migrate

These steps will help organizations migrate to new issuing CA.

If CDP/AIA points are not being changed, steps 2, 4, and 5 are optional and shouldn’t be followed.

1. Log onto the old Issuing CA
2. Identify CDP/AIA Distribution Points (optional)
   1. Open command prompt
   2. Type the command

      certutil -getreg CA\CACertPublicationURLs

      

   3. Document the HTTP AIA points. Ignore LDAP and C:\%windir%

      As per the screenshot, the AIA point is http://pki.encon.com/CertEnroll/%1_%3%4.crt

      %1 refers to ServerDNSName

      %3 refers to CaName

      %4 refers to Certificate Name

      Actual URL: http://pki.encon.com/CertEnroll/iCA2016.encon.com_iCA2016.crt

   4. Type the command

      certutil -getreg CA\CRLPublicationURLs

      

   5. Document the HTTP CDP Points. Ignore LDAP and C:\%windir%

      As per the screenshot, the CDP point is http://pki.encon.com/CertEnroll/%3%8%9.crl

      %3 refers to CaName

      %8 refers to CRLNameSuffix

      %9 refers to DeltaCRLAllowed

      Actual URL: http://pki.encon.com/CertEnroll/iCA2016.crl



3. Disabling the Delta CRL and issue a new long Certificate Revocation List (CRL)
   1. Open Certificate Authority Console

      

   2. Right-click on Revoked Certificates, and then click properties

      

   3. Uncheck “Publish Delta CRL”

      

   4. Edit the “CRL publication interval” to 99 years

      

      Click OK

   5. Open command prompt as administrator
   6. Type the following command

      certutil -crl

      

4. Copy old CA’s certificate (crt) and Certificate Revocation List (CRLs) files to new CDP/AIA Points (optional)
   1. Navigate to %windir%\System32\CertSrv\CertEnroll
   2. Copy the old CA’s crt and CRL files to new CDP/AIA Points

      

5. Redirect AIA and CDP points of old CA to the new location

   This can be done using an

   1. IIS redirect, or
   2. DNS CNAME

      redirecting the AIA and CRL of the old Certification Authority.

6. Document all certificate templates and stop certificate publishing on old Issuing CA
   1. Open the command line with elevated privileges
   2. Run

      Certutil -catemplates > c:\catemplates.txt

      and document all certificate templates published at the old Certification Authority

      

      In total, certificate templates are present.

   3. Launch the Certification Authority console
   4. Navigate to “Certificate Templates”
   5. Highlight all templates in the right pane, right-click and then click “Delete”

      

      The old Certification Authority cannot issue any certificates and has all of its AIA and CRLs redirected to a new CRL Distribution point. The next steps will detail how users can document the certificates templates published on the old issuing CA and how to make them available at the new issuing CA.

7. Sort Certification Authority Database, identify and document all certificates issued based on certificate templates
   1. Open Certificate Authority Console.
   2. Highlight Issued Certificates.
   3. Move to the right and sort by “Certificate Templates.”

      

   4. Identify the certificates that are issued by default certificate template types.
   5. Document the certificates issued by custom certificate templates i.e. any template other than the default certificate templates.



8. Document certificates based on default certificate template types
   1. Open command prompt with elevated privileges
   2. Run

      Certutil -view -restrict “Certificate Template=Template” -out “SerialNumber,NotAfter,DistinguishedName,CommonName”> c:\TemplateType.txt

      Note: Replace the Template with the correct template name

      

   3. Review the output on TemplateType.txt and document all certificates that need immediate action (requiring issuance from the new CA infrastructure if needed, such as Web Server Certificate)
   4. Consult with application administrators using the certificates to determine the best approach to replace the certificates if needed
9. Document certificates based on custom certificate types
   1. Open Certification Authority Console
   2. Right click on Certificate Templates, and click Manage

      

   3. Double-click the certificate template and click on the “Extensions” tab

   

   4. Click on “Certificate Template Information”

   

   5. Copy the Object Identifier (OID) number – the number will look similar to

      1.3.6.1.4.1.311.21.8.5363900.15781253.12798358.11444918.12080715.141.12736713.11129372

   6. Open the command prompt with elevated privileges
   7. Run

      Certutil -view -restrict “Certificate Template= 1.3.6.1.4.1.311.21.8.5363900.15781253.12798358.11444918.12080715.141.12736713.11129372″ -out “SerialNumber,NotAfter,DistinguishedName,CommonName”> c:\CustomTemplateType.txt

      Note: Replace the OID number with the number identified in step 5

      

   8. Examine the output of c:\CustomTemplateType.txt and document all the certificates needing immediate action (requiring issuance from the new CA infrastructure if needed, such as custom SSL certificates).
   9. Consult with the application administrator using the certificates to determine the best approach to replace the certificates if needed
10. Enable certificate templates needed on the results of steps 7 to 9 on new Issuing CA
    1. Login to new Issuing CA.
    2. Right-click on “Certificate Templates,” click New, and click “Certificate Templates to Issue.”

       

    3. Choose all certificate templates needed in the “Enable Certificate Templates” windows and click >OK.

       

Conclusion

If you need help with your PKI environment, feel free to email us at info@encryptionconsulting.com.

Read time: 20 minutes

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

• Lack of deployment in multiple regions
• High latency on CDP and AIA points

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.

Prerequisites

• An Azure account where we will create Virtual Machines and blob storage
• A custom domain name
• An offline Windows Server VM, which will be our Root CA

[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.]

Preparing CDP and AIA points

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.

Creating Azure Blob Storage

1. First, we would need to log into our Azure account and navigate to Storage Accounts

   

2. We will be creating a new storage account. So click Create on the top left corner.

   

3. Provide the necessary details on the basics. For Redundancy, I would recommend at least Zone-redundant Storage (ZRS)

   

4. On the Advanced tab, leave everything on default and click next

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

   

6. On the Data Protection tab, click Next.
7. On the Encryption tab, leave everything default and click Next.
8. Provide relevant tags and click Next.
9. On the review tab, you can review everything looks good and click Create.

This will create the blob storage. Next, we will associate this blob storage with our custom domain and ensure it is accessible via HTTP.

Mapping a custom domain to Azure Blog Storage

For this step, you would need a custom domain. Once you log in, you can navigate to DNS settings

1. In DNS settings, navigate to DNS records and enter a CNAME record.

2. 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 pkitest.z13.web.core.windows.net (https://.z13.web.core.windows.net/)

   Remove the https:// and additional /. It would look like pkitest.z13.web.core.windows.net, which is our hostname

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

4. Navigate to Azure Storage account, click on Networking under Security + Networking and select Custom Domain on the tab above.

5. Provide the subdomain you created.

   

6. Click Save. After successful validation, you will get a validation notification

   

Disabling secure transfer required

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.

1. Navigate to Configuration under Settings

2. Set Secure Transfer Required to Disabled

   

3. Click Save

Testing Accessibility of Storage Account

This section will ensure our storage account is accessible via a custom domain.

1. First, we would create a container and upload a file to it

2. Navigate to Containers under Data Storage

   

3. On the top left corner, click

4. Provide the name, set public level access as a blob, and click Create

   The container will be created

   

5. Click on the name and navigate inside it

6. On the top left corner, click

7. Select any file for testing (preferably a pdf or txt file)

   

8. Click Upload, and once uploaded, it should be available in the container

   

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

Creating Domain Controller

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,

1. VMs are deployed on the same Virtual Network
2. If deployed on the same region, ensure the subnet is the same

3. Public IP Address is static

   

4. Once the VM is created, navigate to Networking under Settings and click on the Network Interface

   

   1. Navigate to IP Configuration under settings

   2. Click on ipconfig1 on the menu and change IP private settings to Static from Dynamic

      

   3. Click Save and go back to the VM

Provide other parameters as per your requirement and create the VM.

Configuring Network

Once the VM is created, log in and follow the steps below

1. Login to DC01 as a local user
2. Click Start, type ncpa.cpl , and press ENTER
3. Click on Ethernet, and then click Properties under Activity
4. Double Click on Internet Protocol Version 4 (IPv4)
5. Only change the DNS Server Address, and provide the private IPv4 of DC01

6. For Alternate DNS, provide 8.8.8.8 or any other public DNS service you want.

   

7. Click OK and restart the VM from the Portal
8. Once Restarted, log in to DC01 as a local user
9. Click Start, type sysdm.cpl , and press ENTER
10. Changer PC name to DC01, and Restart Now when prompted.

Installing Active Directory Domain Services and Adding a new Forest

1. Open Server Manager. To do so, you can click the Server Manager icon in the toolbar or click Start, then click Server Manager.
2. Click Manage, and then click Add Roles and Features
3. Before you Begin, click Next
4. On Installation Type, click Next
5. On Server Selection, click Next
6. On Server Roles, choose Active Directory Domain Services, click Add Features, and then click Next
7. On Features, click Next
8. On AD DS, click Next
9. On Confirmation, click Install.

10. After installation, either

    1. Click on Promote this server to a domain controller on Add Roles and Features Wizard

       

    2. Or, click on Promote this server to a domain controller on Post Deployment Configurations in Notifications

       

11. On Deployment Configuration, choose to Add a new forest and provide the root domain name (“encon.com”)

    

12. On Domain Controller options, provide Directory Services Restore Mode password and click Next
13. Under DNS options, click Next
14. Under Additional options, click Next
15. Under Paths, click Next
16. Under Review options, click Next
17. Under Prerequisites check, click Install
18. Once installed, the remote connection would be terminated.

19. Login to DC01 as encon\

    

20. DC01 is now ready

Creating Offline Root CA

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

1. Log onto CA01 as CA01\Administrator.
2. Click Start, click Run, and then type notepad C:\Windows\CAPolicy.inf and press ENTER.
3. When prompted to create a new file, click Yes.

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

5. Click File and Save to save the CAPolicy.inf file under C:\Windows directory. Close Notepad

Installing Offline Root CA

1. Log onto CA01 as CA01\Administrator.
2. Click Start, and then click Server Manager.
3. Click Manage, and then click Add Roles and Features
4. On the Before You Begin page, click Next.
5. On the Select Server Roles page, select Active Directory Certificate Services, and then click Next.
6. On the Introduction to Active Directory Certificate Services page, click Next.
7. On the Select Role Services page, ensure that Certification Authority is selected, then Next.
8. On the Specify Setup Type page, ensure that Standalone is selected, and then click Next.
9. On the Specify CA Type page, ensure that Root CA is selected, and then click Next.
10. On the Set Up Private Key page, ensure that Create a new private key is selected, and then click Next.
11. Leave the defaults on the Configure Cryptography for CA page, and click Next.
12. On Configure CA Name page, under the Common name for this CA, clear the existing entry and type Encon Root CA. Click Next.
13. On the Set Validity Period page, under Select validity period for the certificate generated for this CA, clear the existing entry and type 20. Leave the selection box set to Years. Click Next.
14. Keep the default settings on the Configure Certificate Database page, and click Next.
15. Review the settings on the Confirm Installation Selections page and then click Install.
16. Review the information on the Installation Results page to verify that the installation is successful, and click Close.

Post Installation Configuration on Root CA

1. Ensure that you are logged on to CA01 as CA01\Administrator.
2. Open a command prompt. To do so, you can click Start, click Run, type cmd and then click OK.

3. 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"

4. To define CRL Period Units and CRL Period, run the following commands from an administrative command prompt:

   1. Certutil -setreg CA\CRLPeriodUnits 52
   2. Certutil -setreg CA\CRLPeriod "Weeks"
   3. Certutil -setreg CA\CRLDeltaPeriodUnits 0

5. To define CRL Overlap Period Units and CRL Overlap Period, run the following commands from an administrative command prompt:

   1. Certutil -setreg CA\CRLOverlapPeriodUnits 12
   2. Certutil -setreg CA\CRLOverlapPeriod "Hours"

6. 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:

   1. Certutil -setreg CA\ValidityPeriodUnits 20
   2. Certutil -setreg CA\ValidityPeriod "Years"

Configuration of CDP and AIA points

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.

Configuring AIA points

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.

Configuring the CDP Points

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

Creating Issuing CA

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,

1. VMs are deployed on the same Virtual Network
2. If deployed on the same region, ensure the subnet is the same

3. Public IP Address is static

   

4. Once the VM is created, navigate to Networking under Settings and click on the Network Interface



1. Navigate to IP Configuration under settings

2. Click on ipconfig1 on the menu and change IP private settings to Static from Dynamic

   

3. Click Save and go back to the VM

Provide other parameters as per your requirement and create the VM.



Configuring Network

1. Login to CA02 as a local user
2. Click Start, type ncpa.cpl, and press ENTER
3. Click on Ethernet, and then click Properties under Activity
4. Double Click on Internet Protocol Version 4 (IPv4)

5. 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)

   

6. Click OK and restart the VM from the Portal
7. Once Restarted, log in to CA02 as a local user
8. Click Start, type sysdm.cpl, and press ENTER

9. Changer PC name to CA02 and provide domain name in the domain. Provide credentials for DC01 and wait until you get a success message

   

10. Click on Restart Now when prompted.

Creating CAPolicy in Issuing CA

1. Log onto CA01 as CA01\Administrator.
2. Click Start, click Run, and then type notepad C:\Windows\CAPolicy.inf and press ENTER.
3. When prompted to create a new file, click Yes.

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

5. Click File and Save to save the CAPolicy.inf file under C:\Windows directory. Close Notepad

Publishing Root CA Certificates and CRLs in CA02

1. Log into CA01 as a local administrator
2. Navigate to C:\Windows\System32\CertSrv\CertEnroll

3. Copy the CRLs and Certificates present

   

4. Paste the files into the C drive in CA02

   Note: If you are using RDP, you can copy and paste directly

   

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

6. 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"
       

Installing Issuing CA

1. Ensure you are logged in as Encon User in CA02

2. Click Start, and then click Server Manager

3. Click Manage, and then click Add Roles and Features

4. Click Next on Before you Begin

   

5. On Installation Type, click Next

   

6. On Server Selection, click Next

   

7. On Server Roles, choose Active Directory Certificate Services, click on Add Features when prompted and click Next

   

8. On Features, click Next

   

9. On AD CS, click Next.

   

10. On Role Services, Choose Certificate Authority Web Enrollment, click on Add Features when prompted, and click Next

    

11. On Web Server Role (IIS) and Role Services, click Next

    

12. On Confirmation, click Install

    

Configuration of Issuing CA

1. After installation, either

   1. Click on Configure Active Directory Certificate Services on the destination server in Add Roles and Features Wizard

      

   2. Or, click on Configure Active Directory Certificate Services on Notification Center

      

2. On Credentials, click Next

   

3. Under Role Services, choose both Certificate Authority as well as Certificate Authority Web Enrollment

   

4. On Setup type, ensure Enterprise CA is chosen and click Next

   

5. On CA Type, choose Subordinate CA, and click Next

   

6. On Private Key, choose to Create a new private key

   

7. On Cryptography, leave defaults and click Next

   

8. On CA Name, provide Common Name as Encon Issuing CA and leave the everything default value.

   

9. On Certificate Request, ensure Save a certificate request to file is selected and click Next

   

10. On Certificate Database, click Next

    

11. On Confirmation after reviewing, Click Configure

    

12. Issuing CA should now be configured. Click Close.

    

13. After Issuing CA is configured, a file will appear on the C drive. Copy this file to C drive in Root CA.

    

Issue Encon Issuing CA Certificate

1. Copy Issuing CA req file to Root CA C drive
2. Open Command Prompt

3. Run the command

   certreq -submit "C:\CA02.encon.com_encon-CA02-CA.req"

4. Select Root CA from the Certification Authority List

   

5. Once a request is submitted, you will get a RequestID

   

6. Open Certificate Authority from Tools in Server Manager

   

7. Navigate to Pending Requests

   

8. Right Click on the RequestID that you got while submitting the request, click All Tasks, and click Issue

   

9. Once issued, navigate to the command prompt again, and run

   certreq -retrieve 2 "C:\CA02.encon.com_Encon Issuing CA.crt"

10. Select Root CA from the Certification Authority List

    

11. Once retrieved, the successful message is displayed

    

12. Copy the issued certificate from Root CA to CA02

    

13. Login to CA02 as an Encon user and copy the certificate to the C drive

14. Open Certificate Authority from Tools in Server Manager

    

15. Right-click on Encon Issuing CA, click on All Tasks, and click Install CA Certificate

    

16. Navigate to C drive, and select All files beside File name until the copied certificate is visible

    

17. Select the issued certificate and click Open

    Right-click on Encon Issuing CA, click on All Tasks, and click Start Service

    

Post Installation Configuration on Issuing CA

1. Ensure that you are logged on to CA02 as Encon User
2. Open a command prompt. To do so, you can click Start, click Run, type cmd and then click OK.

3. To define CRL Period Units and CRL Period, run the following commands from an administrative command prompt:

   1. Certutil -setreg CA\CRLPeriodUnits 1
   2. Certutil -setreg CA\CRLPeriod “Weeks”
   3. Certutil -setreg CA\CRLDeltaPeriodUnits 1
   4. Certutil -setreg CA\CRLDeltaPeriod “Days”

4. To define CRL Overlap Period Units and CRL Overlap Period, run the following commands from an administrative command prompt:

   1. Certutil -setreg CA\CRLOverlapPeriodUnits 12
   2. Certutil -setreg CA\CRLOverlapPeriod “Hours”

5. 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:

   1. Certutil -setreg CA\ValidityPeriodUnits 5
   2. Certutil -setreg CA\ValidityPeriod “Years”

Configuration of CDP and AIA points

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.

Configuring AIA points

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.

Configuring the CDP Points

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



Uploading Certificates and CRLs to the Blob storage

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

• Root CA certificates
• Root CA CRL
• Issuing CA Certificates

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

1. Navigate to the storage account, and click on the pkitest you created

   

2. Click on Containers under Data Storage

   

3. Click on the pkitest folder

4. Click on Upload on the top left

   

5. Click on the browse icon and select all the files that need to be uploaded and click Open

   

6. Check to Overwrite if files already exist and then click Upload

   

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



Script to copy Issuing CA CRLs

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.

Code: https://github.com/Encryption-Consulting-LLC/AzCopyCode/blob/main/Invoke-UpdateAzureBlobPKIStorage.ps1

Github Gist to be embedded:

<script src=”https://gist.github.com/coffee-coded/4cbeb0de02628bc2da6b182dc11bad0b.js”></script>

Code Changes

1. Navigate to the storage account, and click on the pkitest you created

   

2. Click on Containers under Data Storage

   

3. Click on the pkitest folder

4. Click on Shared Access Token under Settings. Provide appropriate permissions, and choose an expiry date (preferably one year)

   

5. Click Generate SAS token and copy Blob SAS Token
6. Open the code in notepad or your preferred code editor

7. Paste the SAS token for the variable

   $azCopyDestinationSASKey

8. Navigate to properties under Settings, copy the URL and paste it for $azCopyDestination
9. Change log and log archive locations if applicable.
10. Change AzCopy location on $azCopyBinaryPath if you stored azcopy in another location.
11. Once changes are made, store them in C:\AZCopyCode\Invoke-UpdateAzureBlobPKIStorage.ps1
12. Open Powershell in CA02
13. Navigate to C:\AZCopyCode
14. Run Invoke-UpdateAzureBlobPKIStorage.ps1

15. Once copied, it will show how many files are copied, with 100% and all done with 0 Failed

    

16. Open PKIView.msc, and now no errors should be visible

    

17. The overall PKI should be healthy.

    

Troubleshooting

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

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.

Automating the script

We would automate this script using Task Scheduler to run this script every week. You can tweak this as per your requirements.

1. Open Task Scheduler

2. Left click on Task Scheduler (local) and click on Create a Basic Task

   

3. Provide name and description for the Task

   

4. Task Trigger is configured to weekly

   

5. Select Data and Time when the script will run

   

6. On Action, select Start A program and click Next

   

7. Under Start, a Program, In Program/Script write

   powershell -file "C:\AZCopyCode\Invoke-UpdateAzureBlobPKIStorage.ps1"

   

8. Click yes on the prompt

   

9. Check the Open Properties dialog and click Finish

   

10. Once completed, AZ Copy should be available in Task Scheduler Library.

    

11. Right Click AZ Copy and click Run

12. Refresh and check History Tab. Action Completed should appear in History

    

Conclusion

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