How to Setup Active Directory Certificate Services (PKI) in Azure, AWS, GCP (Certificate Authority)
To setup and install Active Directory Certificate Services IaaS on any of the cloud platforms (Azure, AWS, GCP) use our virtual machine template solution to get up and running quickly. This virtual machine offering will allow you to build a new Root Certificate Authority or a Subordinate Certificate Authority to establish a PKI hierarchy within Azure, AWS or GCP.
Active Directory Certificate Services
- Build a new PKI hierarchy or setup a Subordinate CA to an already established PKI hierarchy
- Deploy internal certificates to your users or devices
- Integrate with Active Directory Group Policies to deploy certificates to users or devices
- Key Attestation now supports the use of Smart Card Key Storage Providers
- Network Device Enrollment Service (NDES)
- Online Certificate Status Protocol (OCSP)
- Use the existing endpoint identity information that exists in AD to register for certificates (to avoid re-registering)
- Configure AD Group Policies to dictate which users and machines are allowed which types of certificates
- Automate Certificate Provisioning and Lifecycle Management
Cloud PKI
Setup AD Certificate Services in Azure
Setup AD Certificate Services on AWS
Setup AD Certificate Services in GCP
Table of Contents
Active Directory Certificate Services PKI Planning
When designing your PKI solution (certificate authority) you will have to determine the hierarchy that you will use.
There are generally three types of hierarchies, and they are denoted by the number of tiers.
Single/One Tier PKI Hierarchy
A single tier Hierarchy consists of one CA. The single CA is both a Root CA and an Issuing CA.
A Root CA is the term for the trust anchor of the PKI. Any applications, users, or computers that trust the Root CA trust any certificates issued by the CA hierarchy. The Issuing CA is a CA that issues certificates to end entities. For security reasons, these two roles are normally separated.
When using a single tier hierarchy they are combined. This may be sufficient for simple implementations where ease of manageability and lower cost outweigh the need for greater levels of security or flexibility.
Two Tier PKI Hierarchy
A two tier hierarchy is a design that meets most company’s needs. In some ways it is a compromise between the One and Three Tier hierarchies.
In this design there is a Root CA that is offline, and a subordinate issuing CA that is online. The level of security is increased because the Root CA and Issuing CA roles are separated. But more importantly the Root CA is offline, and so the private key of the Root CA is better protected from compromise. It also increases scalability and flexibility. This is due to the fact that there can be multiple Issuing CA’s that are subordinate to the Root CA.
This allows you to have CA’s in different geographical locations (Azure regions or Subscriptions or Vnets etc), as well as with different security levels. Manageability is slightly increased since the Root CA has to be brought online to sign CRL’s.
Three Tier PKI Hierarchy
Specifically the difference between a Two Tier Hierarchy is that second tier is placed between the Root CA and the issuing CA.
The placement of this CA can be for a couple different reasons. The first reason would be to use the second tier CA as a Policy CA. In other words the Policy CA is configured to issue certificates to the Issuing CA that is restricted in what type of certificates it issues. The Policy CA can also just be used as an administrative boundary. In other words, you only issue certain certificates from subordinates of the Policy CA, and perform a certain level of verification before issuing certificates, but the policy is only enforced from an administrative not technical perspective.
The other reason to have the second tier added is so that if you need to revoke a number of CAs due to a key compromise, you can perform it at the Second Tier level, leaving other “branches from the root” available. It should be noted that Second Tier CAs in this hierarchy can, like the Root, be kept offline.
Following the paradigm, security increases with the addition of a Tier, and flexibility and scalability increase due to the increased design options. On the other hand, manageability increases as there are a larger number of CAs in the hierarchy to manage.
Getting Started Setting up Active Directory Certificate Services PKI
Once you’ve deployed the Active Directory Certificate Services VM from the marketplace, login to the VM via RDP:
- How to RDP to AWS Windows Instance
- How to RDP to Google GCP Windows Instance
- How to RDP to Azure Windows Virtual Machine
Post Deployment Configuration
Once logged in open up “Server Manager“. First task is to decide if this will be an Enterprise CA or Standalone CA. If it will be an Enterprise CA then you will need to add this VM to your Active Directory domain otherwise you can leave as a member server and run as a Standalone CA.
Next step is to run the setup wizard from the notification alert in Server Manager.
On the Credentials page, you can see Administrator is displayed in the Credentials box.
Click Next.
Certificate Authority Role
On the Role Services page, select the Certification Authority check box Click Next.
Enterprise CA or Standalone CA
On the Setup Type page, select Enterprise CA as the CA type to allow integration with your AD Or Standalone CA if your want to run this as a member server in a workgroup.
Root CA or Subordinate CA
On the CA Type page, Select Root CA if this is the first CA in your environment or Subordinate CA if you have an established PKI already, Click Next.
Create Private Key
On the Private Key page, choose between Create a new private key or Use existing private key. Click Next.
Certificate Authority Cryptography
On the Cryptography for CA page:
- Select the default cryptographic provider as RSA#Microsoft Software Key Storage Provider.
- Select Key length as 2048 or above.
- Note: Do not select SHA1 as it is being deprecated by all browsers and Microsoft Server Authentication; use SHA256 instead.
Certificate Authority Name
On the CA Name page, specify the name of your CA in the Common name for this CA text box.
Certificate Validity Period
On the Validity Period page, select the number of years for the certificate to be valid.
CA Database Location
On the CA Database page, specify the locations for the database and database log files. Click Next.
On the Confirmation page, click Configure. Results screen appears after configuration is complete.
Active Directory Certificate Services Firewall Ports
If you have a network security group or firewall appliance in front of your new AD CS virtual machine you’ll need to check you have the following firewall ports open:
Below is a list of ports that need to be opened on Active Directory Certificate Services servers to enable HTTP and DCOM based enrollment.
Protocol | Port | From | To | Action | Comments |
Kerberos | 464 | Certificate Enrollment Web Services | Domain Controllers (DC) | Allow | Source Certificate Enrollment Web Services Destination: DC Service: Kerberos (network port tcp/464) |
LDAP | 389 | Certificate Enrollment Web Services | Domain Controllers (DC) | Allow | Source Certificate Enrollment Web Services Destination: DC Service: LDAP (network port tcp/389) |
LDAP | 636 | Certificate Enrollment Web Services | Domain Controllers (DC) | Allow | Source Certificate Enrollment Web Services Destination: DC Service: LDAP (network port tcp/636) |
DCOM/RPC | Random port above port 1023 | · Certificate Enrollment Web Services · All XP clients requesting certs | CA | Allow | Please see for details on RPC/DCOM configuration:http://support.microsoft.com/kb/154596/en-us |
HTTPS | 443 | All clients requesting certs | Certificate Enrollment Web Services | Allow | Source: Windows 7 client Destination: Service: https (network port tcp/443) Certificate Enrollment Web Services |
To setup AWS firewall rules refer to – AWS Security Groups
To setup Azure firewall rules refer to – Azure Network Security Groups
To setup Google GCP firewall rules refer to – Creating GCP Firewalls
Deploy PKI Certificates by Group Policy
Once you have your PKI Certificate Authority server setup, you’re now ready to start deploying certificates. The following article has a great tutorial on how to deploy Active Directory Certificate Authority certificates to clients using Active Directory Group Policies:
AD Certificate Authority Support
If you have any questions about this Active Directory Certificate Services deployment or are experiencing any issues with your deployment leave your comments below and we will assist you.
If you would like to hire us to setup your AD CS PKI environment for you, get in touch and we can get you up and running.
