Before installing and configuring an Enterprise Certification Authority (CA), it’s important to understand the role and required privileges. Active Directory Certificate Services (AD CS) at the Enterprise CA level must be installed by a Domain Enterprise Admin, not just a Domain Admin.
Because we want to follow the principle of least privilege, we will temporarily promote the Server Administrator account on this server to Enterprise Admin. This will allow us to install the CA role, configure the required certificate templates, and perform initial setup tasks. Once configuration is complete, the account will be demoted back to a local administrator, ensuring day-to-day CA management is performed with minimal privileges.
Deployment Preparation & Planning
1. Server Preparation
- Install on a dedicated server, not a Domain Controller.
- Windows Server installed and fully patched.
- Static IP address assigned.
- Joined to the Active Directory domain.
- Time synchronized with domain controllers.
2. Active Directory Requirements
- A functioning AD forest with healthy replication.
- Enterprise Admin account credentials (for temporary use).
3. Certificate Authority Planning
- Determine certificate templates required (e.g., Web Server, DC Authentication, LDAPS).
- Plan enrollment permissions (restrict access to specific security groups).
4. Security Hardening Considerations
- Ensure the CA server will not host additional roles (keep it dedicated).
- Plan backup strategy for CA database and private keys.
- Limit administrative access via RBAC or security groups.
- Firewall ports required for AD CS and LDAPS should be opened.
Secure Deployment Recommendations
Why You Should Not Install Web Enrollment Services on the Enterprise CA
In a hardened Enterprise CA deployment, the Certification Authority should run only the core CA service. Web-facing components introduce unnecessary risk and should not be installed on the Enterprise CA. This includes:
- Certificate Enrollment Policy Web Service
- Certificate Enrollment Web Service
- Certification Authority Web Enrollment
- Network Device Enrollment Service (NDES)
Key Reasons
1. Minimize Attack Surface
The Enterprise CA is a Tier-0 asset, holding the private keys that secure the entire forest. Installing IIS-based enrollment services exposes the CA to additional HTTP(S) traffic and direct user interaction — both of which expand the attack surface.
2. Role Separation
The CA’s sole purpose should be to issue and manage certificates. Enrollment services such as Web Enrollment or NDES should be deployed on separate, hardened servers that act as Registration Authorities (RAs). This keeps the CA isolated and reduces the risk of compromise.
3. Protect Operational Security
If enrollment services are compromised, attackers could submit malicious requests and obtain unauthorized certificates. By keeping them separate, a compromise of the RA or web server does not expose the CA’s private key directly.
4. Use Modern Auto-Enrollment
For domain-joined devices, Group Policy certificate auto-enrollment is the recommended and most secure approach. It automates certificate issuance and renewal without relying on web services. Web enrollment should only be considered for exceptional cases (e.g., BYOD or non-domain systems) and never run on the Enterprise CA itself.
Secure Enterprise CA Deployment Plan
1. Preparation
- Verify Windows Server is fully patched, domain-joined, and on a dedicated server (!!not a Domain Controller!!).
- Confirm time sync with domain controllers.
- Ensure Enterprise Admin credentials are available for temporary elevation.
Plan to use SHA-256 (not SHA-1, not SHA-384/512 unless explicitly required).
- ✅ SHA-256 is widely supported and secure.
- ⚠️ SHA-384/512 can cause compatibility issues with older applications, devices, and services.
2. Temporary Privilege Elevation
- Temporarily promote the CA server administrator account to Enterprise Admins.
This account will only be used for:
- Installing the CA role.
- Running initial configuration.
- Removing unneeded certificate templates.
3. Install Required Role
Open “Server Manager” got to “Manage -> Add Roles and Features” leave defaults and click “Next“.
Leave Defaults and click “Next“.
Verify the Server to be installed on and click “Next“.
Select “Active Directory Certificate Services” and “Add Features” when you get the popup.
Leave defaults and click “Next“.
Leave defaults and click “Next“.
Click “Install“.
4. Configure Enterprise CA
Once install of the role is complete click “Configure Active Directory Certificate Services on the destination server“.
As outlined in Step 2, the user should be temporarily assigned the Enterprise Admin role to proceed with the configuration. In my setup, this will be done using SRV3, which is the local administrator account of the server where the installation is taking place.
Select “Certificate Authority” and click “Next“.
Select “Enterprise CA” then “Next“.
Choose “Root CA” then “Next“.
Choose “Create a new private key” then “Next“.
Set “Cryptographic provider Key Length“, “Hash” and click “Next“.
Recommended Settings:
-
Configure for SHA-256 hashing algorithm.
-
Set appropriate RSA key length:
-
2048-bit → Recommended baseline, widely compatible, good performance.
-
4096-bit → Stronger security, but may impact performance and cause compatibility issues with older apps, printers, or embedded devices.
-
Next when configuring your Certification Authority, you must assign it a CA name. ⚠️ Important: Once this name is set, it cannot be changed later.
In this example, the CA will be named: BNBC-CA
During Enterprise CA setup, you’ll be prompted to define the validity period for the CA’s certificate. This determines how long the CA’s signing certificate will remain valid before it must be renewed.
For most organizations, a validity period of 10 years is considered acceptable and is commonly chosen. This provides a balance between long-term stability and operational security:
-
Too short (e.g., 2–5 years):
-
Increases administrative overhead since the CA certificate must be renewed more frequently.
-
Can cause disruption if renewal planning is not carefully managed.
-
-
Too long (e.g., 20+ years):
-
Extends risk if cryptographic standards or algorithms are weakened over time.
-
Makes key rollover and migration more difficult.
-
✅ Recommendation: Use 10 years for an Enterprise CA unless your organization has stricter compliance or cryptographic lifecycle requirements. This is a safe default for most Active Directory environments.
Leave the defaults and click “Next“.
Once everything has been selected click “Configure” to finalize the setup.
Closing Notes
You now have a hardened Enterprise CA deployed with:
- A dedicated server (not a Domain Controller).
- SHA-256 hashing with a secure RSA key length.
- Default templates removed, ensuring only approved certificate types are introduced later.
- Least privilege enforced by demoting the setup account back to local administrator.
- Post-install validation using Locksmith and PingCastle to confirm a secure baseline.
⚠️ Important:
The default CA installation includes several vulnerable templates (such as User, Computer, and Web Server) that, if left enabled, can be abused for privilege escalation or unauthorized certificate requests.
In this setup guide, we focused only on creating a secure baseline deployment. In a follow-up series of posts, we’ll cover:
- The risks associated with default templates.
- How to configure secure alternatives (e.g., LDAPS, Web Server, Kerberos Authentication).
- Best practices for scoping templates to specific AD groups.
- Hands-on testing with Locksmith and PingCastle.
✅ With this foundation in place, your Enterprise CA is ready to support secure template deployment in the next steps of your manual.
Next Steps & Related Posts
Securing Active Directory CA: Baseline Checks and Template Cleanup
Hardening LDAPS: Creating a Secure DC-LDAPS Certificate Template