Introduction
A Microsoft Certificate Authority (CA) is one of the most critical components in an enterprise PKI environment. It is responsible for issuing, enrolling, revoking, and renewing digital certificates that support various use cases, including user and device authentication, data encryption, identity management, and secure communications (SS/TLS). CA installation and administration cannot be treated as one-time deployment task. CA is not a set and forget it requires continuous monitoring, periodic validation and controlled cleanup with regular health checkups to remain operational over time without disrupting certificate services. Microsoft’s Active Directory Certificate Service (ADCS) tooling supports this through backup, restore, database management, CRL publication, template review, and database cleanup operations.
CA issues certificates over an extended period of time, could be days, months or years without any visible issue. However, in the background, the CA database steadily grows as it retains records of failed requests, denied requests, revoked certificates, expired certificates, and outdated CRL-related entries. Since these records are not automatically cleaned up, they accumulate over months and years, increasing the size of the database and the amount of stale data administrators must work through during troubleshooting or audits.
In one Microsoft case study, a customer’s CA database had grown to unexpectedly large proportions over many months without the administrators noticing. The issue only came to light when the database had consumed nearly all of the 55 GB partition on which it was hosted. In that instance, a Windows Server Enterprise CA database had exceeded 50 GB in size and was still growing, highlighting how easily unchecked accumulation can turn into a serious operational concern.
At Encryption Consulting, we treat PKI maintenance as more than a simple housekeeping service. Before you start deleting failed requests from the database, you should ensure that a valid and recent backup of the CA database is available so that the system can be restored if needed. Next, validate that the database paths and storage location are correctly configured and have sufficient space. Cleanup activities should then be carried out in a controlled manner, removing only obsolete or unnecessary records such as expired or failed requests.
Once the cleanup is complete, the database should be compacted to reclaim space and improve performance. Finally, it is essential to validate that core CA functions, including CRL publication and certificate revocation, continue to operate correctly after the maintenance activity and are available.
PKI Maintenance
The first and most important step for PKI Maintenance is making sure you have a proper backup. You should never start cleaning up the CA database without having a rollback point, so that if something goes wrong, you can restore the system.
Now, Microsoft ADCS allows you to back up different parts of the CA separately, and this is where people often get confused:
- A database-only backup includes the CA database and logs. This is usually enough for routine tasks like quarterly cleanup, because you’re only modifying database records.
- A full CA backup is much broader. It includes the CA database and logs, the CA certificate and private key, and related CA configuration data such as registry settings
The distinction is important because a database backup alone cannot fully restore the CA in the event of an outage; it only helps you roll back database changes.
There is another critical point when Hardware Security Modules (HSMs) are involved. If your CA private key is stored in an HSM, you cannot back it up like a normal software key. Instead, you must follow the specific backup process defined by the HSM vendor (like Luna or nShield). Ignoring this can lead to a situation where the CA cannot be recovered.
A CA being “healthy” is beyond than issuing certificates it also depends on whether clients can trust and validate those certificates. In simple terms, when a certificate is issued, clients do not just accept it blindly. They check:
- Whether the certificate has been revoked (via CRL/OCSP → CDP locations)
- Who issued the certificate and how to build the chain (via AIA locations)
So even if your CA is issuing certificates perfectly, it is not truly operational if these supporting services are broken or unreachable. That’s why maintenance should also include, checking that CRL Distribution Points (CDP) are accessible, ensuring Authority Information Access (AIA) URLs are correct and reachable, and verifying that revocation data is being published and updated properly.
A simple and effective way to do this in Microsoft environments is using pkiview.msc, on Issuing CA, which gives a quick health view of your PKI. It shows whether CDP/AIA URLs are reachable, it flags expired or missing CRLs, it highlights any chain or publication issues
In Microsoft ADCS environments, the certutil -deleterow command provides targeted cleanup options depending on the type of data being removed. For e.g., request cleanup focuses on failed or pending requests and is typically based on when those requests were submitted, while certificate cleanup applies to expired or revoked certificates and is based on their expiration dates. This distinction is important because cleanup should be deliberate and guided by defined retention policies, ensuring that only unnecessary records are removed without affecting important audit or operational data.
Finally, once the cleanup is complete, the certificate database may require compaction to reclaim unused space. For this purpose, the esentutl /d command is used to perform an offline defragmentation and compaction of the ESE (Extensible Storage Engine) database. This step is particularly important after removing stale or outdated records, as it reorganizes the database and reduces its physical size. As a result, it helps improve performance, optimize storage usage, and leaves the CA database in a cleaner and more efficient state.
Importance of Quarterly cleanup
Quarterly cleanup provides a practical and balanced approach to CA administration. It is frequent enough to prevent long-term database buildup over time, yet controlled enough to align with a controlled maintenance process that includes review, backup, execution, and post-change validation. Instead of waiting for the CA database to become overly large or difficult to manage, administrators can regularly remove data that is no longer operationally relevant while preserving a rollback point for the maintenance window.
Quarterly maintenance also helps you stay disciplined about backups and recovery. Before you start any cleanup, you should take a fresh backup of the CA so it accurately reflects the current state of the database. If you rely on an older backup, it may no longer match the latest changes, making it less useful for recovery. So in practice, the safest approach is to take a backup right before you begin cleanup, this gives you a reliable rollback point in case anything goes wrong during the maintenance activity.
A Practical Quarterly Cleanup Process for Microsoft CA
A practical quarterly cleanup process for Microsoft CA should follow a defined and repeatable sequence to ensure database maintenance is carried out safely, with a clear rollback point established before any changes are made and proper validation completed after the activity concludes.
Step 1: Perform pre-cleanup checks
Before starting the activity, administrators should review the health of the Issuing CA and confirm that sufficient disk space is available on the server. This is important because both backup and offline database compaction require working space. If the CA is hosted in a virtual environment, taking a VM snapshot can provide an additional rollback safeguard, subject to the organization’s operational standards.
Step 2: Take a pre-maintenance CA database backup
Once the environment has been prepared, the next step is to back up the CA database before any records are deleted. This can be done from the Certification Authority console by right-clicking the CA, selecting the backup option, and choosing only certificate database and certificate database log for this maintenance task. This should be treated as a database backup for maintenance rollback, not as a full CA backup. If a full CA backup is required, the CA certificate and private key must also be backed up separately.
This step is critical because it establishes the rollback point for the cleanup activity.
Step 3: Run the cleanup script or certutil-based cleanup process
After the backup has been taken, the cleanup process can be executed on the Issuing CA. At this stage, the administrator should run the approved EC’s PowerShell script or cleanup command set and provide the cutoff date up to which records should be removed.
To delete expired certificates:
certutil -deleterow <Date> Cert
To delete failed certificates:
certutil -deleterow <Date> Request
To delete revoked certificates:
certutil -deleterow "ExpiredRevokedCerts"
The process should be designed to first identify matching records, display the total count, and then require explicit confirmation before deletion begins. This is an important measure because Microsoft CA cleanup is record-type specific. Request cleanup targets failed and pending requests, while certificate cleanup targets expired and revoked certificate records. Because of this, the administrator should confirm exactly what is being deleted before proceeding.
Step 4: Review cleanup completion and prepare for database maintenance
After the deletion process has completed successfully, the next stage is to prepare for database maintenance. At this point, the cleanup of stale rows may have reduced the logical content of the CA database, but the physical database file may still remain larger than necessary. To reclaim unused space, offline database compaction should be performed.
Before that happens, the administrator should ensure that the cleanup process has fully completed and no other maintenance actions are in progress on the CA.
Step 5: Stop AD CS
The Active Directory Certificate Services service should then be stopped before any offline database operation is performed. This is a required part of the maintenance process because database compaction must not be performed while the CA database is actively in use.
Stopping AD CS ensures that the database remains in a stable state while the maintenance activity continues.
Step 6: Confirm the CA database path
Once the service has been stopped, the administrator should confirm the exact location of the certificate database file from the CA properties rather than relying on an assumed default path. This can be done by opening the Certification Authority console, right-clicking the CA, selecting Properties, and then navigating to the Storage tab.
In many environments, the certificate database is stored under:
C:\Windows\System32\CertLog
However, the actual EDB file name depends on the CA name. In the example environment, the database file is:
Encon Issuing CA.edb
Validating the live database path at this stage helps avoid running maintenance against the wrong file.
Step 7: Perform offline database compaction
After confirming the correct EDB file path, the administrator should navigate to the certificate database directory and run offline compaction using esentutl /d.
Example:
esentutl /d "C:\Windows\System32\CertLog\Encon Issuing CA.edb"
This step defragments and compacts the CA database after stale records have been removed. It is especially useful when a significant number of failed, expired, or revoked records have been deleted, as it helps reclaim unused database space and improves database hygiene.
Step 8: Take a fresh post-maintenance backup
Once compaction has completed successfully, a new backup of the CA database should be taken. This becomes the new clean recovery point after maintenance and preserves the post-cleanup, post-compaction state of the CA database.
This step is just as important as the pre-cleanup backup because it captures the CA in its updated and maintained state.
Step 9: Restart AD CS
After the post-maintenance backup has been completed, the Active Directory Certificate Services service should be started again. The administrator should confirm that the CA service starts normally and that there are no immediate errors related to the database, certificate services, or publication functions.
Step 10: Perform post-maintenance validation
The final step is validation. After the CA has been brought back online, administrators should confirm that the CA is functioning normally, that certificate services are healthy, and that publication points remain valid. This should include checking AIA and CDP health through pkiview.msc, reviewing the CA console, and confirming that the maintenance activity has not affected normal CA operations.
Quarterly cleanup should only be considered complete once the CA has been cleaned, compacted, backed up again, restarted successfully, and validated operationally.
How can Encryption Consulting Help?
Managing a Microsoft CA goes well beyond initial deployment. It demands continuous attention to database health, backup discipline, CRL publication, and regular validation activities that many organizations struggle to maintain consistently alongside their day-to-day operations. This is exactly where Encryption Consulting brings value.
Our PKI Assessment Services provide a comprehensive evaluation of your existing ADCS environment, identifying gaps in CA hygiene, backup practices, CRL/AIA configuration, and database health. Whether your CA database has grown unchecked over time or your maintenance processes lack structure, our team delivers a detailed risk report along with a prioritized roadmap to bring your PKI back into a healthy and auditable state.
For organizations that need ongoing support rather than a one-time review, our PKI Support Services offer subscription-based, round-the-clock assistance. This includes proactive CA maintenance, CRL monitoring, troubleshooting database issues, and guided quarterly cleanup execution, ensuring that your CA environment stays clean, compact, and operationally reliable without burdening your internal teams.
Conclusion
Quarterly CA cleanup should not be approached as a simple deletion exercise. It is a controlled PKI maintenance activity that combines backup discipline, careful record cleanup, offline database maintenance, and post-change validation. When done properly, it improves database hygiene, keeps CA administration manageable, and supports a stronger long-term operational posture for Microsoft PKI.
For organizations running Microsoft AD CS, the best results come from treating maintenance as part of the overall PKI governance model. Backup should be deliberate, cleanup should be retention-aware, database maintenance should be performed carefully, and every maintenance cycle should end with verification that the CA is healthy and revocation publication remains intact. That is what turns routine maintenance into a reliable and repeatable PKI operational practice.
