Can You Install AD CS on a Domain Controller? PKI Security, Recovery and Migration Risks

Below is what Reinders recommends, what Microsoft's own documentation says, and what you need to check if your CA already runs on a DC.

The short answer, and a caveat​

Reinders' position: putting the two roles on one server is supported and common, and sometimes it's the right call. If you're designing a PKI from scratch, though, he recommends keeping the CA and the domain controller on separate servers wherever you can.

Microsoft's AD CS documentation on Learn doesn't say "put it on a DC" or "never put it on a DC." The current guide to installing the Certification Authority says only that the target computer must be joined to a domain where AD DS is installed. It installs the role with Install-WindowsFeature -Name ADCS-Cert-Authority -IncludeManagementTools and configures an Enterprise Root CA with Install-AdcsCertificationAuthority -CAType EnterpriseRootCA. That guide covers Windows Server 2016 through 2025, and it describes a domain-joined server, not specifically a DC. So the claim that the setup is supported rests on long-standing practice and on the fact that setup allows it. The docs don't explicitly endorse it.

People who work in this area are blunter. One Windows Server deployment guide calls it technically possible to run AD CS on the same server as a Domain Controller, but this is very bad practice and can have some unintended consequences if there is ever an issue with it. SecureW2, which sells certificate management, argues that putting AD CS on a DC complicates decommissioning, OS upgrades, and system recovery. That vendor has a stake in the answer, but the operational point stands.

Section summary: Setup allows it, admins have done it for years, and Microsoft's documentation stays neutral. Separating the roles is the advice you'll hear from nearly everyone who designs PKI for a living.

Why it's done anyway​

Reinders gives three reasons the combined setup keeps appearing:

• Tight AD integration. Enterprise CAs depend heavily on the directory. Microsoft's Certification Authority role documentation says Enterprise CAs publish certificates and certificate revocation lists (CRLs) to AD DS and check user accounts and security groups before approving or denying requests. Only Enterprise CAs can issue smart-card sign-in certificates, because those must be mapped automatically to AD user accounts.
• Limited hardware. Small businesses, branch offices and labs often can't justify a dedicated PKI server.
• Different needs. For some organizations, putting roles together is a reasonable trade for lower cost and less admin work.

This is how many small businesses end up with "DC01 is also our CA": a consultant needed LDAPS or an internal TLS certificate one afternoon, and the domain controller was the only server available.

Two key servers in one box​

Here's the security argument. A CA can vouch for users, computers, VPN connections, Wi-Fi authentication, smart cards and web servers. A domain controller holds the directory and handles authentication. Put both on one server and, as Reinders notes, a single compromise can expose:

• Active Directory credentials
• Domain authentication services
• The CA's private keys
• The ability to issue certificates
• Control over certificate revocation

Microsoft's guide to securing domain controllers explains how serious the first half of that list is. Someone with privileged access to a DC can modify, corrupt or destroy the AD DS database. Microsoft says a forest can't be trusted again after a DC compromise unless it's recovered from a known-good backup and the security gaps are closed. Microsoft's AD CS guidance on securing and delegating CA administration covers the other half: a CA can create credentials the whole environment trusts, so one over-privileged or compromised admin account can both weaken CA policy and issue certificates.

Combine the two and incident response gets much harder. Reinders points out that rebuilding the DC doesn't make certificates the CA already issued trustworthy again. Restoring the CA from backup doesn't prove the directory it uses to approve requests is clean. Responders have to:

• Preserve evidence and stop certificate issuance.
• Protect or replace the CA keys.
• Work out which certificates may have been issued fraudulently.
• Restore AD from a known-good state.
• Plan revocation and re-enrollment before bringing dependent services back.

Separate servers don't make a CA secure on their own, and Microsoft's CA guidance is clear that host hardening, named admin accounts and controlled access to backups still matter. What separation does is limit the damage. If attackers get one server, you aren't automatically rebuilding the other.

The same logic applies to other roles sharing a box. In a Microsoft Q&A thread about putting a CA on a WSUS server instead, MVP Vadims Podāns pointed out that WSUS brings IIS with it, and if server is compromissed via IIS (to be more precise, via vulnerable or miconfigured web app), then CA is compromised too. Moving the CA off the DC doesn't help much if it lands on another busy, exposed server.

Section summary: The CA and the DC are each a top-value target. Put them on one server and an attacker who gets in owns both identity systems at once.

Recovery: two jobs tied together​

Security is only half the case. Reinders' failure scenario: your only issuing CA runs on a DC that suffers an unrecoverable OS or storage failure. Other DCs keep sign-ins working, but the CA goes down at the same moment you start rebuilding the DC.

Existing certificates may keep working for a while, as long as their chains and cached revocation data stay valid and reachable. Problems start when someone needs an urgent revocation, a certificate expires, a new device needs to enroll, or a service needs fresh revocation data. Then VPN, Wi-Fi, smart-card and TLS services get dragged into the outage even though their own servers are fine.

Microsoft's PKI design guidance explains why. The Authority Information Access (AIA) and CRL distribution point (CDP) locations are written into every certificate a CA issues. Microsoft warns that failures to verify certificate chains or revocation status can cause failed VPN connections and failed smart-card sign-ins. Changing a CDP URL only affects new certificates. Older ones keep pointing at the original location, so Microsoft says to settle these locations before the CA issues anything.

Reinders recommends this recovery order:

• Preserve the failed system and its backups.
• Confirm that another DC is serving healthy AD DS and DNS.
• Restore the CA only from known-good backups that include the database, the private key and certificate, the configuration and the publication settings.
• Check that AIA and CRL locations are reachable, and publish fresh revocation data if needed.
• Test enrollment and certificate validation before you call the recovery finished.

Ask yourself one question: can the business live without certificate operations for as long as an AD restore takes? A dedicated issuing CA keeps issuing, revoking and publishing while you rebuild the DC.

Where to draw the line​

Reinders proposes a size-based framework. It's his practical advice, not a Microsoft requirement, since Microsoft's documentation sets no size thresholds.

If you're a small shop keeping the combined setup, accept the risk on purpose. Keep separate, tested backups of the CA database and private key, keep revocation locations available, and write down a recovery order for both roles.

The two-tier design matches Microsoft's own guidance. Microsoft says that if the root CA is compromised, every CA and certificate below it is compromised too. It recommends keeping the root disconnected from the network, known as an offline root, and letting subordinate CAs handle day-to-day issuance. Microsoft also notes that many organizations protect CA keys with a hardware security module (HSM). Without one, the private key is stored on the CA server itself, which on a combined server means on the domain controller.

Moving a CA off a DC​

You don't need to panic if you've inherited a combined server. Reinders says many run fine for years. Start by asking a few questions. Does the CA support critical services? Do you have compliance obligations? Do you plan to expand certificate-based authentication?

If you decide to separate the roles, treat it as a PKI project, not a quick role move. Microsoft's migration documentation shows how much is involved:

• Back up more than the database. Microsoft's list includes the CA database, the private key or keys, the CA registry settings, CAPolicy.inf and, on Enterprise CAs, the list of assigned templates. If an HSM holds the key, follow the HSM vendor's backup procedure.
• Record your templates by hand. Microsoft's guide to moving a CA notes that template settings live in Active Directory and are not included in the backup, so you have to reassign them on the new CA. The migration guide uses certutil -setcatemplates for this.
• Publish a long-lived CRL first. Microsoft recommends publishing a CRL whose validity period covers the whole planned migration, so clients can keep validating certificates during the move.
• Follow the removal order. Microsoft says to remove the CA role from the source server after the backup and before installing it on the destination. Removing it later deletes AD configuration data that the new CA, which shares the same common name, depends on.
• Watch for old hostnames in CDP paths. By default, CDP extensions include the CA's hostname, so certificates issued before the move may point to the old server. Microsoft says the new CA must publish CRLs to both the old and new paths to avoid revocation-check errors.
• Edit the registry export before importing it. Some values belong to the CA, while others belong to the old host, domain or Windows version. Microsoft advises reviewing the exported .reg file and removing anything that shouldn't carry over.

Watch the CDP point closely when the CA is on a DC. Certificates issued by "DC01" may contain DC01's name in their CDP paths for years, and the migration has to keep those paths working.

Section summary: Migration is supported and well documented. The tricky parts are the pieces outside the database: templates, registry settings, CRL validity and old hostnames inside certificates you've already issued.

Bottom line​

Reinders' closing test is worth borrowing: will you still be happy with this decision in three, five or ten years? For a small lab or a small business that only needs internal TLS, a combined DC and CA is a defensible shortcut if the backups are tested and the recovery steps are written down. Once certificates support VPN, Wi-Fi, smart cards or device authentication, a dedicated issuing CA, and an offline root as you grow, is easier to defend, easier to recover and easier to upgrade.

The real question is whether you're prepared to rebuild both roles at once when that server fails or gets compromised.

Correction (October 19, 2026): Fixed a character-encoding error in the name of PKI expert Vadims Podāns, which had rendered as "Pod??ns".