
Installation and Configuration of Active Directory Certificate Services (ADCS)
This guide will provide you with detailed steps on Installing and Configuring of the Microsoft Certificate Authority (Active Directory Certificate Service) in an Enterprise.
Table of Contents
Prerequisites
-
Windows Server (Root CA): A server joined to your Active Directory Domain (e.g.,
corp.local
). This can be a Domain Controller or a member server or a standalone laptop. For production, a standalone laptop is often recommended for security, however a member server or a non-domain joined VM can also work. Do not share server roles as this expands the attack surface area. - Windows Servers (ISSUING CA): Two servers joined to your Active Directory Domain (e.g.,
corp.local
). Each Server at different geographic location (ex: 1 at prod and the other at DR site) Do not share server roles as this expands the attack surface area. - Windows Servers (CRL/AIA): Two servers joined to your Active Directory Domain (e.g.,
corp.local
). Each Server at different geographic location (ex: 1 at prod and the other at DR site). -
Permissions: You must be logged in as a user who is a member of the Enterprise Admins group. Many configuration steps require this high level of privilege.
-
Static IP Address: The server should have a static IP address configured.
-
Server Name: Choose a meaningful name for your CA server (e.g.,
ORG-NAME-ROOT-CA
). Changing it after AD CS is installed is complex and not recommended.
Phase 1: Installation of the ROOT CA AD CS Role
-
Open Server Manager: Log in to your Windows Server and launch Server Manager.
-
Add Roles and Features:
-
Click on Manage > Add Roles and Features.
-
The wizard will open. Click Next until you reach the Server Roles section.
-
-
Select Server Role:
-
Scroll down and check the box for Active Directory Certificate Services.
-
A pop-up will appear listing additional tools that are required. Click Add Features, then click Next.
-
-
Features: Click Next (no additional features are needed at this stage).
-
AD CS Introduction: Read the information and click Next.
-
Role Services:
-
This is the most critical step. You are selecting the components of AD CS to install.
-
For a basic Enterprise Root CA, select Certification Authority
-
Click Next.
-
-
Confirmation: Review your selections and check Restart the destination server automatically if required. Click Install.
-
Wait for Installation: The role files will be installed. Do not close the wizard. Once complete, click the Configure Active Directory Certificate Services on the destination server link near the top.
Phase 2: Configuration of ROOT Certificate Authority (ADCS)
The AD CS Configuration Wizard will now launch.
-
Credentials: The displayed credentials should be your Enterprise Admin account. Click Next.
-
Role Services: Select the same services you chose to install (Certification Authority and Certification Authority Web Enrollment). Click Next.
-
Setup Type:
-
Select Enterprise CA. (An Enterprise CA integrates with AD; a Standalone CA does not).
-
Click Next.
-
-
CA Type:
-
Select Root CA (this is the first CA in your hierarchy and trusts itself).
-
Click Next.
-
-
Private Key:
-
Select Create a new private key.
-
Click Next.
-
-
Cryptography:
-
Select a cryptographic provider: RSA#Microsoft Software Key Storage Provider is fine for most.
-
Key length: 2048 bits is the minimum recommended. 4096 is more secure but has a performance impact.
-
Hash algorithm: SHA256 is the current standard. Do not use SHA1.
-
Click Next.
-
-
CA Name:
-
The Common name for this CA is critical. Use a meaningful name like
CORP-CA-ROOT
. This name will be in every certificate it issues. -
The Distinguished name will populate automatically. Note the preview.
-
Click Next.
-
-
Validity Period:
-
For a Root CA, set a long validity period (e.g., 10 years). The Root CA’s certificate must be valid for all certificates it issues to be trusted. Due to Post Quantum Cryptography – setting this to expire by 2035 and using a PQC safe algorithm should be tracked as a roadmap.
-
Click Next.
-
-
Certificate Database:
-
Accept the default locations unless you have a specific reason to change them (e.g., performance or storage constraints).
-
Click Next.
-
-
Confirmation: Review all settings carefully. Click Configure.
-
Results: Wait for the configuration to complete. You should see “Configuration succeeded” for all components. Click Close.
Your Root CA is now installed and configured.
The next step is to configure CRL/AIA onto the webservers to ensure that if the ROOT-CA is not an Enterprise CA, we are able to resolve these files via the ISSUING-CA and confirm the validity of the Signed Certs.
Phase 3: Preparation on the CRL/AIA Web Server (Corp-CRL-WebServer
)
Before configuring the CA, set up the infrastructure that will host the files.
1. Create Network Share and Local Folder
-
On
Corp-CRL-WebServer
, create a folder that will be shared and also used for the website (e.g.,C:\PKI
) - Create a new service account SVC-PKI-CRL that will be used to copy the AIA-CRL files onto the CRL Webserver from the Certificate Authorities
-
Share this folder:
-
Right-click the folder -> Properties -> Sharing tab -> Advanced Sharing.
-
Check Share this folder. Share name is auto-filled (e.g.,
PKI
). -
Click Permissions and ensure
Everyone
orDomain Computers
has Read access. Click OK. - Click Permissions and ensure SVC-PKI-CRL has write permissions to it
-
-
Set NTFS Permissions:
-
Go to the Security tab of the folder properties.
-
Ensure the following principals have Read & Execute, List folder contents, and Read permissions:
-
Everyone
-
Authenticated Users
-
-
Ensure the following principals have Read & Write, Execute, List folder contents, and Read permissions:
-
SVC-PKI-CRL
-
-
(This double-layer of share + NTFS permissions is crucial for access).
-
2. Configure IIS for HTTP Access
-
Open IIS Manager.
-
Ensure you have a website (e.g.,
Default Web Site
) running. -
Create a Virtual Directory (This is the best practice):
-
Right-click on your website -> Add Virtual Directory.
-
Alias: Enter
pki
. (This will be part of the URL, e.g.,http://Corp-CRL-WebServer/pki
). -
Physical path: Browse to the folder you created (
C:\PKI
). -
Click OK.
-
-
Set Permissions on the Virtual Directory:
-
In the Features View for the new
pki
virtual directory, double-click Directory Browsing. -
In the right-hand Actions pane, click Enable. This is important so clients can browse to and download the CRL files.
-
Phase 4: CRL/AIA Configuration on the CA
Now, go to your CA server.
1. Open the Certification Authority Console
-
Press
Win + R
, typecertsrv.msc
, and press Enter.
2. Configure the CRL Distribution Point (CDP)
-
Right-click on your CA server name -> Properties.
-
Go to the Extensions tab.
-
In the Select extension dropdown, choose CRL Distribution Point (CDP).
-
You will see a list of existing locations. These are mostly
file://
paths for local publishing. -
Add a new HTTP URL:
-
Click Add.
-
Enter the URL pointing to your web server:
http://Corp-CRL-WebServer/pki/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
(See explanation in the box below) -
A good, standard entry is:
http://Corp-CRL-WebServer/pki/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
-
Click OK.
-
-
Critical Steps for CDP:
-
Select the new HTTP URL in the list.
-
Check the boxes for: Include in all CRLs. Specifies where to publish in the CRL. and Include in the CDP extension of issued certificates. This puts the URL into every certificate the CA issues.
-
Uncheck the box for Include in CRLs. Clients use this to find Delta CRL locations. for this HTTP entry. (Delta CRLs are advanced and often use the same location, but keeping it simple is best for a root).
-
-
Modify the existing
file://
locations:-
For each existing
file://
path, select it and ensure Publish CRLs to this location and Publish Delta CRLs to this location are checked. This ensures new CRLs are still written to the local disk for you to manually copy to the web server or you setup a Scheduled Job running under theSVC-PKI-CRL
service account (you may need to update local-policy to allow this account to run-as a batch) or alternatively, use File-transfer to copy files from the CA to the Webservers.
-
URL Variable Explanation:
<CaName>
: Resolves to the CA’s name, sanitized for URLs (e.g.,CORP-ROOT-CA
).
<CRLNameSuffix>
: Resolves to the CRL suffix (often nothing for the base CRL).
<DeltaCRLAllowed>
: Will be blank for the base CRL, or+
for a delta CRL.Using these variables ensures the URL dynamically builds the correct filename (e.g.,
http://Corp-CRL-WebServer/pki/CORP-ROOT-CA.crl
).
3. Configure the Authority Information Access (AIA)
-
In the same Extensions tab, from the Select extension dropdown, choose Authority Information Access (AIA).
-
You will see existing locations, typically a
ldap://
path and afile://
path. -
Add a new HTTP URL:
-
Click Add.
-
Enter the URL:
http://Corp-CRL-WebServer/pki/<ServerDNSName>_<CaName><CertificateName>.crt
(See explanation in the box below) -
A good, standard entry is:
http://Corp-CRL-WebServer/pki/<ServerDNSName>_<CaName><CertificateName>.crt
-
Click OK.
-
-
Critical Steps for AIA:
-
Select the new HTTP URL.
-
Check the box for Include in the AIA extension of issued certificates. This is the most important one—it tells clients where to find the CA’s certificate to build the chain.
-
Uncheck Include in the online certificate status protocol (OCSP) extension. (OCSP is for a different, advanced revocation service).
-
-
Modify the existing
file://
location:-
Select it and ensure Add to certificate AIA extension is unchecked. You typically don’t want the local file path in issued certificates.
-
Ensure Save the certificate to this location is checked so the CA certificate is still published to a local file for you to copy.
-
URL Variable Explanation for AIA:
<ServerDNSName>
: The DNS name of the CA server.
<CaName>
: The name of the CA.
<CertificateName>
: The name of the certificate file.This will resolve to something like:
http://Corp-CRL-WebServer/pki/rootca.corp.local_CORP-ROOT-CA.crt
-
Apply Changes:
-
Click Apply. You will be prompted that the CA needs to be restarted for changes to take effect and that you must generate a new CRL. Click OK and then OK again to close the properties window.
-
The CA service will restart.
-
Phase 5: Publishing and Testing CRL/AIA
The CA is now configured to write files locally and tell clients to look for them on the web server. You must now manually copy the files and test.
1. Manually Publish the Files
-
On your CA, generate a new CRL:
-
In
certsrv.msc
, right-click on the Revoked Certificates folder -> All Tasks -> Publish. -
Select New CRL and click OK.
-
-
Copy the required files from the Root CA to the web server’s folder (
C:\PKI
onCorp-CRL-WebServer
):-
Root CA Certificate: Located at
C:\Windows\System32\Certsrv\CertEnroll\<YourRootCAName>.crt
(e.g.,CORP-ROOT-CA.crt
). -
Base CRL File: Located at
C:\Windows\System32\Certsrv\CertEnroll\<YourRootCAName>.crl
(e.g.,CORP-ROOT-CA.crl
). -
Copy these files to the
C:\PKI
folder onCorp-CRL-WebServer
.
-
2. Test the Configuration
-
From a domain-joined client machine, open a web browser.
-
Test the AIA URL: Try to navigate to
http://Corp-CRL-WebServer/pki/CORP-ROOT-CA.crt
. You should be prompted to download the Root CA certificate. -
Test the CDP URL: Try to navigate to
http://Corp-CRL-WebServer/pki/CORP-ROOT-CA.crl
. You should be prompted to download the CRL file. -
Test with a Certificate:
-
Open the Certificates MMC snap-in for the local computer.
-
Find a certificate issued by your Root CA (or import one for testing).
-
Double-click the certificate -> Certification Path tab. Select the Root CA certificate in the path and click View Certificate.
-
Go to the Details tab and look for the CRL Distribution Points and Authority Information Access extensions. You should see your new HTTP URLs listed there.
-
Your Root CA’s revocation and chain-building information is now publicly accessible to all clients on your network. Remember, every time you publish a new CRL from the CA, you must manually copy the new .crl
file to the web server or as suggested transfer to a network mapped drive via scheduled job or use FTP.
Phase 6: Installation of the ISSUING CA – AD CS Role on the Subordinate Server
-
Open Server Manager on your designated subordinate server (e.g.,
CORP-ISSUING-CA01
). -
Add Roles and Features:
-
Click on Manage > Add Roles and Features.
-
Click Next until you reach the Server Roles section.
-
-
Select Server Role:
-
Check the box for Active Directory Certificate Services.
-
Click Add Features in the pop-up window, then click Next.
-
-
Features: Click Next.
-
AD CS Introduction: Click Next.
-
Role Services:
-
Select Certification Authority. (You can add Certification Authority Web Enrollment later if needed).
-
Click Next.
-
-
Confirmation: Review your selections and check Restart the destination server automatically if required. Click Install.
-
Wait for Installation: Once the role is installed, click the Configure Active Directory Certificate Services on the destination server link.
Phase 7: Configuration of the Subordinate CA
The AD CS Configuration Wizard will launch.
-
Credentials: Ensure you are using an Enterprise Admin account. Click Next.
-
Role Services: Select Certification Authority. Click Next.
-
Setup Type:
-
Select Enterprise CA. Click Next.
-
-
CA Type:
-
This is the key difference. Select Subordinate CA. Click Next.
-
-
Private Key:
-
Select Create a new private key. Click Next.
-
-
Cryptography:
-
Choose your cryptographic provider, key length (e.g., 2048), and hash algorithm (e.g., SHA256). Click Next.
-
-
CA Name:
-
Enter a meaningful Common name for this CA, such as
CORP-SUBCA01-ISSUING
. -
Note the Distinguished name. Click Next.
-
-
Certificate Request:
-
This is the most critical step for a Subordinate CA. You must generate a request file to send to your Root CA.
-
Select Save a certificate request to file and manually send it to the parent CA.
-
Note the path to the request file (e.g.,
C:\subca01_request.req
). You will need this file. Click Next.
-
-
Certificate Database: Accept the defaults. Click Next.
-
Confirmation: Review all settings. Click Configure.
-
Results: The configuration will run, but it will pause because the Subordinate CA does not yet have a certificate from its parent. Click Close.
Your Subordinate CA is now installed but cannot function yet. Its service will be stopped.
Phase 8: Obtaining the Certificate from the Parent (Root) CA
Now you must take the request file (subca01_request.req
) to your Root CA to be signed.
On the Root CA Server:
-
Open the Certification Authority console (
certsrv.msc
). -
In the left pane, right-click on your Root CA server name, navigate to All Tasks, and select Submit new request….
-
Navigate to the request file you generated on the Subordinate CA (
subca01_request.req
). You may need to copy this file to the Root CA via USB drive or network share (if the Root is online). -
Once submitted, the request will appear in the Pending Requests folder.
-
Issue the Certificate:
-
Go to the Pending Requests folder, right-click on the request, and select All Tasks -> Issue.
-
-
Retrieve the Certificate:
-
Go to the Issued Certificates folder.
-
Find the newly issued certificate (it will have the Subordinate CA’s name you provided).
-
Double-click the certificate to open it.
-
Go to the Details tab and click Copy to File….
-
-
Certificate Export Wizard:
-
Click Next.
-
Select Base-64 encoded X.509 (.CER). This is the correct format. Click Next.
-
Browse to a location to save the file (e.g.,
C:\subca01_cert.cer
). Give it a descriptive name. -
Click Next, then Finish. You should see a success message.
-
-
Export the Root CA Certificate (Optional but Recommended):
-
While on the Root CA, it’s efficient to also export the Root CA’s own certificate.
-
In
certsrv.msc
, right-click your Root CA server name and select Properties. -
Go to the General tab. Select the top certificate in the list (the Root CA certificate).
-
Click View Certificate, then go to the Details tab.
-
Click Copy to File… and export it as a Base-64 encoded X.509 (.CER) file (e.g.,
C:\rootca_cert.cer
).
-
Copy both the subca01_cert.cer
and the rootca_cert.cer
files back to your Subordinate CA server.
Phase 9: Finalizing the Subordinate CA Installation
Now, return to your Subordinate CA server (CORP-ISSUING-CA01
).
-
Open the Certification Authority console (
certsrv.msc
). You will see a red circle on the CA icon indicating it’s stopped. -
Complete the Installation:
-
Right-click on the server name and select All Tasks -> Install CA Certificate….
-
Browse to the certificate file you obtained from the Root CA (
subca01_cert.cer
). -
Select it and click Open.
-
-
Start the Service:
-
Right-click on the server name again and select All Tasks -> Start Service.
-
The red circle should turn into a green play arrow, indicating the service is running.
-
-
Install the Root CA Certificate into the Trusted Store (Critical):
-
The Subordinate CA must trust its own parent. You must import the Root CA certificate into the computer’s Trusted Root store.
-
Press
Win + R
, typemmc.exe
, and press Enter. -
Go to File -> Add/Remove Snap-in….
-
Select Certificates from the left list and click Add.
-
Select Computer account, click Next, then Finish, and finally OK.
-
In the MMC console, expand Certificates (Local Computer) -> Trusted Root Certification Authorities -> Certificates.
-
Right-click on the Certificates folder and select All Tasks -> Import….
-
Follow the wizard to import the
rootca_cert.cer
file you exported. Place it in the Trusted Root Certification Authorities store.
-
Your Subordinate CA is now fully operational and ready to issue certificates.
Phase-7: Post-Configuration Tasks
-
Publish Subordinate CA to Active Directory (Optional but Recommended):
-
On the Subordinate CA, open an elevated command prompt.
-
Run the following command:
bashcertutil -dspublish -f "C:\path\to\subca01_cert.cer" SubCA
(Replace the path with the actual location of your Subordinate CA’s
.cer
file). -
This publishes the Subordinate CA’s certificate to the AIAContainer and CDPContainer in AD, making it available to all domain members.
-
-
Configure Certificate Templates:
-
You can now go to the Subordinate CA console (
certsrv.msc
), right-click Certificate Templates, and select New > Certificate Template to Issue. -
Choose the templates you want this issuing CA to manage (e.g., Web Server, User, Computer).
-
-
Update Group Policy:
-
If you previously created a GPO to distribute the Root CA certificate (as in the first guide), you should add the Subordinate CA’s certificate to that same GPO.
-
Edit the GPO and navigate to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Public Key Policies.
-
Right-click on Intermediate Certification Authorities and select Import.
-
Import the
subca01_cert.cer
file. This helps clients build the certificate chain more efficiently.
-
Your PKI hierarchy is now complete: Offline Root CA -> Online Enterprise Subordinate (Issuing) CA. You now request all certificates from the Subordinate CA, and they will chain back to the trusted Root CA.
Phase 10: Setting Up Certificate Templates
Certificate Templates define the properties and purposes of certificates that can be issued.
-
Open the Certificate Templates Console:
-
Press
Win + R
, typecertsrv.msc
, and press Enter. This opens the Certification Authority console. -
In the left pane, expand your server name and click on Certificate Templates. You will see a list of default templates.
- Delete all of the Default templates as we will be creating new modern templates.
-
-
Duplicate and Configure a New Template (Example: Web Server SSL Certificate):
-
Right-click on the Web Server template and select Duplicate Template.
-
A properties window will open.
-
General Tab: Give the new template a descriptive name (e.g.,
CORP-TLS-Web Server
). Decrease the Validity period (1 Year or less) and Renewal period as needed. -
Subject Name Tab: Ensure Supply in the request is selected. This allows the requester (e.g., a web admin) to specify the exact subject name (like the website URL).
-
Extensions Tab:
-
Edit Application Policies and ensure Server Authentication is present.
-
Edit Key Usage and ensure it includes Digital Signature and Key Encipherment.
-
-
Security Tab: This is where you assign permissions.
-
Click Add and find the group or user who should be allowed to request this certificate (e.g., a security group named
Web Server Admins
). It’s highly recommended that this should be restricted to PKI Admins or limited to PKI Trust Manager service-account for automation. -
Select that group and grant it Read and Enroll permissions.
-
Remove Enroll permissions from other groups if necessary for least privilege.
-
-
Click OK. Your new template is now created.
-
-
Issue the New Template:
-
Back in the
certsrv.msc
console, right-click on Certificate Templates > New > Certificate Template to Issue. -
Select your new template (
Web Server - Custom
) from the list and click OK. It is now available for enrollment.
-
This completes the guide on Installation and Configuration of the Microsoft CA (Active Directory Certificate Authority) as a two-tier architecture that provides redundancy and scalability. You may add additional ISSUING-CAs or make it even 3-tier where required.