Should You Install Certificate Authority on a Domain Controller? PKI Design Best Practices 

One question I still hear regularly from IT pros planning a new rollout is whether it’s acceptable to install a certificate authority (CA) on a domain controller. 

The short answer is yes. Microsoft fully supports installing Active Directory Certificate Services on a domain controller, and the setup process doesn’t prevent you from doing so. However, the more important question isn’t whether you can, but whether you should. 

In many environments, particularly those with long-term security, compliance, and scalability requirements, separating certificate authority (CA) and domain controller (DC) roles is considered a best practice. Not to mention that many an ‘IT Pro’ will tell you not to install anything on a DC. That said, there are situations where combining the roles may be reasonable. 

Let’s look at the tradeoffs and the architecture choices that make the most sense for modern Windows environments. 

Can you install certificate authority on a domain controller? 

Absolutely. Microsoft supports installing the Certificate Authority (CA) role service on a domain controller. And many organizations have done so over the years. In fact, smaller companies frequently deploy their first Enterprise CA directly on an existing DC because it’s readily available and already integrated with Active Directory. 

From a technical perspective, AD CS works perfectly well on a domain controller. Certificate templates, auto-enrollment, certificate publication, and Active Directory integration all function normally. 

The fact that Microsoft supports the configuration often leads administrators to assume it is the preferred approach. That’s not necessarily the case. Supportability and best practice aren’t always the same thing. 

Why Microsoft allows you to install a certificate authority on a domain controller 

There are several practical reasons Microsoft continues to support this deployment model. 

First, AD CS is tightly integrated with Active Directory. Enterprise CAs publish information to AD and they rely on domain services for many PKI-related functions. Installing the CA on a domain controller simplifies some aspects of deployment and management. 

Second, many smaller organizations have limited server resources. Small businesses, branch offices, and lab environments often don’t have the budget or operational need for dedicated PKI servers. 

Finally, Microsoft recognizes that different organizations have different requirements. For some environments, consolidating infrastructure roles is a reasonable compromise that reduces cost and administrative overhead. 

The key point is that Microsoft’s support for the configuration doesn’t automatically make it the best design choice for every environment. 

Combining the roles concentrates security risk 

A certification authority is not just another Windows role: it can establish trust for users, computers, applications, VPN connections, wireless authentication, smart cards, and web servers. A domain controller is equally critical because it holds domain authority and provides core authentication services. Hosting both roles on one server places two high-value trust functions inside the same security boundary. 

The configuration is supported and is not inherently insecure. However, if an attacker compromises a server hosting both the CA and DC roles, they potentially gain access to: 

• Active Directory credentials 

• Domain authentication services 

• The CA private keys 

• Certificate issuance capabilities 

• Certificate revocation management 

That combination changes the incident from a domain compromise or a CA compromise into both at once. An attacker may be able to alter directory identities and permissions while also using CA private-key material or issuance rights to create certificates that support unauthorized authentication or persistence. 

A practical containment decision is therefore harder. Simply isolating and rebuilding the domain controller does not restore confidence in certificates already issued by the CA. Conversely, restoring the CA from backup does not establish that the directory used to authorize enrollment is trustworthy.  

Responders must preserve evidence, stop certificate issuance, protect or replace CA keys, determine which certificates may have been fraudulently issued, restore Active Directory from a known-good state, and plan revocation and re-enrollment before returning dependent services to normal operation. 

Separating the roles limits the blast radius and lets the organization rebuild domain services without automatically inheriting uncertainty about the CA private key. If the CA key itself is suspected of compromise, trust recovery may require replacing the issuing CA certificate and key, revoking affected certificates, publishing updated revocation information, and reissuing certificates to users, devices, and services—not merely restoring the server. 

Separate the roles when independent recovery matters 

Security is only half of the design decision. Combining the roles also couples two recovery timelines that may have different priorities, dependencies, and evidence-preservation requirements. 

Consider a production failure in which the organization’s sole issuing CA runs on a domain controller that suffers an unrecoverable operating-system or storage failure. Other domain controllers may keep sign-in and directory services available, but the CA is offline at the same moment administrators begin restoring or rebuilding the failed DC. 

Existing certificates may continue to work while their chains and cached revocation data remain valid and reachable. The operational gap appears when a certificate must be revoked urgently, a certificate expires, a new server or user must enroll, or an authentication service depends on fresh revocation information. VPN, Wi-Fi, smart-card, device, or TLS services can then become part of the recovery path even though their own servers did not fail. 

The team must now coordinate two distinct recoveries and verify more than a normal domain-controller rebuild: 

• CA database backups 

• CA private keys 

• Certificate revocation lists (CRLs) 

• Authority Information Access (AIA) configuration 

• CA-specific restoration procedures 

A safe sequence is to preserve the failed system and its backups, confirm that another domain controller can provide healthy AD DS and DNS services, and restore the CA only from known-good CA backups that include the database, private key and certificate, configuration, and publication settings. Administrators must also verify that AIA and CRL distribution locations remain reachable, publish current revocation data if necessary, and test enrollment and certificate validation before declaring recovery complete. 

The key decision is whether the business can tolerate certificate operations being unavailable for the duration of AD restoration. With a dedicated issuing CA, the CA can continue issuing, revoking, and publishing while the failed domain controller is rebuilt.  

With a combined server, recovery of one trust service can block or complicate recovery of the other, so the recovery plan must define service priorities, backup ownership, temporary controls, and the point at which certificate-dependent services can safely resume. 

When combining the roles is reasonable 

Use one dividing line: combining the roles can be reasonable when certificate use is limited, and infrastructure constraints justify it. Use a dedicated issuing CA when certificates support important authentication or services, recovery independence matters, or compliance requires role separation. 

Small organizations 

A combined Enterprise CA and domain controller can be a proportionate choice when the environment has: 

• One or two domain controllers 

• Limited IT staff 

• Minimal compliance requirements 

• Internal certificate usage only 

In this case, accept the tradeoff explicitly: maintain separate, tested backups of the CA database and private key, keep revocation locations available, and document a recovery sequence for both roles. 

Mid-sized organizations 

Move to a dedicated issuing CA when certificate use expands beyond basic internal TLS or when an outage would interrupt network access, remote access, device enrollment, or other business services. 

Typical signals include: 

• Several domain controllers or sites 

• Growing auto-enrollment or certificate volume 

• VPN, Wi-Fi, Network Policy Server, or device authentication 

• A requirement to recover AD DS and PKI independently 

The practical default is a domain-joined, dedicated issuing CA with regular CA backups and hardened administrative access. 

Enterprise organizations 

Use a separated PKI architecture: an offline standalone root CA, one or more dedicated enterprise issuing CAs, protected key storage where appropriate, distinct administrative roles, and tested procedures for revocation, key replacement, and recovery. At this scale, role separation is a trust and resilience requirement rather than an infrastructure preference. 

Offline root CA versus enterprise issuing CA 

One of the most widely accepted PKI designs is a two-tier hierarchy. 

Offline root CA 

The root CA sits at the top of the trust hierarchy. 

Best practice is to: 

• Keep it offline 

• Power it on only when needed 

• Avoid domain joining it 

• Restrict access tightly 

• Use it only for signing subordinate CA certificates and publishing CRLs 

Because the root CA rarely operates, the attack surface remains extremely small. 

Enterprise issuing CA 

The issuing CA handles day-to-day certificate operations. 

This server: 

• Is typically domain-joined 

• Publishes certificates 

• Processes enrollment requests 

• Supports auto-enrollment 

• Integrates directly with Active Directory 

In larger environments, issuing CAs are often dedicated servers separate from domain controllers. 

This model provides a practical balance between security, manageability, and operational efficiency. 

What if your CA already runs on a domain controller? 

If you’ve inherited an environment where AD CS runs on a domain controller, don’t panic. Many such deployments operate reliably for years. 

The first step is evaluating business requirements and risk. 

Ask questions such as: 

• Is the CA actively used for critical services? 

• Does the organization have compliance obligations? 

• Are there plans to expand certificate-based authentication? 

• Does the current server present a security concern? 

If separation makes sense, migrating the CA to a dedicated server is entirely possible. Microsoft supports CA migration procedures that preserve the CA database, certificates, configuration, and private keys. 

Many organizations perform this migration during hardware refresh cycles or broader infrastructure modernization projects. 

The important thing is to approach the move as a planned PKI project rather than treating it as a simple role migration. 

Final thoughts 

Installing AD CS on a domain controller is supported, common, and sometimes entirely appropriate. For small organizations with limited resources, combining the roles may be a practical decision that keeps infrastructure simple. 

However, if you’re designing a PKI from scratch, I generally recommend separating CA and domain controller functions whenever possible. A certification authority represents one of the most trusted security components in the environment, and treating it as dedicated infrastructure provides meaningful benefits in security, operational flexibility, and disaster recovery. 

In my experience, the question isn’t whether AD CS can run on a domain controller. The better question is whether you’ll still be happy with that decision three, five, or ten years from now as your PKI environment grows. For most organizations, a dedicated CA architecture is the design that ages the best. 

Frequently asked questions