ADCS Powershell commands

Posted by & filed under , , .

In this post we explore some of the nifty CLI (read: Powershell) based commands that can be used when interacting with an ADCS deployment. These commands are all fully documented over at Microsoft, but I find them hard to locate at times.


I can almost hear a couple of MVPs yelling from here! Before you go ahead and deploy your CAs, please make sure you have documented and planned your architecture.

In any case, before you deploy your CAs, you should also make sure you have made any necessary adjustments needed in your CAPolicy.inf file – take a look at the latest round of documentation here at Microsoft for more information on a CAPolicy.inf file – depending on your requirements, you might actually not need one; but it’s best to review now, before you go ahead and build your environment – Measure twice; cut once.

Don’t publish LDAP CRLs… Ever.

Many seem to yell this loudly from the rooftops stating that it has been the case since 2008, but the only reference I can find as to why is outlined here in a document that is no-longer easy to find over at Microsoft land:


Although AD DS enables publication of CRLs to all domain controllers in the forest, we recommend implementing HTTP instead of LDAP for revocation information publication. Only HTTP enables the use of the ETag and Cache-Control: Max-age headers providing better support for proxies and more timely revocation information. In addition, HTTP provides better heterogeneous support as HTTP is supported by most Linux, UNIX, and network device clients

If this is the case, why do all ADCS deployments including Server 2016 include an LDAP CRL?

ADCS Deployment commands

Referenced Commands:

Installing a CA via Powershell

Let’s start off with the basics. We can deploy a CA using a powershell command-let, but first you’ll need to make it available by running the following commands:

Import-module ServerManager
Add-WindowsFeature Adcs-Cert-Authority -includeManagementTools

Once this has been executed, we can make use of the Install-AdcsCertificationAuthority cmdlet.
To build a Standalone Root CA with the Microsoft software KSP

Install-Adcs-CertificationAuthority -CAType StandaloneRootCA -CryptoProvderName "RSA#Microsoft Software Key Storage Provider" -KeyLength 4096 -HashAlogrythm SHA256 -CaCommonName "Your Root CA Name"

NOTE: If you were using an HSM or some other cryptographic provider, obviously you’d need to update the CryptoProviderName accordingly. This is a simple demonstration here – not intended for a prodcution system.

Each of the ADCS roles can be installed in this way. If you wanted to install Web Policy Server, you’d run the Install-AdcsWebEnrollment command. If the module has not been added as a feature, you’d also need to Add-WindowsFeature Adcs-Web-Enrollment

If you want to see more details examples of deployment commands, take a look here. For ease of reference, the table below outlines all the deployment commands in one place (along with the associated Windows feature that needs to be installed:

ModuleWindows Feature

A note on multiple instances of Enrollment Web Policy Services

I have not found this documented anywhere: It is possible to install multiple Enrollment Web Policy instances on a single server – but only via Powershell. If you use the GUI to perform an install, only one instance is possible.


ADCS Administration commands

Referenced Commands:

Add-CAAuthorityInformationAccessConfigures the AIA or OCSP for a certification authority.
Add-CACrlDistributionPointAdds a CRL distribution point URI where AD CS publishes certification revocations.

Adds a certificate template to the CA.
Backup-CARoleServiceBacks up the CA database and private key information.
Confirm-CAEndorsementKeyInfoChecks whether the local CA trusts secure hardware for key attestation.
Get-CAAuthorityInformationAccessGets the AIA and OCSP URI information set on the AIA extension of the CA properties.
Get-CACrlDistributionPointGets all the locations set on the CDP extension of the CA properties.
Get-CATemplateGets the list of templates set on the CA for issuance of certificates.
Remove-CAAuthorityInformationAccessRemoves AIA or OCSP URI from the AIA extension set on the certification authority.
Remove-CACrlDistributionPointRemoves the URI for the CRL distribution point (CDP) from the CA.
Remove-CATemplateRemoves the templates from the CA which were set for issuance of certificates.
Restore-CARoleServiceRestores the CA database and private key information.

Working with CDPs (CRLs)

By default, a number of default CDPs are published to a newly created CA. Using the CA Administration commands, it is possible to manipulate these entries. Unfortunately, CDPs must be either removed or added using the CA Administration Commandlets – there is no option to modify.

For example, if the desired result is to remove all HTTP and LDAP based CDPs, we could issue the following command:

Get-CACrlDistributionPoint | ?{$_.uri -like "http*" -or $_.uri -like "ldap*"} | Remove-CACrlDistributionPoint -force

In the example below, we create an HTTP CDP.

Add-CACrlDistributionPoint -Uri "<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl" -AddToCrlIdp:$false -AddToFreshestCrl:$true -AddToCertificateCdp:$true -Confirm -Force

Well that's about it for this post for now. See you next post!

Further reading – ADCS PKI – The latest round of CA deployment instructions. – Vadims’ wonderful blog containing all things PKI. – Chris Ayres’ blog on PKI – Whilst this is a little old, he has a great article on Disaster recovery. – An article outlining how to set up ADCS to use a static DCOM port (spoiler alert: it will still need port 135 available) – A nice article showing how to set up a Web Policy Proxy Server (where the web server is split away from the CA Service onto another machine)

Some of the linked sites are aging, but they are still quite relevant today.

Leave a Reply

Your email address will not be published. Required fields are marked *