Set up a 2-tier PKI in Active Directory Certificate Services (AD CS) – Part 1
In this blog post series I want show step by step, how to setup a 2-tier PKI consisting of a standalone offline Root CA and one enterprise online subordinate CA (aka Intermediate CA). The subordinate CA (Intermediate CA) will finally issuing certificates directly to end-entities such as users, computers, and devices.
A Subordinate CA that sits between the root CA and end-entity certificates (like SSL/TLS certificates for websites) is by the way a so called Intermediate CA.
Using a standalone offline root Certificate Authority (CA) offers several advantages:
Since the root CA is offline, it’s not directly connected to any network, making it less vulnerable to cyber attacks. This reduces the risk of unauthorized access or compromise of the root CA, which is critical for ensuring the integrity and trustworthiness of the entire PKI (Public Key Infrastructure) hierarchy.
Keeping the root CA offline isolates it from potential security threats present on the network. This isolation helps maintain the integrity of the root CA’s private key, which is essential for signing certificates and establishing trust in the PKI.
In the event that a subordinate CA is compromised, having an offline root CA provides a mechanism for mitigating the impact. The offline root CA can be used to revoke the compromised subordinate CA’s certificate and issue a new one, helping to contain the damage and restore trust in the PKI.
Introduction
Active Directory Certificate Services (AD CS) is a Windows Server role for issuing and managing public key infrastructure (PKI) certificates used in secure communication and authentication protocols.
Digital certificates can be used to encrypt and digitally sign electronic documents and messages as well as for authentication of computer, user, or device accounts on a network.
AD CS gives you a cost-effective, efficient, and secure way to manage the distribution and use of certificates. In addition to binding of identities and private keys, AD CS also includes features that allow you to manage certificate enrollment and revocation.
PKI design considerations using Active Directory Certificate Services
Before creating a new PKI in your environment, it makes sense to first read the following article by Microsoft.
PKI design considerations using Active Directory Certificate Services
https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/pki-design-considerations
Plan for PKI
To ensure that your organization can take full advantage of your Active Directory Certificate Services (AD CS) installation, you must plan the PKI deployment appropriately. You should determine how many CAs you need and in what configuration before you install any CA.
For example, do you need an Enterprise Root CA or a Standalone Root CA? How will certificate approval requests be handled? How will you manage certificate revocation? Creating an appropriate PKI design can be time consuming, but it’s important for the success of your PKI
Enterprise and Standalone certification authorities
Enterprise CAs are integrated with Active Directory Domain Services (AD DS). They publish certificates and certificate revocation lists (CRLs) to AD DS. Enterprise CA’s use information that is stored in AD DS, including user accounts and security groups, to approve or deny certificate requests. Enterprise CAs use certificate templates. When a certificate is issued, the Enterprise CA uses information in the certificate template to generate a certificate with the appropriate attributes for that certificate type.
If you want to enable automated certificate approval and automatic user certificate enrollment, use Enterprise CAs to issue certificates. These features are available only when the CA infrastructure is integrated with Active Directory. Additionally, only Enterprise CAs can issue certificates that enable smart card sign-in, because this process requires that smart card certificates are mapped automatically to the user accounts in Active Directory.
Stand-alone CAs don’t require AD DS, and they don’t use certificate templates. If you use stand-alone CAs, all information about the requested certificate type must be included in the certificate request. By default, all certificate requests that are submitted to stand-alone CAs are held in a pending queue until a CA administrator approves them. You can configure stand-alone CAs to issue certificates automatically upon request, but it’s less secure and it’s not recommended because requests aren’t authenticated.
You must use stand-alone CAs to issue certificates when you’re using a non-Microsoft directory service or when AD DS isn’t available. You can use both enterprise and stand-alone certification authorities in your organization.
Root and subordinate certification authorities
Enterprise and stand-alone CAs can be configured as root CAs or as subordinate CAs. Subordinate CAs can further be configured as intermediate CAs (also referred to as a policy CA) or issuing CAs.
A root CA is the CA that is at the top of a certification hierarchy, where all certificate chains terminate. When the root CA certificate is present on the client, the root CA is trusted unconditionally. Whether you use enterprise or stand-alone CAs, you need to designate a root CA.
Since the root CA is the top CA in the certification hierarchy, the Subject field of the certificate has the same value as the Issuer field. Likewise, because the certificate chain terminates when it reaches a self-signed CA, all self-signed CAs are root CAs. The decision to designate a CA as a trusted root CA can be made at the enterprise level or locally by the individual IT administrator.
A root CA serves as the foundation upon which you base your certification authority trust model. It guarantees that the subject’s public key corresponds to the identity information shown in the subject field of the certificates it issues. Different CAs might also verify this relationship by using different standards; therefore, it’s important to understand the policies and procedures of the root certification authority before choosing to trust that authority to verify public keys.
The root CA is the most important CA in your hierarchy. If your root CA is compromised, all CAs in the hierarchy and all certificates issued from it are considered compromised. You can maximize the security of the root CA by keeping it disconnected from the network and by using subordinate CAs to issue certificates to other subordinate CAs or to end users. A disconnected root CA is also known as an Offline root CA.
CAs that aren’t root CAs are considered subordinate. The first subordinate CA in a hierarchy obtains its CA certificate from the root CA. This first subordinate CA can use this key to issue certificates that verify the integrity of another subordinate CA. These higher subordinate CAs are referred to as intermediate CAs. An intermediate CA is subordinate to a root CA, but it serves as a higher certifying authority to one or more subordinate CAs.
An intermediate CA is often referred to as a policy CA because it’s typically used to separate classes of certificates that are distinguished through policies. For example, policy separation includes the level of assurance that a CA provides or the geographical location of the CA to distinguish different end-entity populations. A policy CA can be online or offline.
Certification authority private keys
The private key is part of the CA identity, and it must be protected from compromise. Many organizations protect CA private keys by using a hardware security module (HSM). If an HSM isn’t used, the private key is stored on the CA computer.
Offline CAs should be stored in secure locations and not connected to the network. Issuing CAs use their private keys when issuing certificates, so the private key must be accessible (online) while the CA is in operation. In all cases, the CA and its private key on the CA should be physically protected.
Hardware security modules
Using a hardware security module (HSM) can enhance the security of your CA and Private Key Infrastructure (PKI).
An HSM is a dedicated hardware device that is managed separately from the operating system. HSMs provide a secure hardware store for CA keys, in addition to a dedicated cryptographic processor to accelerate signing and encrypting operations. The operating system utilizes the HSM through the CryptoAPI interfaces, and the HSM functions as a cryptographic service provider (CSP) device.
HSMs typically are PCI adapters, but they’re also available as network-based appliances, serial devices, and USB devices. If an organization plans to implement two or more CAs, you can install a single network-based HSM and share it among multiple CAs.
HSMs must be installed and configured before you set up any CAs with keys that need to be stored on the HSM.
Determine CA name
Before you configure certification authorities (CAs) in your organization, you should establish a CA naming convention.
You can create a name by using any Unicode character, but you might want to use the ANSI character set if interoperability is a concern. For example, certain types of routers aren’t able to use the Network Device Enrollment Service to enroll for certificates if the CA name contains special characters such as an underscore.
If you use non-Latin characters (such as Cyrillic, Arabic, or Chinese characters), your CA name must contain fewer than 64 characters. If you use only non-Latin characters, your CA name can be no more than 37 characters in length.
In Active Directory Domain Services (AD DS), the name that you specify when you configure a server as a CA becomes the common name of the CA. The common name is reflected in every certificate that the CA issues. For this reason, it’s important that you don’t use the fully qualified domain name for the common name of the CA. This way, malicious users who obtain a copy of a certificate can’t identify and use the fully qualified domain name of the CA to create a potential security vulnerability.
The CA name shouldn’t be identical to the name of the computer (NetBIOS or DNS name). Also, you can’t change the name of a server after Active Directory Certificate Services (AD CS) is installed without invalidating all the certificates that are issued by the CA.
To change the server name after AD CS is installed, you must uninstall the CA, change the name of the server, reinstall the CA using the same keys and modify the registry to use the existing CA keys and database. You don’t have to reinstall a CA if you rename a domain; however, you have to reconfigure the CA to support the name change.
Determine validity period
Certificate-based cryptography uses public-key cryptography to protect and sign data. Over time, attackers could obtain data that was protected with the public key and attempt to derive the private key from it. Given enough time and resources, this private key could be compromised, effectively rendering all protected data unprotected. Also the names that are guaranteed by a certificate may need to be changed over time. Because a certificate is a binding between a name and a public key, when either change, the certificate should be renewed.
Every certificate has a validity period. After the end of the validity period, the certificate is no longer considered an acceptable or usable credential.
CAs can’t issue certificates that are valid beyond their own validity period. A best practice is to renew the CA certificate when half of its validity period is expired. When installing a CA, you should plan this date and ensure that it’s recorded as a future task.
Select CA database
The certification authority’s database is a file on the hard drive. In addition to this file, other files serve as the transaction logs, and they receive all modifications to the database before the changes are made. Because these files may be accessed frequently and simultaneously, you may wish to keep the database and transaction logs on separate volumes.
The location of the certificate database and log files are kept in the following registry location:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesCertSvcConfiguration
The registry contains following values:
DBDirectoryDBLogDirectoryDBSystemDirectoryDBTempDirectory
Set up a new Domain and Domain Controller
For this blog post series about how to set up a 2-tier PKI in Active Directory Certificate Services (AD CS) I will install a complete new lab environment from the scratch starting with a domain controller for the new domain.
So I will first need to install the AD DS server role on my new domain controller as shown below.
We can already promote the server here to a domain controller by clicking on the link, or by clicking on the yellow triangle icon shown below.
To promote this server to a domain controller another wizard will shown up. You can choose here to add a new domain controller to an existing domain or a new domain to an existing forest or finally what I will do to create a new forest.
The latest forest and domain function level is as of today still Windows Server 2916 even we have installed here Windows Server 2022.
For the new forest and domain the Administrator account and password from the server we promoted to a domain controller is used for.
So we can still logon by using the Administrator account and its password from the server before we promoted it.
By the way on the screenshot above it looks like the server doesn’t have a working internet connection, the reason for is that during the promotion to a domain controller, the servers IP configuration resp. its assigned DNS servers were changed to its own loopback address 127.0.0.1 and therefore to the new installed DNS server which will be installed along with the Active Directory Domain Services.
So it can take a few seconds till this new DNS server and its service is started can resolve FQDNs into an IP address. To check if the DNS server works you can right click on the server node and switch to the Monitoring tab of the servers properties dialog. Here you can check the simple query and recursive query and click on Test Now to see if the DNS server works correctly.
In Part 2 we will see how to set up the standalone offline Root CA.
Blog Post Series – Parts Summary
Set up a 2-tier PKI in Active Directory Certificate Services (AD CS) – Part 1
Set up a 2-tier PKI in Active Directory Certificate Services (AD CS) – Part 2
Set up a 2-tier PKI in Active Directory Certificate Services (AD CS) – Part 3
Set up a 2-tier PKI in Active Directory Certificate Services (AD CS) – Part 4
Links
What is Active Directory Certificate Services?
https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/active-directory-certificate-services-overviewImplement and manage Active Directory Certificate Services
https://learn.microsoft.com/en-us/training/modules/implement-manage-active-directory-certificate-services/What is the Certification Authority Role Service?
https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/certification-authority-roleStanding up a Microsoft Certificate Authority
https://christopherkibble.com/posts/standing-up-a-microsoft-certificate-authority-part-1/What Are Subordinate CAs and Why Would You Want Your Own?
https://www.globalsign.com/en/blog/what-is-an-intermediate-or-subordinate-certificate-authority
