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.
HOLD UP!
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:
Use HTTP
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?
I have seen certain hardware platforms that claim to support LDAP CRLs fail – next time you look at the LDAP CRL in a certificate, take a look at the full LDAP string in the CRL Distribution point strinig and note the three slashes “ldap:///CN=xxx” – I have found some platforms can’t handle this format.
ADCS Deployment commands
Referenced Commands: https://learn.microsoft.com/en-us/powershell/module/adcsdeployment/?view=windowsserver2022-ps
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:
Module | Windows Feature |
---|---|
Install-adcscertificationauthority | Adcs-Cert-Authority |
Install-AdcsEnrollmentPolicyWebService | Adcs-Enroll-Web-Pol |
Install-AdcsEnrollmentWebService | Adcs-Enroll-Web-Svc |
Install-AdcsNetworkDeviceEnrollmentService | Adcs-Device-Enrollment |
Install-AdcsOnlineresponder | Adcs-Online-Cert |
Install-AdcsWebEnrollment | Adcs-Web-Enrollment |
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: https://learn.microsoft.com/en-us/powershell/module/adcsadministration/?view=windowsserver2022-ps
Command | Description |
---|---|
Add-CAAuthorityInformationAccess | Configures the AIA or OCSP for a certification authority. |
Add-CACrlDistributionPoint | Adds a CRL distribution point URI where AD CS publishes certification revocations. |
Add-CATemplate | Adds a certificate template to the CA. |
Backup-CARoleService | Backs up the CA database and private key information. |
Confirm-CAEndorsementKeyInfo | Checks whether the local CA trusts secure hardware for key attestation. |
Get-CAAuthorityInformationAccess | Gets the AIA and OCSP URI information set on the AIA extension of the CA properties. |
Get-CACrlDistributionPoint | Gets all the locations set on the CDP extension of the CA properties. |
Get-CATemplate | Gets the list of templates set on the CA for issuance of certificates. |
Remove-CAAuthorityInformationAccess | Removes AIA or OCSP URI from the AIA extension set on the certification authority. |
Remove-CACrlDistributionPoint | Removes the URI for the CRL distribution point (CDP) from the CA. |
Remove-CATemplate | Removes the templates from the CA which were set for issuance of certificates. |
Restore-CARoleService | Restores 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 "http://company.com/crl/<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
https://learn.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/server-certs/server-certificate-deployment – The latest round of CA deployment instructions.
https://www.sysadmins.lv/blog-en/default.aspx – Vadims’ wonderful historical blog containing all things PKI. You can catch more recent articles over at the PKI Solutions Blog
https://learn.microsoft.com/en-us/archive/blogs/paranoidhumanoid/ – Chris Ayres’ blog on PKI – Whilst this is a little old, he had a great article on Disaster recovery there which seems to have been deleted. Here’s an extract on that from some time back here
https://mssec.wordpress.com/2014/02/20/configure-ad-cs-to-use-a-static-dcom-port/ – An article outlining how to set up ADCS to use a static DCOM port (spoiler alert: it will still need port 135 available)
https://learn.microsoft.com/en-us/archive/blogs/askds/how-to-configure-the-windows-server-2008-ca-web-enrollment-proxy – 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 can still be quite relevant today.