In this part, we will see how to install and configure an OCSP responder. OCSP responder is a web service that indicates to the client the status of the certificate. The response sent by the OCSP responder is digitally signed with its certificate. This TechNet topic explains well how online responders work.

Prepare certificate template for OCSP signing

First of all, it is necessary to prepare a template to enroll OCSP servers for a certificate. So open the certification authority console and right click on certificate Templates. Select Manage.

Next I select the OCSP Response Signing to modify properties of this template.

Open security tab. On my side, I have created a group where members are OCSP servers. This group is called GDL-OCSP. I apply Enroll and Autoenroll permissions to this group.

Next return to certification authority console, and right click on certificate templates. Select New Certificate Template to Issue.

Select the OCSP Response Signing template and click ok.

Sub CA configuration

Now, I configure the AIA extension to add OCSP responder URL. For that, open a certification authority console and right click on CA name. Select properties.

Open extensions tab and select Authority Information (AIA) extension. Add an entry like https://<servername>/ocsp. Don’t forget to tick Include in the online certificate status protocol (OCSP) extension.

Click on apply and restart the Certificate Services.

Install and configure online responder

Online Responder Installation

To install the Online Responder role, open your server manager and select Add Roles and Features.

On Select server roles screen, tick Active Directory Certificate Services check box.

On Select role services, tick only
Online Responder. Add IIS features that are required.

Configure online responder

To configure the online responder, open the server manager and run the Post-Deployment configuration as below.

To configure the online responder you need to be only a local administrator. So use local administrator credential and click on next.

Select Online Responder and click on next.

Before clicking on Configure, make sure that Default Web Site exists in IIS because if not, you will have a beautiful error message.

Once the configuration is done, you should have a success message.

In IIS, OCSP web service is added to default web site.

Make a revocation configuration

Now that online responder is installed and configured, we will configure revocation configuration. For that, open the Online Responder Management console:

Next, right click on Revocation configuration and select Add Revocation Configuration.

On the getting started screen, click on next.

Type a name for your Revocation Configuration. A revocation configuration is associated with a CA. So if you have many CA, you have to create many Revocation Configuration J.

Select the CA certificate that will be associated with this revocation configuration. It is working for Offline Root CA or Enterprise CA. Because I want to associate this Revocation Configuration to my Enterprise sub CA, I select a certificate for an existing enterprise CA.

Next I browse the Active Directory to retrieve the CA certificate.

Next I select to Auto-Enroll for an OCSP signing certificate with the template that I have issued previously.

To finish, configure the revocation provider that is the location where are stored CRL or Delta CRL. The configuration retrieves automatically this information in the CDP extension of the certificate.

Once you have finished setting the Revocation Configuration, you should have a working status as below:

Test the online responder

To test the functioning of my online responder, I have enrolled for a certificate a client. As you can see below, the AIA extension indicates the OCSP URL.

I have exported this certificate to CER file and I run certutil –URL c:\temp\MyCertificate.cer. This command opens the below window. I check the status of this certificate with OCSP.

Now I revoke the certificate and I publish again the CRL.

A retrieve again the status of the certificate from OCSP responder and tada : the certificate is marked as revoked.

The post Public Key Infrastructure Part 8 – OCSP responder appeared first on Tech-Coffee.

In the last part, we have created a certificate template for WinRM over HTTPS. Now the Sub CA is able to respond to enrollment request. To remember, enrollment is the process for a client to obtain a signed certificate. The client which asks for a signed certificate is called the enrollee.

In this part, we will see how to obtain a certificate from the certificate template called WinRM.

Enrollment

To make an enrollment, open mmc.exe and click on File and Add/Remove Snap-in:

On the left menu, select Certificates and click on Add. There are three types of snap-in to manage certificates:

• My user account: manage certificates related to your account (personal certificate);
• Service account: manage certificates related to a service (IIS, LDAP etc.);
• Computer account: manage certificates related to the computer (or remote computer).

I select computer account for WinRM using.

Then right click on personal store (or certificates as below) and select All Tasks and Request New Certificate.

On the first screen, click on Next.

Select the Active Directory Enrollment Policy and click on Next.

Select the certificate template that you have configured previously. So I select the certificate template WinRM that I have configured on the previous part.

And that’s all. The enrollment is in progress.

At the end of the enrollment, you should have the certificate in your personal store.

Auto-Enrollment

With Active Directory Certificate Services, it is possible to make Auto-Enrollment to avoid manual steps as above. In this way all machines where you have set auto-enrollment will obtain a certificate automatically. To configure auto-enrollment, your certificate template must have the security permissions set correctly (view previous part).

Next setting is set in GPO. So open gpmc.msc from a domain controller or console server and create a new GPO.

Edit the GPO and navigate to Computer Configuration > Policies > Windows Settings > Public Key Services. Edit Certificate Services Client Auto-Enrollment policy. Set settings as below.

Next, apply the GPO where you want servers make auto-enrollment. On my side I want that all my servers obtain a certificate to configure WinRM over HTTPS everywhere. So I link the GPO on domain level.

Next I’m connecting to a server. I open a mmc as above. As you can see, no certificate are present on this server.

So I run a gpupdate in order to refresh GPO on this server. My GPO is applied and I obtain certificates. I have another certificate for OCSP signing. It is because I set another certificate template to auto-enroll OCSP server (for the next part J).

If I open a certification authority console on the Sub CA and I navigate to issued certificates, I obtain that:

So it is working well. Now you know how to deploy a PKI and how to deploy a certificate. No excuse to not use HTTPS, IPsec or other way to encrypt communicationJ. Next part I will talk about OCSP responder.

The post Public Key Infrastructure Part 7 – Enrollment and Auto-enrollment appeared first on Tech-Coffee.

Certificate templates are a feature available on enterprise CA. Certificates templates enable to preconfigure certificate settings for enrollment (or auto enrollment). As you will see in the next part, enrollment is the process to obtain a certificate signed by the CA. The client that has obtained a certificate by enrollment is called the enrollee.

In this part I will show you how to create a certificate template and configure the CA to respond to enrollment request. In this example I will create a certificate template for WinRM HTTPS using.

Multi-domain forest consideration

In a multi-domain forest, you have to make an extra configuration to manage certificate templates. By default only enterprise admins account or domain admins of the root domain can manage certificate templates. On my side I create always a group where members can manage the CA and templates.

So open an adsiedit.msc console and open a connexion to configuration partition of your domain (see part 5 for further information). Navigate to CN=Public Key Services,CN=Services,CN=Configuration,DC=MY,DC=Domain. Edit properties of the container Certificate Templates and open security tab as below. Add group or user you want to manage certificate templates and add full control permissions.

Add the same permissions to the OID container as below.

Now accounts in GG-CAAdmins can manage certificate templates even if they are not member of enterprise admins or domain admins group.

Create certificate template

/!\ Many settings can be modified in certificate templates. I will show you only basic settings.

To manage certificate templates, open a certification authority console (usually via pkiview.msc
J) and right click on Certificate Templates and select Manage:

In the new console, all certificate templates that are stored in the domain are displayed. This is predefined certificate templates and you can’t delete them. To create a new certificate template you have to duplicate a predefined certificate template and bring modification related to your needs.

So for my example, I want to create a certificate for WinRM over HTTPS. So right click on the Web Server template and select Duplicate template.

The compatibility tab asks you to choose a version for certification authority and certificate recipient. Each version add or remove features in certificates. You should choose compatibility settings according to your certificate using. For example, Hyper-V replica certificates need these parameters set to Windows Server 2012.

Next choose a name for your template. I check the box Publish certificate in Active Directory to sequester certificates in Active Directory.

Next you have some parameters regarding the private key. You can choose the private key usage (signature, encryption or both) or for example if it is exportable. For Hyper-V replica (same example :p), the private key must be exportable to use the same certificate on each host.

On cryptography tab you can choose the minimum key size and the CSP (Cryptographic Service Provider). CSP is a library that contains algorithms to encrypt or unencrypt information.

Next I add a group to manage this template. I use again GG-CAAdmins group.

Because my certificate will be used by all computers of my domain, I add the Domain Computers group with enroll and autoenroll permissions.

On extensions tab, you can choose the certificate usage (Server authentication, client authentication etc.).

To finish, on the subject name tab you can choose how the certificate subject name is filled. You have two options: manually (Supply in the request) or automatically with Active Directory information (Build from this Active Directory information). I choose to use the DNS name as subject name. You can add also alternative subject name.

When the certificate template is set, click on Apply and it will be published in Active Directory.

Configure the CA

Now we have to say to CA that it can issue certificates from WinRM template. For that open the certification authority console and right click on Certificate Templates. Select New and Certificate Template to issue.

Select the WinRM template and click ok.

Now the CA can issue certificate requested from WinRM template.

On the next part of this series, we will see how to make enrollment and auto-enrollment from the WinRM template.

The post Public Key Infrastructure Part 6 – Manage certificate templates appeared first on Tech-Coffee.

In the previous parts of this series, I have talked about encryption and signature algorithms and why Public Key Infrastructure exists. Next I have shown you step by step how to install a simple Public Key Infrastructure with basic configuration. To finish I have spoken about CRL. Now it is time to view how work Certificate Services (ADCS) behind the graphical shell. There is a lot of fun stuff as registry keys, the certutil tool and Active Directory objects. To make things more fun, I have made a screenshot of everything (or almost).

Active Directory objects

To view objects related to ADCS in Active Directory, open ADSIEdit.msc and create a new connection as below.

Navigate to CN=Public Key Services,CN=Services,CN=Configuration,DC=Your,DC=Domain

The first objects called NTAuthCertificates contains CA Certificates that can issue certificates for authentication as Smart Cart Logon. This object can contain multiple CA Certificates.

Next there is the AIA container. This container store CA Certificate of each CA. You can the add certificate manually with certutil command for offline Root CA for example.

If you edit an object, you should have similar information as below. The attribute CACertificate contains the CA certificate in binary format. In my example I have three certificates. It is because when I have made the how to install Active Directory Certificate Services, I have renewed three times the CA Certificate (some mistakes :p).

Next you have the CDP container that containers CRL and Delta CRL.

If you edit an object you can see that the CRL is stored also in binary format.

Next the Certificate Templates containers store template definitions used to deliver certificates. For more information about certificate templates, see next parts of this series.

The Certification Authorities container stores Root CA certificate. It can be published manually for offline Root CA for example.

The Enrollment Services container stores enterprise CA certificate. This information is used by clients to find enterprise CA when they make enrollment and to know which CA host the certificate template that clients need.

The KRA containers (Key Recovery Agent) store the certificate of the recovery agent. When a CA issues a certificate based on the Key Recovery Agent Template, this certificate is added in the KRA containers.

To finish OID container stores object identifier definition describing some custom policies and certificate templates.

Registry keys

Now let’s go see the important registry keys that configure your CA. For that open HKLM\System\CurrentControlSet\Services\Certsvc\Configuration\<YourCAName>. If you want backup your CA, I recommend you to protect this key. This key contains lot a CA settings.

The first are the CA common configuration:

• CACertHash: hash of your CA Certificate
• CACertPublicationURLs: AIA extension configuration
• CAServerName: FQDN of your CA
• CAType: Root CA (0) or Sub CA (1)
• CommonName: CN of your CA.

Next you have CRL parameters as CRL validity period, CRL overlap etc. I will present you some of them:

• CRLPeriod: Time unit used by CRLPeriodUnits
• CRLPeriodUnit: value of the CRL validity period
• CRLPublicationURLs: CRL Distribution Point extension setting

Next you have information about Active Directory:

• DSConfigDN: Distinguished Name (DN) to configuration partition
• DSDomainDN: DN to domain of the CA.

Next, you have information about Key Recovery Agent. You can see that my CA has no recovery agent.

To finish, there are default values of the validity period for the issued certificates:

• ValidityPeriod: Time unit used by ValidityPeriodUnits
• ValidityPeriodUnit: value of the certificate validity period

Certutil command

The objective of this part is not to show you all possibilities of certutil command but make you understand that this tool is the best friend of CA Administrator. Many settings presented above can be set by this command. For example registry settings can be set with this command:

Certutil –setreg CA\<ValueName> <Data>
Certutil –setreg CA\CRLPeriodUnits 5

Certification Authorities must be protected by a backup. Certutil enables you to backup the private key and the database and restore them. Useful after a disaster:

Certutil –BackupDB C:\MyBackupFolder
Certutil –BackupKey C:\MyBackupFolder
Certutil –RestoreDB C:\MyBackupFolder
Certutil –RestoreKey C:\MyBackupFolder\CAName.p12

You can also manually publish the CA Certificate and CRL using Certutil –dspublish

If you have to manage a PKI, I recommend you to watch deeper this tool which can save your life.

The post Public Key Infrastructure Part 5 – Registry key, certutil and Active Directory appeared first on Tech-Coffee.

In this part I’m going to install a Public Key Infrastructure consists of an offline Root CA and an online Sub CA. The offline Root CA will be installed on a server that is not member of Active Directory and will be shut down after installation. The Sub CA will be an enterprise CA because it is joined to Active Directory and always online. My Root CA server is called VMPKI01 and the Sub CA server is called VMPKI02.

This topic is part of a series of articles about Public Key Infrastructure. If you are not comfortable with AIA, CA, CDP and anything about PKI I recommend you to read previous parts of this series.

Active Directory Certificate Services role installation

This part is run on every Certificate Authority server (VMPKI01 and VMPKI02).

First, open the Server Manager and select Add Roles and Features as below.

When you are on Select Server Roles screen, select Active Directory Certificate Services.

On Select role services screen, select only Certification Authority.

To finish click on install.

Root CA configuration (VMPKI01)

Certification authority service configuration

Open the Server Manager and click on the flag. Select Configure Active Directory Certificates Services as below.

On the first screen of the AD CS Configuration, It informs you that install a Standalone Certification Authority, you need an account member of the Administrators group.

Tick the Certification Authority check box and click next.

On the Setup Type screen, you have no choice : you must select Standalone CA.

On the CA Type screen, select Root CA and click next.

On Private Key screen, select Create a new private key. The other options are used when you want to restore a CA after a disaster.

On the next screen, I advise you to set at least a key length of 4096 and use at least SHA 256 (MD5 and SHA-1 are vulnerable to collision).

Next, specify a common name for your CA. I choose to not change this parameter.

On Validity Period screen, select a validity period for the Self-Signed certificate using to sign certificates for Sub CA. In best pratices, this type of certificate should have a validity period between 10 and 20 years.

Next, choose the database locations. It is recommended to store the database on a separate disk.

To finish, click on configure to run the CA configuration.

Now you can open Certification Authority console (as below).

Extensions configuration (AIA and CDP)

Before signing any certificates, it is necessary to configure the CDP and the AIA extensions. Every certificate you sign before you configure these extensions will not have CDP and AIA information and you will must resign them. To configure CDP and AIA open Certification Authority console and right click on the CA Name (as below). Select Properties

Navigate to Extensions tab. On CRL Distribution Point (CDP) menu we have some settings to modify. First I delete all CDP except LDAP.

I add a CDP located to D:\CRL. I use variable to construct CRL name. In this example the CRL will be called VMPKI01-CA.crl

Verify that the previously CDP added have the publish option ticked for CRL and Delta CRL as below.

For the LDAP CDP, make sure that this options are configured as below. The first checkbox is useful to include the Active Directory path directly in CRL to simply publishing manually. The second option add the CDP extension to the certificate. This extension is used by servers to download the CRL.

Next I navigate to Authority Information Extension (AIA) menu. As CDP, I remove every location except LDAP. Verify that option Include in the AIA extension of issued Certificates is ticked for LDAP location. The server will download the certificate chain from the path included in AIA extension.

Next I add my custom path to store the CA certificate.

Once extensions are set, click on apply. You will be asked to restart the Certificate Services. Select yes.

Now I try to publish a CRL to validate my settings. For that right click on Revoked Certificates, select All tasks and publish.

Now that my CRL is published I navigate to D:\CRL and as you can see below, I have my CRL.

CRL and Certificate Validity period

The Root CA is used to sign the CA certificate from Sub CA. So the Certificate and CRL validity period can be increased. So open the registry key HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<CAName>. To modify the signed certificate validity period, edit ValidityPeriodUnits and set this key to 20. Because ValidityPeriod key is set to Years, certificates that will be signed by my Root CA will have a validity period of 20 years. You can do this with these commands:

certutil -setreg ca\ValidityPeriodUnits 20
certutil -setreg ca\ValidityPeriod "Years"

Next the CRL validity period can be increased also because this CA will sign certificate only of Sub CA. So few revocation will be performed. So edit CRLPeriodUnits and set this key to 12. Because CRLPeriod key is set to Weeks, the validity period of the Root CA CRL is 12 weeks. You can do this using these commands:

certutil -setreg CA\CRLPeriodUnits 12
certutil -setreg CA\CRLPeriod "Weeks"

To finish, you have to restart CertSvc service (net stop certsvc && net start certsvc)

Variables configuration

Before when we have set CDP and AIA extensions we have seen variable. There are also variables for the Distinguished Name in Active Directory where to store information (for example LDAP CDP). Because my Root CA is not a member of an Active Directory, it can’t know the Distinguished Name (DN) in Active Directory. So it is possible to define it manually with certutil command:

Certutil –setreg ca\DSConfigDN "CN=Configuration,DC=My,DC=Domain"

Below an example in my environment:

Next, you have to restart CertSvc service (net stop certsvc && net start certsvc). To view if the configuration is good, publish again the CRL and open it. In the General tab, you should see Published CRL Location field. If the value of this field contains the DN that you have specified previously it is good:

Publish Root CA CRL and AIA to Active Directory

The first time, you have to connect with an enterprise admin account to publish certificate and CRL in Active Directory.

To finish the Root CA configuration, it is necessary to publish the CRL and the Root CA certificate in Active Directory. For that I have copied the Root CA certificate (crt file) and the CRL file to VMPKI02. Next I have run the below commands:

Publish CRL: certutil –dspublish –f <CRLFile> <CAName>

Publish CA Certificate : certutil –dspublish –f <CACertificateName>

Now the basic configuration of the Root CA is done. It is time to set the Sub CA.

Sub CA configuration (VMPKI02)

You have to connect with an enterprise admin account to install the enterprise Sub CA.

Connect to the Sub CA server and open the Server Manager. Select Configure Active Directory Certificate Services as below.

On the first screen, you can see that an Enterprise Admins account is needed to install an Enterprise Certification Authority

On Role Services screen, select Certification Authority and click on next.

On Setup Type screen, select Enterprise CA and click on next.

On the next screen, select Subordinate CA.

On private key screen, select Create a new private key. Other options are used to recover the CA after a disaster.

On the next screen, I advise you to set at least a key length of 4096 and use at least SHA 256 (MD5 and SHA-1 are vulnerable to collision).

Next specify a common name for your CA and the distinguished name. I choose to let default parameter.

Next, specify where to store the certificate request and click on next.

Next, choose the database locations. It is recommended to store the database on a separate disk.

Click on configure to run the CA configuration.

Submit the CA certificate request

First copy the request file that is generated from your Sub CA to the Root CA.

Open the certification authority console, right click on the CA Name. Select All tasks and Submit new request. Then specify the path to the CA certificate request.

Once the request is submitted, navigate to pending requests and right click on the request. Select all Tasks and Issue.

Once the CA certificate is issued, navigate to Issued Certificates and right click on the certificate and select open.

Navigate to details tab and click on Copy to File.

After that, the export wizard is opened. On File Format screen select DER encoded X.509 (.CER).

Specify a location to store the CA certificate. I choose to store it directly on Sub CA server.

CA certificate installation on Sub CA

Open the Certification Authority console and right click on CA name. Select All tasks and install CA Certificate. Select the certificate that you have previously exported.

Once the CA certificate is installed, you should start the Certificate Services.

Extension configuration

As Root CA, CDP and AIA should be set first. I configure a CDP on D:\CRL where I publish only CRL.

Make sure that the LDAP CDP is configured as below.

On AIA menu, I set a custom location to store certificate on D:\AIA. Make sure that LDAP location is set as below.

Click on apply and the service should restart. Now you can open PKIVIEW.msc:

Now you have a basic PKI ready to sign certificates. It is a basic configuration. In the next part of this series of articles we will see more in details CRL  configuration.

The post Public Key Infrastructure Part 3 – implement a PKI with Active Directory Certificate Services appeared first on Tech-Coffee.