OCSP Revocation Configuration Management with PSPKI

OCSP configuration has a specific way of failing: quietly. A signing certificate that doesn’t renew correctly, a configuration change made on the wrong array member and silently overwritten at the next sync, a revocation setting that drifted from what every other responder in the array has, none of these throw an obvious error, they just make revocation checking subtly wrong for whoever happens to hit the affected responder. This guide covers how to inventory, validate, and detect drift in OCSP configuration using PSPKI, specifically, with the safety notes that matter before you run anything that changes live configuration.

This is a deeper follow-up to our PowerShell PKI Module Guide for Microsoft ADCS Administrators, and it connects directly to the OCSP-specific trust breakpoints covered in ADCS Certificate Chain and Topology Monitoring.

TL;DR: Key Takeaways

Read-only queries are always safe, configuration changes are not: anything starting with Get- is safe to run against production at any time. Anything starting with Set-, Add-, or Remove- changes live OCSP configuration and needs testing first.
Array controller versus array member matters more than it looks: configuration changes made directly on an array member rather than the controller can be silently overwritten during the next synchronization cycle, with no error to tell you it happened.
Adding a server to an array is destructive, not additive: it removes the server from its current array, deletes its existing revocation configurations entirely, and replaces them with the new array’s configuration. This is not a safe operation to run without understanding that first.
There are exactly three OCSP signing certificate strategies: same-CA automatic enrollment, delegated-CA automatic enrollment (the RFC 5019 pattern), and manual out-of-band assignment, each with different things to monitor.
Configuration drift is only detectable if you’re actually comparing against a baseline: a one-time health check tells you today’s state, recurring, compared exports are what actually catch drift before it becomes an outage.

Safety Notes Before You Run Anything

Every script and cmdlet in this guide falls into one of two categories: read-only or configuration-changing: know which category you’re working with before you run anything against a production Online Responder.
Read-only cmdlets, Get-OnlineResponderRevocationConfiguration, Connect-OnlineResponder, Get-EnterprisePKIHealthStatus, are safe to run at any time, they query existing state and don’t modify anything.
Configuration-changing cmdlets need testing against a non-production Online Responder first, without exception: Set-OnlineResponderRevocationConfiguration, Add-OnlineResponderRevocationConfiguration, Add-OnlineResponderArrayMember, and similar cmdlets modify live configuration that active clients are depending on for revocation checking right now.
Make configuration changes on the array controller, not a member, covered in more depth below, this single habit avoids one of the most common and confusing OCSP configuration problems.
Treat Add-OnlineResponderArrayMember as a destructive operation specifically, it removes existing revocation configurations from the server being added, this is by design, but it’s easy to run without realizing the full effect until it’s already happened.

Inventorying OCSP Responders and Arrays

Connect to a responder to begin any query or configuration work: Connect-OnlineResponder -ComputerName <ResponderName> establishes the connection that other OCSP cmdlets in this guide depend on.
Identify array membership and role explicitly, don’t assume: confirm whether a given responder is the array controller or a member before making any configuration change, since that distinction determines whether your change will actually persist.
Run a broader PKI health check alongside your OCSP-specific inventory: Get-EnterprisePKIHealthStatus, covered in our broader PSPKI guide, gives you AIA and CDP context alongside OCSP status, useful for seeing OCSP health in the context of the CA it serves rather than in isolation.

Validating Revocation Configuration

Retrieve current revocation configuration with Get-OnlineResponderRevocationConfiguration, this is your primary read-only inspection point, returning the settings tied to a specific CA’s revocation configuration on a given responder.
Understand which of three signing certificate strategies is in use for each configuration: automatic enrollment from the same Enterprise CA the configuration serves, automatic enrollment from a different, delegated CA following the RFC 5019 pattern, or manual, out-of-band signing certificate assignment. Each has different renewal behavior and different things worth monitoring.
Confirm the signing strategy actually matches your documented design, a configuration quietly using manual assignment when your documentation says automatic enrollment (or the reverse) is exactly the kind of drift that’s invisible until a signing certificate expires with nobody watching for it.
Add new revocation configuration only after this planning is deliberate, not ad hoc, Add-OnlineResponderRevocationConfiguration -OnlineResponder $responder -Name <ConfigName> -CertificationAuthority $ca creates a new configuration, and Microsoft’s own guidance on this is explicit that this action should be executed on the array controller specifically, not a member.

Signing Certificates: What to Check and Why

Check the signing certificate template and hash algorithm for automatic-enrollment configurations: Set-OnlineResponderRevocationConfiguration‘s -SigningCertTemplate and -HashAlgorithm parameters control this, confirming they’re set to what you expect is a basic, worthwhile validation step.
Watch for the “Bad Signing on Array Controller” status specifically, this is a real, documented status that shows up when the signing certificate’s cryptographic operations aren’t correctly authorized, commonly resolved by confirming credential prompting behavior for the signing certificate’s private key operations rather than assuming certificate reissuance is needed.
Confirm reminder duration is configured to give you real lead time, -ReminderDuration controls how far ahead of signing certificate expiration you’re warned, this setting existing at all is a strong signal that signing certificate expiration is a genuinely common failure mode, worth taking seriously rather than leaving at a default you haven’t actually reviewed.
Tie signing certificate monitoring back to your broader topology visibility, an OCSP responder can be otherwise perfectly healthy while its signing certificate quietly approaches expiration, the exact trust breakpoint pattern covered in our topology monitoring guide.

Revocation Settings and CRL Retrieval Configuration

Confirm Base and Delta CRL URLs are correctly configured for each revocation configuration: -BaseCrlUrl and -DeltaCrlUrl control where the Online Responder actually fetches the CRL data it uses to determine revocation status, a responder with correct signing configuration but a broken CRL retrieval URL still returns wrong or stale answers.
Check retrieval timeout settings against your actual network conditions: -CrlUrlTimeout and -RefreshTimeout govern how long the responder waits before giving up on a CRL fetch, defaults that work fine on a fast internal network may not be appropriate for a responder retrieving CRLs across a slower link.
Know where serial number tracking data lives: -SerialNumbersDirectory specifies the UNC or local paths used to track issued certificate serial numbers, worth confirming this points to a location that’s actually current and accessible.
Use local CRL entries deliberately, as an exception mechanism, not routine practice: Add-OnlineResponderLocalCrlEntry lets you manually mark specific serial numbers as revoked directly on the responder, outside the normal CRL retrieval path, this is useful for emergency revocation scenarios but should be a documented exception, not a habit that quietly diverges from your CA’s actual CRL over time.

OCSP Arrays: The Controller/Member Gotcha

Understand the controller/member relationship before touching array configuration: an Online Responder array has one controller and one or more members, and members periodically synchronize their configuration from the controller, not the other way around.
Make configuration changes on the controller, every time, without exception: a change applied directly to a member can be silently overwritten the next time that member synchronizes with the controller, producing a change that appears to work immediately and then quietly reverts with no error logged anywhere obvious.
Understand exactly what happens when you add a server to an array: Add-OnlineResponderArrayMember removes the target server from whatever array it currently belongs to, removes all of its existing revocation configurations, and copies over the configurations from the new array’s controller instead. This is a genuinely destructive operation on the server being added, test it against a non-production responder first, and don’t run it against a production array member expecting it to simply “join” without consequence.
Promote a new array controller deliberately, not as an afterthought: Set-OnlineResponderProperty supports promoting a specified responder to the array controller role, this is a meaningful operational change worth planning and documenting, not something to do reactively during an incident if you can avoid it.

Detecting Configuration Drift

Export current configuration on a recurring schedule, not just once: a single health check tells you today’s state, drift detection requires comparing today’s export against a previous baseline to see what actually changed.
Include signing certificate details, revocation settings, and array membership in every export, drift can show up in any of these independently, a signing certificate that silently switched strategies, a CRL URL that changed, or a responder that unexpectedly shows a different array controller than last time.
Pay particular attention to differences that show up on array members specifically, given the synchronization behavior covered above, a member showing configuration that doesn’t match its controller is either mid-sync or a sign that something is genuinely wrong, worth investigating either way rather than assuming it will self-correct.
Treat any unexpected difference as an investigation trigger, not noise to filter out, configuration drift in OCSP infrastructure specifically tends to be invisible until it causes a revocation-checking failure, catching it during a routine comparison is considerably better than catching it during an incident.

How Encryption Consulting Can Help

OCSP configuration touches signing certificates, array synchronization behavior, and CRL retrieval settings all at once, and a mistake in any one of them tends to surface as a subtle, hard-to-diagnose revocation-checking problem rather than an obvious outage.

Encryption Consulting’s PKI Services team supports this directly:

OCSP configuration audit: reviewing your responder arrays, signing certificate strategies, and revocation settings against what your documentation actually says should be configured.
Array architecture review: confirming your controller/member setup is correctly designed and that your team understands the synchronization behavior before it causes a confusing configuration problem.
Drift detection tooling: building scheduled, PSPKI-based configuration exports and comparison scripts tailored to your specific OCSP infrastructure.
Safe change validation: testing configuration-changing scripts, including array membership changes, in a non-production environment before they touch anything live.
Signing certificate monitoring setup, so expiration and strategy drift are caught well ahead of time rather than discovered when revocation checking starts failing.

If your OCSP infrastructure hasn’t had a configuration audit recently, or you want drift detection built around your actual array setup, our PKI Services team can help.

Conclusion

OCSP configuration problems rarely announce themselves, a signing certificate strategy that drifted from what you documented, a change applied to the wrong array member and silently overwritten, a CRL retrieval setting nobody’s checked since it was configured. PSPKI gives you the tooling to inventory, validate, and detect drift in all of this, but the tooling only helps if you respect the safety boundaries: read-only queries anytime, configuration changes tested first, changes applied to the array controller specifically, and array membership changes treated as the destructive operations they actually are.

Want your OCSP configuration audited or real drift detection built for your array? Talk to our PKI Services team about an OCSP configuration review. Encryption Consulting is ISO/IEC 27001:2022 and SOC 2 certified.

FAQ

What are the three ways an OCSP signing certificate can be assigned in AD CS? Automatic enrollment from the same Enterprise CA the revocation configuration is for; automatic enrollment from a different, delegated CA following the RFC 5019 pattern; or manual, out-of-band assignment of a signing certificate. Each strategy has different renewal and monitoring implications.

Why should revocation configuration changes only be made on the OCSP array controller? Because array members periodically synchronize their configuration from the array controller. A change made directly on a member rather than the controller can be silently overwritten during the next synchronization cycle, making the change appear to disappear without any error.

Is adding a server to an OCSP responder array a safe, non-destructive operation? No. Adding a server to a new Online Responder array removes it from its existing array, removes all of its existing revocation configurations, and replaces them with the configurations copied from the new array’s controller. Treat this as a destructive operation and test it in a non-production environment first.

Which PSPKI OCSP cmdlets are safe to run without prior testing? Read-only cmdlets like Get-OnlineResponderRevocationConfiguration and Get-EnterprisePKIHealthStatus are safe to run at any time since they only query existing configuration. Any Set-, Add-, or Remove- cmdlet changes live OCSP configuration and should be tested against a non-production Online Responder before running in production.

How can PowerShell help detect OCSP configuration drift? By exporting revocation configuration, signing certificate details, and array membership on a recurring schedule and comparing each export against the previous baseline. An unexpected difference, especially on an array member rather than the controller, is a strong signal worth investigating rather than dismissing.