PowerShell PKI Module Guide for Microsoft ADCS Administrators

Most PowerShell PKI content falls into one of two camps: dense release-note recaps of the latest module version, or a handful of scattered one-off scripts with no organizing structure. This is neither. It’s a task-based reference built around what an AD CS administrator actually needs to do: inventory a CA hierarchy, audit templates, query certificate stores, manage CRLs, administer OCSP, and turn all of it into usable reporting, using the PSPKI module specifically, with real cmdlet names you can use today.

This connects directly to several posts in our broader AD CS series, including ADCS Certificate Chain and Topology Monitoring and AD CS Template Hardening, both of which this module makes considerably easier to execute at scale.

TL;DR: Key Takeaways

PSPKI is not the same as the built-in ADCSAdministration module: the module that ships with the AD CS role covers basic local CA administration, PSPKI is a separately installed, far more comprehensive community module covering remote CA connectivity, OCSP, templates, database queries, and ACLs.
Installation is a single PowerShell Gallery command: Install-Module PSPKI, run from an administrative workstation, no server-side installation on the CA itself is required.
Six task areas cover the vast majority of routine AD CS administration: CA inventory, certificate templates, certificate stores and database rows, CRL management, OCSP administration, and reporting, each with its own consistent set of cmdlets.
PSPKI turns manual console checks into scriptable, repeatable operations: tasks that would otherwise mean clicking through the Certification Authority console CA by CA become a single script that covers your entire hierarchy at once.
Test destructive or bulk operations in a non-production environment first, the same discipline that applies to any bulk database or configuration change applies here, PowerShell makes it easy to run an operation across many objects at once, which cuts both ways.

PSPKI vs. the Built-In ADCSAdministration Module

ADCSAdministration ships with the AD CS server role itself: cmdlets like Add-CATemplate, Add-CACrlDistributionPoint, and Backup-CARoleService cover fundamental, local CA configuration tasks, and they’re available without installing anything extra.
PSPKI is a separately installed, considerably more comprehensive module: it adds remote CA connectivity from an administrative workstation, direct OCSP responder management, certificate template ACL auditing, and direct queries against the CA database that the built-in module simply doesn’t provide.
Use ADCSAdministration for straightforward, local, single-CA configuration changes, and reach for PSPKI when you need to work across multiple CAs, audit permissions at scale, or query data the built-in module doesn’t expose at all.

Getting Started

Install from the PowerShell Gallery: Install-Module PSPKI -Scope CurrentUser, run from an administrative workstation with appropriate rights, not necessarily the CA server itself.
Import the module into your session: Import-Module PSPKI, standard practice for any PowerShell session where you’ll be running these cmdlets.
Connect to a remote CA explicitly when needed: Connect-CertificationAuthority -ComputerName <CAServerName> (alias Connect-CA) establishes the connection many other cmdlets in this guide depend on.

Task 1: CA Inventory

Discover every enterprise CA in your forest: Get-CertificationAuthority with no parameters returns every enterprise CA registered in Active Directory, a genuinely useful starting point for confirming your documented hierarchy matches reality.
Pull cryptographic configuration for a specific CA: Get-CACryptographyConfig returns the CSP or KSP provider, key length, and hash algorithm a CA is actually using, useful for auditing consistency across a hierarchy or confirming a CA’s configuration ahead of a migration.
Check overall PKI health across your topology: Get-EnterprisePKIHealthStatus is PSPKI’s scripted equivalent of the pkiview.msc console, evaluating AIA, CDP, and OCSP health across every CA it can discover, and it can be scheduled, unlike the manual console tool.
Combine these into a single inventory script, piping Get-CertificationAuthority into Get-CACryptographyConfig for each result gives you a complete configuration inventory across your entire hierarchy in one pass, rather than checking each CA individually through the console.

Task 2: Certificate Templates

List what a specific CA is actually configured to issue: Get-CATemplate returns a given CA’s current issuance list, the scripted equivalent of the certutil -CATemplates check we cover elsewhere in this series.
Modify a CA’s issuance list directly: Add-CATemplate and Remove-CATemplate add or remove templates from a CA’s issuance configuration, useful for scripted, repeatable configuration changes rather than manual console clicks.
Audit template permissions at scale: Get-CertificateTemplateAcl retrieves the access control list for a given template, and Add-CertificateTemplateAcl modifies it, scripting this across every template in Active Directory turns a manual, template-by-template permissions review into a single pass that surfaces overly permissive enrollment rights, exactly the kind of misconfiguration our template hardening guide covers in depth.
Build a standing template audit script, combining Get-CATemplate per CA with Get-CertificateTemplateAcl per template gives you a complete, current picture of what’s issuable and who can enroll against it, worth running on a recurring schedule rather than only during an incident.

Task 3: Certificate Stores and Database Rows

Query issued, pending, failed, and revoked requests directly: Get-IssuedRequest, Get-PendingRequest, Get-FailedRequest, and Get-RevokedRequest each return the corresponding category of database record, with filtering support for building targeted queries rather than pulling an entire table.
Run arbitrary custom queries against the CA database: Get-AdcsDatabaseRow (alias Get-DatabaseRow) gives you direct, flexible access to CA database content beyond the specific category cmdlets above, useful for building custom reports the standard cmdlets don’t directly support.
Remove database rows deliberately, with the same caution as any bulk deletion: Remove-AdcsDatabaseRow (alias Remove-Request) is the scripted path for the kind of cleanup we cover in depth in our database maintenance guide, apply the same safe-deletion discipline here: failed and pending requests are generally safe targets, issued certificate records need a policy decision first.
Reassociate a certificate with an orphaned local key: Import-LostCertificate supports the client-side key recovery scenario covered in our guide to recovering deleted user certificates, scripted rather than manual.

Task 4: CRL Management

Inventory CDP configuration across a CA: Get-CRLDistributionPoint (alias Get-CDP) returns a CA’s currently configured CRL distribution points, and Add-CRLDistributionPoint (alias Add-CDP) adds new ones, useful for confirming publication configuration matches your documentation across every CA in your hierarchy.
Check CRL-related configuration flags and validity periods: Get-CertificateRevocationListFlag and Get-CRLValidityPeriod return the current registry-backed configuration governing CRL behavior, scriptable rather than a manual registry check per CA.
Trigger CRL publication directly: Publish-CRL republishes a CA’s CRL on demand, useful both for routine operations and for verification after a configuration change.
Build a scripted CDP health check across your entire hierarchy, combining Get-CertificationAuthority with Get-CRLDistributionPoint per CA gives you a single report confirming every CA’s publication points are configured as expected, worth pairing with an actual retrieval check against each URL for full confidence.

Task 5: OCSP Management

Connect to an Online Responder explicitly: Connect-OnlineResponder establishes the connection other OCSP-related cmdlets depend on, parallel to how Connect-CertificationAuthority works for CA cmdlets.
Manage revocation configuration directly: Add-OnlineResponderRevocationConfiguration and Remove-OnlineResponderRevocationConfiguration manage which CAs a given responder is providing revocation status for, scriptable configuration rather than console clicks.
Restart the responder service when needed: Restart-OnlineResponder gives you a scripted restart path, useful when troubleshooting or applying a configuration change that requires a service cycle.
Manage responder-level access control: Add-OnlineResponderAcl (alias Add-OCSPACL) manages who can administer the responder itself, worth auditing with the same rigor you’d apply to CA-level permissions.
Pair this with signing certificate monitoring, PSPKI doesn’t replace the need to specifically track OCSP signing certificate expiration, covered in depth in our topology monitoring guide, but it does make querying responder configuration across multiple instances considerably faster than checking each one through its own console.

Task 6: Reporting

Export any of the above to CSV for a lightweight, shareable report: nearly every PSPKI cmdlet’s output pipes cleanly into Export-Csv, turning a one-off query into a report you can hand to an auditor or track over time.
Build a combined hierarchy report, joining CA inventory, template issuance and permissions, CDP configuration, and OCSP status into a single scheduled script gives you one artifact that reflects your entire PKI’s current state, rather than reconstructing that picture manually every time someone asks for it.
Schedule recurring reports rather than running them only reactively, a weekly or monthly export of template permissions and CA configuration gives you a change-detection baseline, differences between reports are often the fastest way to spot configuration drift.
Feed reporting output into your broader topology and DR documentation, the inventory this module produces is directly useful for the kind of topology mapping and DR artifact inventory covered elsewhere in this series, rather than being a one-off reporting exercise disconnected from that documentation.

A Note on Version and Compatibility

Confirm the module version matches your PowerShell and OS version, PSPKI has evolved across multiple major versions, and cmdlet availability and behavior can differ, check the module’s release notes against your specific environment before assuming full compatibility.
Test any bulk or destructive operation in a non-production environment first, the same discipline that applies to manual database cleanup or configuration changes applies here, scripting makes it easy to apply a change across many objects at once, which is exactly why testing matters more, not less.
Treat this module as a genuine administrative tool with real permissions, not a read-only reporting utility, many of the cmdlets covered here can modify live CA and OCSP configuration, run them with the same care you’d apply to any direct console change.

How Encryption Consulting Can Help

Building reliable, safe PowerShell automation around a real production CA hierarchy, one that covers your actual templates, CAs, and OCSP infrastructure correctly, takes both PKI domain knowledge and scripting discipline together, and getting either one wrong in an automated script scales the mistake across your entire environment at once.

Encryption Consulting’s PKI Services team supports this directly:

Custom PSPKI-based automation: building inventory, audit, and reporting scripts tailored to your specific hierarchy, templates, and compliance requirements.
Template and permission auditing: using PSPKI to systematically review certificate template ACLs across your environment for the kind of privilege escalation risk covered in our template hardening guide.
Scheduled health and compliance reporting: building recurring reports that combine CA inventory, CRL health, and OCSP status into artifacts your team and auditors can actually use.
Safe database and configuration automation, applying the same safe-operations discipline covered in our database maintenance guide to any scripted bulk operation.
PKI operations training, helping your team build genuine PowerShell PKI administration capability rather than depending on manual console work indefinitely.

If you want PowerShell automation built around your actual PKI hierarchy rather than generic scripts, our PKI Services team can build and validate it with you.

Conclusion

PSPKI turns most of the manual, console-by-console work covered elsewhere in this series, CA inventory, template auditing, CRL health checks, OCSP management, into scriptable, repeatable operations that scale across an entire hierarchy instead of one CA at a time. Start with the built-in ADCSAdministration module for simple, local configuration tasks, and reach for PSPKI when you need remote connectivity, template permission auditing, direct database queries, or OCSP administration it doesn’t cover. Test bulk operations in a non-production environment first, and build the reporting this module makes possible into a recurring practice rather than a one-time script.

Want PowerShell PKI automation built around your actual hierarchy rather than generic scripts? Talk to our PKI Services team about building and validating it. Encryption Consulting is ISO/IEC 27001:2022 and SOC 2 certified.

FAQ

What’s the difference between PSPKI and the built-in ADCSAdministration PowerShell module? ADCSAdministration ships with the AD CS server role itself and covers basic local CA administration. PSPKI is a separately installed, far more comprehensive community module that adds remote CA connectivity, OCSP responder management, certificate template auditing, direct CA database queries, and ACL management that the built-in module doesn’t provide.

How do you install the PSPKI PowerShell module? Install it from the PowerShell Gallery with Install-Module PSPKI, then load it into your session with Import-Module PSPKI. No CA server-side installation is required; PSPKI runs from an administrative workstation and connects to CAs remotely.

Can PSPKI query certificate templates a CA is configured to issue? Yes. Get-CATemplate returns the templates a specific CA is currently configured to issue, and Add-CATemplate or Remove-CATemplate change that issuance list. This is the scripted equivalent of the certutil -CATemplates issuance list check covered elsewhere in our AD CS series.

How do you check certificate template permissions with PSPKI? Get-CertificateTemplateAcl retrieves the access control list for a given template, which can be scripted across every template in Active Directory to audit for overly permissive enrollment rights, a common source of certificate template privilege escalation risk.

Can PSPKI manage Online Responder (OCSP) configuration? Yes. Connect-OnlineResponder establishes a connection to an Online Responder, and cmdlets like Get-OnlineResponderRevocationConfiguration, Add-OnlineResponderRevocationConfiguration, and Restart-OnlineResponder manage its revocation configuration and service state directly from PowerShell.