Tag Archives: Certificate Service

PKI Deployment Models

In my previous posts, we learn how PKI works and what are the PKI components. You can find those articles in following links,

How PKI Works?http://www.rebeladmin.com/2018/05/how-pki-works/ 

Active directory certificate service componentshttp://www.rebeladmin.com/2018/05/active-directory-certificate-service-components/

In this post we are going to look in to different PKI deployment models. In several places in above articles, I have mentioned about the PKI hierarchy and components in it such as root CAs, Intermediate CAs and Issuing CAs. Based on the business and operation requirements, PKI topology will also change. There are three deployments models we can use to address the PKI requirements. 

Single-Tier Model

This is also called as one-tier model and it is the simplest deployment model for PKI. This is NOT recommended to use in any production network as its single point of failure of entire PKI. 


In this model, single CA will act as root CA and Issuing CA. as I explain before the root CA is the highest trusted CA in PKI hierarchy. Any compromise to root CA will be compromise entire PKI. In this model its one server, so any compromise on server will easily compromise entire PKI as it doesn’t need to spread through different hierarchy levels. This is model is easy to implement and easy to manage. Because of that event it’s not recommended, this model exists in corporate networks. 

Some CA aware applications, required certificates in order to function. System center operation manager (SCOM) is one of the good example. It uses certificates on to secure web interfaces, to authenticate management servers and many more. If the organization doesn’t have internal CA, the options are to purchase certificates from vendor or to deploy a new CA. In similar situations engineers usually use this single-tier model as its only use for a specific application or task. 



Less resources and Low Cost to manage as the its all running from single server. It also reduces the license cost for the operating systems.

High possibility of getting compromise as root CA is online and running entire PKI related roles from one single server. If someone get access to private key of root CA he has complete ownership over the PKI

Faster deployment and it is possible to get CA running in short period of time.

Lack of redundancy as Certificate issuing and management all depend on single server and availability of it will decide the availability of PKI


It is not scalable and it will need restructure the hierarchy if need to add more role servers.


All the certificate issuing and management done by one server and all the work requests has to handle by it. it creates a performance bottleneck.

Two-Tier Model 

This is the most commonly used PKI deployment model in corporate networks. By design the root CA need to keep offline and it will prevent private key of root certificate been compromised. root CA will issue certificates for subordinate CAs and Subordinate CAs are responsible for issuing certificates for objects and services. 

In event of Subordinate CAs certificate expire, Offline root CA will need to bring online to renew the certificate. Root CA doesn’t need to be a domain member and it should be operating in workgroup level (standalone CA). There for the certificate enrollment, approval and renew will be manual process. This is scalable solution and number of issuing CAs can be increase based on workloads. This allows to extend the CA boundaries to multiple sites too. In Single-Tier model if PKI got compromised, in order to recover all the issues certificates, need to be manually removed from the devices. In Two-Tier model, all need to do is revoke the certificates issued by CA and then publish CRL (Certificate Revocation List) and then reissue the certificates. 



Improved PKI security as root CA offline and it’s been protected by private key been compromised.  

High Maintenance – Need to maintain multiple systems and need skills to process the manual certificates request/approval/renewal between root CA and subordinate CA

Flexible scalability – Can start small and expand by adding additional subordinate CAs when required.

Cost – Cost of resources and licenses are high compare to Single-Tier model 

Restrict Issuing CA impact in CA hierarchy by controlling certificates scope. It will prevent issuing “rouge” certificates.

Manual certificate renewal process between root CA and subordinate CAs adds additional risks as if administrators forgot to renew it on time it can bring whole PKI down.

Improved performances as workloads can shared among multiple subordinate CAs.


Flexible maintenance capabilities as less dependencies.


Three-Tier Model 

Three-Tier model is the highest in the model list which operates with greater security, scalability and control. Similar to two-tier model it also has offline root CA and online Issuing CAs. Addition to that there will be offline intermediate CAs which operates between root CA and subordinate CAs. Main reason for it is to operate intermediate CAs as Policy CAs. In larger organizations, different departments, different sites, different operation units can have different certificate requirements. As an example, a certificate issued to a perimeter network will required manual approval process while others users in corporate network prefer auto approval. IT team prefer to have advanced Cryptography provider for its certificates and large key while other users operates with default RSA algorithm. All these different requirements are defined by the Policy CA and it publish the relevant templates, procedures to the other CAs. 

This model add another layer of security to the hierarchy. However, if you not using CA policies the intermediate tier will not use. It is just can be a waste of money and resources. there for most of the organizations prefer Two-tier model to start with and then expand as required. 
In this model both root CA and Intermediate CAs are operates as standalone CA. root CA only will issue certificates to intermediate CAs and those only will issue certificate to Issuing CAs. 



Improved security as it adds another layer of CAs to the certificate verification.

Cost – Cost of resources and licensee are high as its need to maintain three layers. It also increases the operation cost.

Greater scalability as each tier can span horizontally.

High Maintenance – When number of servers increases the efforts need to maintain those also increases. Both tiers which operates standalone CAs required additional maintenance as its not supported for automatic certificate request/approval/renewal. 

In event of compromise of issuing CA, intermediate CA can revoke the compromised CA with minimum impact to existing setup

Implementation Complexity is high compare to other models.

High Performance setup as workloads are distributed and administrative boundaries are well defined by intermediate CAs.


Improved control over certificate policies and allow enterprise to have tailored certificates.


High availability as dependencies further reduced.


This marks the end of this blog post. In next post we are going to look in to deployment of AD CS. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.

Active Directory Certificate Service Components

In my previous post I explained what is PKI and how it works. You can find it using http://www.rebeladmin.com/2018/05/how-pki-works/ 

Active Directory Certificate Service is the Microsoft solution for PKI, It is collection of role services and those can use to design the PKI for your organization. In this post we are going to look in to each of these role service and their responsibilities. 

Certificate Authority (CA)

CA role service holders responsible for issue, store, manage and revoke certificates. PKI setup can have multiple CAs. There are mainly two types of CA which can identify in PKI. 

Root CA

Root CA is the most trusted CA in PKI environment. Compromise of root CA will possibly compromise entire PKI. There for security of the root CA is critical and most organization only bring those online when they need to issue or renew a certificate. Root CA also capable of issue certificates to any object or services but considering security and hierarchy of the PKI it used to issue certificates only to Subordinate CAs. 

Subordinate CA

In PKI, Subordinate CAs are responsible for issues, store, manage and revoke certificates for objects or services. These publish certificate templates and users can create their certificate requests based on those templates. Once CA receives the request it will process it and issue the certificate. PKI can have multiple subordinate CAs. Each subordinate server should have its own certificate from the root CA. the validity period of these certificates is normally longer than ordinary certificates. It also need to renew its certificate from root CA when it reaches the end of validity period. Subordinate CA can have more subordinate CAs below it. in such situation, Subordinate CA also responsible for issuing certificates for its more subordinate CAs. These Subordinate CAs which have more Subordinate CAs called as Intermediate CA. These will not be responsible for issues certificates to users, devices or services. Then it will become more subordinate CA’s responsibilities. The more subordinate servers which issues certificates will call as Issuing CA.


Certificate Enrollment Web Service

Certificate enrolment web service allow users, computer or services to request certificate or renew certificate via web browser, even it is not domain-joined or temporally out of corporate network. If it is domain-joined and in corporate network, they can use auto enrollments or template based request process to retrieve certificate. This web service will remove the dependencies to use other enrollment mechanism. 

Certificate Enrollment Policy Web Service

This role service is works with certificate enrollment web service and allow user, computer or services to perform policy-based certificate enrollment. Similar to enrollment web services, the client computers can be non-domain joined computer or domain joined devices which is out of company network boundaries. When client request for policy information, enrollment policy web service query the AD DS using LDAP for the policy information and then deliver it to client via HTTPS. This information will be cashed and use for similar requests. Once user has the policy information then he/she can request certificate using certificate enrollment web service. 

Certificate Authority Web Enrollment 

This is similar to a web interface for Certificate Authority. Users, computers or services can request certificates using web interface. Using the interface users also can download the root certificates and intermediate certificates in order to validate the certificate. This also can use to request certificate revocation list (CRL). This list includes all the certificates which is expires or revoked with in its PKI. If any presented certificate match entry in the CRL, it will be automatically refused. 

Network Device Enrollment Service

Network devices such as routers, switch and firewalls can have device certificates to verify authenticity of traffic pass through it. majority of these devices are not Domain-Joined and their operation system are also very unique and do no support typical windows computer functions. In order to request or retrieve certificates, it uses Simple certificate enrollment protocol (SCEP). It allows network devices to have x.509 version 3 certificates similar to other domain-joined devices. This is important as if devices going to use IPsec it must needs have x.509 version 3 certificate.  

Online Responder

Online responder is responsible for producing information about certificate status. When I explain about CA web enrollment I explained about certificate revocation list (CRL). CRL includes the entire list of certificates which is expired and revoked with in the PKI. The list will keep growing based on the number of certificates it managed. Instead of using bulk data, online responder will response to individual requests from users to verify status of a particular certificate. This is more efficient than CRL method as requests is focused to find out status of one certificate in given time. 

Certificate Authority Types

Based on the installation mode the CAs can be divide in to two types which is Standalone CA and Enterprise CA. The best way to explain capabilities of both types is to compare them. 


Standalone CA

Enterprise CA

AD DS Dependency

Not Depend on AD DS, it can install on member server or stand-alone server in workgroup

Only can install in Member server

Operate Offline

Can Stay Offline

Cannot be Offline

Customized Certificate Templates

Do Not support, only support standard templates


Supported Enrollment Methods

Manual or Web Enrollment

Auto, Manual or Web Enrollment

Certificate Approval Process


Manual or Automatic based on the Policy

User input for the Certificate fields


Retrieved from AD DS

Certificate Issuing and Managing using AD DS



Standalone CA mostly use for as the root CA. in previous section I have explain how important is root CA security is. In Standalone CA it support to keep the server offline and bring it online when it need to issue certificate or renew certificate. Since root CA are only used to issue certificates to subordinate CA. so the manual processing and approval are manageable as it may only have to do in every few years’ time. This type also valid for public CAs. Issuing CA are involving with day to day certificate issuing, managing, storing, renewing and revoking process. Depending on the infrastructure size it can be hundreds or thousands who use these issuing CAs. If the request and approval process is manual it may take much manpower to maintain it. there for in corporate networks it always recommended to use enterprise CA type. Enterprise CAs allows engineers to create certificate templates with specific requirements and publish these via AD DS. End users can request the certificates based on these templates. Enterprise CAs are only can install on Windows server Enterprise or Data Center version only. 

This marks the end of this blog post. In next post we are going to look in to deployment models of AD CS. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.


Microsoft has already announced that windows server 2003 / windows server 2003 R2 versions support is coming to end in 14th July 2015 (http://support2.microsoft.com/lifecycle/search/default.aspx?sort=PN&alpha=Microsoft+Windows+Server+2003&Filter=FilterNO). It’s no wonder that some organizations still uses windows server 2003 versions in production environment.

If you still not plan for migration from legacy windows server versions, well time has come!!

This guide will explain how we can migrate AD CS from windows server 2003 to windows server 2012 R2.

In this demonstration I am using following setup.

Server Name

Operating System

Server Roles


Windows Server 2003 R2 Enterprise x86

AD CS ( Enterprise Certificate Authority )


Windows Server 2012 R2 x64

Backup windows server 2003 certificate authority database and its configuration

•    Log in to Windows 2003 Server as member of local administrator group
•    Go to Start > Administrative Tools > Certificate Authority


•    Right Click on Server Node > All Tasks > Backup CA


•    Then it will open the “Certification Authority Backup Wizard” and click “Next” to continue


•    In next window click on check boxes to select options as highlighted and click on “Brows” to provide the backup file path location where it will save the backup file. Then click on “Next” to continue


•    Then it will ask to provide a password to protect private key and CA certificate file. Once provided the password click on next to continue


•    In next window it will provide the confirmation and click on “Finish” to complete the process

Backup CA Registry Settings

•    Click Start > Run and then type regedit and click “Ok”


•    Then expand the key in following path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc

•    Right click on “Configuration” key and click on “Export”


•    In next window select the path you need to save the backup file and provide a name for it. Then click on save to complete the backup


Now we have the backup of the CA and move these files to the new windows 2012 R2 server.



Uninstall CA Service from windows server 2003

Now we have the backup files ready and before configure certificate services in new windows server 2012 r2, we can uninstall the CA services from windows 2003 server. To do that need to follow following steps.

•    Click on Start > Control Panel > Add or Remove Programs


•    Then click on “Add/Remove Windows Components” button


•    In next window remove the tick in “Certificate Services” and click on next to continue


•    Once its completed the process it will give the confirmation and click on “Finish”


With it we done with windows server 2003 CA services and next step to get the windows server 2012 CA services install and configure.

Install windows server 2012 R2 Certificate Services

•    Log in to windows server 2012 as Domain Administrator or member of local administrator group

•    Go to Server Manager > Add roles and features


•    It will open up “Add roles and feature” wizard and click on next to continue


•    Then next window select “Role-based or Feature-based installation” and click next to continue


•    From the server selections keep the default selection and click on next to continue


•    In next window click on tick box to select “Active Directory Certificate Services” and it will pop up with window to acknowledge about  required features need to be added. Click on add features to add them



•    Then in features section will let it run with default. Click next to continue


•    In next window, it will give brief description about AD CS. Click next to continue


•    Then it will give option to select roles services. I have selected Certificate Authority and Certification Authority Web Enrollment. Click next to continue


•    Since Certification Authority Web Enrollment selected it will required IIS. So next window it will give brief description about IIS


•    Then in next window it gives option to add IIS role services. I will leave it default and click next to continue


•    Next window will give confirmation about service install and click on “Install” to start the installation process


•    Once installation completes you can close the wizard.

Configure AD CS

In this step will look in to configuration and restoring the backup we created.

•    Log in to server as Enterprise Administrator
•    Go to Server Manager > AD CS


•    In right hand panel it will show message as following screenshot and click on “More”


•    It will open up window and click on “Configure Active Directory Certificate Service ……”


•    It will open role configuration wizard, it gives option to change the credential, in here I already log in as Enterprise administrator so I will leave the default and click next to continue


•    In next window it asking which service you like to configure. Select “Certification Authority”,  “Certification Authority Web Enrollment” options and click next to continue


•    It will be Enterprise CA so in next window select the Enterprise CA as the setup type and click next to continue


•    Next window select “Root CA” as the CA type and click next to continue


•    The next option is very important on the configuration. If its new installation we will only need to create new private key. But since it’s a  migration process we already made a backup of private key. So in here select the options as highlighted in screenshot. Then click on next to continue


•    In next window click on “Import” button


•    In here it will give option to select the key we backup during the backup process from windows 2003 server. Brows and select the key from the backup we made and provide the password we used for protection. Then click ok


•    Then it will import the key successfully and in window select the imported certificate and click next to continue


•    Next window we can define certificate database path. In here I will leave it default and click next to continue


•    Then in next window it will provide the configuration confirmation and click on configure to proceed with the process


•    Once its completed click on close to exit from the configuration wizard

Restore CA Backup

Now it’s comes to the most important part of the process which is to restore the CA backup we made from windows server 2003.

•    Go To Server Manager > Tools > Certification Authority


•    Then right click on server node > All Tasks > Restore CA


•    Then it will ask if it’s okay to stop the certificate service in order to proceed. Click ok


•    It will open up Certification Authority Restore Wizard, click next to continue


•    In next window brows the folder where we stored backup and select it. Then also select the options as I did in below. Later click next to continue


•    Next window give option to enter the password we used to protect private key during the backup process. Once its enter click next to continue


•    In next window click “Finish” to complete the import process


•    Once its completed system will ask if it’s okay to start the certificate service again. Please proceed with it to bring service back online

Restore Registry info

During the CA backup process we also backup registry key. It’s time to restore it. To do it open the folder which contains the backup reg key. Then double click on the key.
Then click yes to proceed with registry key restore.


Once completed it will give confirmation about the restore.


Reissue Certificate Templates

We have done with the migration process and now it’s time to reissue the certificates. I had template setup in windows 2003 environment called “PC Certificate” which will issue the certificates to the domain computers. Let’s see how I can reissue them.

•    Open the Certification Authority Snap-in
•    Right click on Certificate Templates Folder > New > Certificate Template to Reissue


•    From the certificate templates list click on the appropriate certificate template and click ok


Test the CA

In here I already had certificate template setup for the PC and set it to auto enroll. For the testing purposes I have setup windows 8 pc called demo1 and added it to canitpro.local domain. Once it’s loaded first time in server I open certification authority snap in and once I expanded the “Issued Certificate” section I can clearly see the new certificate it issued for the PC.


So this confirms the migration is successful.