General ADCS best Practices

• Make a detailed plan of your PKI infrastructure before deployment. One mistake and you have to rebuild your PKI.
• Do not rename your CA server name after ADCS configuration. Issued certificates will no longer work
• Avoid to install ADCS on a domain controller
• On all CA, implement Role-Based Administration

Root CA

• The operating system should be without Graphical Shell (Core)
• Make a hardening of your server
• Use a specific administrator password
• Do not join an Active Directory domain
• Shutdown the server except when publishing the CRL
• Protect the offline Root CA with Bitlocker (View Flemming Riis topic)
• If you can, protect the private key with HSM
• Store the database and transaction log on a separate hard drive
• Do not issue certificates to clients (devices or users) from Root CA
• Backup the CA private key, CA registry Key, the CA database and the CA certificate
• Publish the CA certificate in Active Directory
• Enable auditing events

Sub CA

• The operating system should be without Graphical Shell (Core)
• Make a hardening of your server
• Use a specific administrator password
• If you can, protect the private key with HSM
• Store the database and transaction log on a separate hard drive
• The Sub CA should issue certificates for clients OR for Sub CA but not both
• If your Sub CA issue certificates for other Sub CA (and not clients), keep this server outside of an Active Directory Domain.
• Install Enterprise CA only if your CA issue certificate for clients (devices or users)
• Backup the CA private key, CA registry Key, the CA database and the CA certificate
• On CAs that deliver certificates for user clients, implement Key Archival
• Enable auditing events

Template Certificates

• Do not use default templates and always duplicate certificate templates.

CRL, AIA and OCSP

• Modify default file system CDP path
• Modify default file system AIA path
• CDP should be highly available. For internal usage, prefer use Active Directory and for External usage, prefer use HTTP.
• For larger organization, prefer using of high available OCSP responder
• Publish Root CA CRL to Active Directory

CA certificates

• Validity period: maximum 20 years
• Key length: at least 4096bit
• Hash algorithm : at least Sha-2 (Sha 256bit)

Client certificates

• Validity period: maximum 2 years
• Key length: at least 4096bit (be careful that some applications support only 2048bit, I’m talking about you SCCM 2012 R2 … Red card)
• Hash algorithm : at least Sha-2 (Sha 256bit)

The post Public Key Infrastructure Part 10 – Best Practices about PKI appeared first on Tech-Coffee.

In this part I will talk about management accounts regarding:

• CA management: To manage CA we will implement Role-Based Administration;
• Recovery Agent: account which is able to recover all private keys.

These CA management accounts are important to increase the security level of your PKI. PKI is a security component and should be managed by security officers. But it is not always the same security officer who manages CAs, certificates or audit logs. Moreover, the CAs backups are usually managed by the backup team and Windows server is managed by the system admin. So it is necessary to implement Role-Based Administration.

Regarding Recovery Agent, it is a special account that is able to recover all private keys. This is why this agent should be associated with a security officer account. If this account is corrupted, all data of your company could be decrypted …

Role-Based Administration

Permission description

All tables on this part are taken from TechNet.

I have copied tables from TechNet because they explain very well the different permissions. Four permissions are managed from Certificate Services: Manage CA, Issue and Manage Certificates, Read and Enroll. Backup Operator and Auditor roles are managed from the operating system.

In the below table, you have the Activity related to the role of the user.

Modify CA management accounts

Now I’m going to show you how to implement Role-Based Administration in practice. For that, I have created some groups in Active Directory:

• GA-CAAdmins: Manage CA.
• GG-CertificateMgmt: Manage Certificates
• GG-SecurityLogMgmt: permissions on security event logs.

To manage permissions for Certificate Services, open a certification authority console and right click on CA name. Select properties. Navigate to Security tab. First I have deleted permissions for Domain Admins group. Next I have added the group GG-CAAdmins with below permissions:

After that, I have added GG-CertificateMgmt group as below:

On Certificate Services side, I have finished. Now I want to set permissions on security logs auditing. For that open gpedit.msc (you can make the same thing by GPO). Navigate to Computer Configuration, Windows Settings, Security Settings, Local Policies and User Right Assignments.

Edit Manage auditing and security log policy and add the related group. On my side I have added GG-SecurityLogMgmt.

To finish, add to Backup Operators (from Active Directory or local group) accounts that need backup permissions.

Recovery Agent

Now I would like to spend some time about Recovery Agent. This feature is very important if you encrypt corporate data. Depending on your country and your law, security officers must be able to unencrypt information for a while even if the employee has left. To be able to unencrypt all data even if the private key of the user has been lost, you should use recovery agent.

The principle is simple: all private keys generated by client are copied in a key archival. Then the recovery agent certificate is able to open this key archival. To recover data, just extract the related private key from key archival and use it to unencrypt data.

To implement Key Archival, I will create a certificate for Romain Serre using Key Recovery Agent certificate template:

In security tab, I add my account with Read and Enroll permissions.

Next I configure my CA to issue the certificate template:

Now I open a mmc with certificates snap-ins which manage my user account:

Right click on Personal and select All tasks, Request New Certificate.

When you are asked for a certificate template, select Key Recovery Agent and click on Enroll. At the end of this process, the enrollment is pending and wait for your approval.

To approve the certificate request, open the certification authority console and click on Pending Requests. Right click on your certificate and select All Tasks and Issue.

Now open issued certificates and double click on the previously issued certificate. Navigate to the Details tab and export the certificate by clicking on Copy to file. Follow the process and export your certificate to .cer file.

Once your certificate is exported, go back to your mmc and right click on Personal. Select All Tasks and import as below.

Follow the import process and select the .cer file that you have just exported. Now you should have the certificate in your personal store.

To configure the Key Archival, open the certification authority, right click on the CA name and select properties. Navigate to Recovery Agents tab. Select Archive the key, click on Add and select the certificate:

Before restarting Certificate Services, the status of the key recovery agent certificates is not loaded. When you click on apply, the service restarts and the status should be valid.

Now to archive the private key in the Key Archival, edit the template that you want and navigate to the Request Handling tab. Tick the Archive subject’s encryption private key checkbox. Select the Key archival and click ok:

Now, private keys will be archived to the Key Archival. To understand the user key recovery, I recommend you this topic.

The post Public Key Infrastructure Part 9 – management accounts appeared first on Tech-Coffee.

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.

Certificate Revocation List

As seen in previous the part, Certificate Revocation List contains revoked certificate IDs (only non-expired revoked certificate). To determine if a certificate is revoked, the client downloads the CRL and verify if it is not in the CRL. The CRL is cached by the client for the duration of the validity period. By default, a CRL validity period is 1 week. That means that the CRL is updated on the Certificate Distribution Point (CDP) every week. So it can be a security issue because if a certificate is revoked during the validity period of the CRL, this last will not be updated on CDP and the client will not know that the certificate is revoked.

So if you are using only base CRL, do not configure a longer validity period to reduce the security issue period. In the other hand, do not publish too often the CRL to avoid network overload especially if your CRL is large. You have to find a golden mean.

Delta CRL

A delta CRL contains revoked certificate IDs (only non-expired revoked certificate) since the last CRL has been published. To determine if a certificate is revoked, the client downloads the CRL (will be cached) and the Delta CRL. By default the CRL is published every day.

Delta CRL is used when the CRL becomes very large. In this case the CRL is published less frequently and Delta CRL is downloaded more frequently.

CRL overlap

When using CRL overlap, two CRL is published at different times. For example, suppose that CRL has a validity period of 4 days. So the first CRL is published and the second will be published two days after.

CRL overlaps is used to be sure that a new CRL is available before that the first CRL is expired. When you store the CRL in Active Directory and you have many sites, the CRL propagation depends on DFS replication. So it is necessary to allow time for replication. So in this case, CRL overlaps can be used. By default on Active Directory Certificate Services solution, the overlap period is 10% of the CRL lifetime and 12 hours at maximum.

Configure CRL

Below commands configure the CRL validity period to 6 days:

certutil -setreg CA\CRLPeriodUnits 6
certutil -setreg CA\CRLPeriod "Days"

 Below commands configure the Delta CRL validity period to 1 days:

certutil -setreg CA\CRLDeltaPeriodUnits 1
certutil –setreg CA\CRLDeltaPeriod "Days"

 Below commands configure the overlap period to 2 hours:

certutil -setreg CA\CRLOverlapPeriod "hours"
certutil -setreg CA\CRLOverlapUnits 2

The post Public Key Infrastructure Part 4 – Configure Certificate Revocation List 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.

Public Key Infrastructure

Certificates

As you have seen previously, encryption and signature operation are performed with public and private key. These two keys are mathematically related. So when an entities (users or computers) want to receive encrypted or signed data, it generates a private key and send the public key to its correspondent. The correspondent performs the same process. This is called the Key Exchange.

The first problem of key exchange, is that the key must not be duplicated by malicious guy. So it is necessary to create a secure channel to make the key exchange. The solution can be physic with a diplomatic bag for example. In 1976 a popular person called Diffie Hellman published a secure key exchange protocol called DH key exchange (Diffie Hellman key exchange). Thanks to DH, a secure channel can be used for the key exchange. But this protocol doesn’t resolve the second problem: how to be sure that the public key belong to the owner that claim to be?

This is why digital certificate (called sometime public key certificate) has been created. A certificate is a digitally signed document containing the entity information (such as name, postal address, E-mail etc.). In this way, it is possible to be sure that the public key belongs to an entity.

Usually the certificate is signed by a trusted third party called Certificate Authorities. A certificate has an expiration date, information about key using (encryption, signature or both) or the certificate using (authentication server, E-mail signing etc.).

Figure 1: Example of a certificate: outlook.com

The above certificate (figure 1) is delivered to the entity mail.live.com by a certificate authority called VeriSign. This certificate has a validity period from May, 21^st 2013 to May, 23^rd 2013.

Figure 2: Example of certificate: detailed information

Certificate contains other details such as:

• The asymmetric cryptography algorithm;
• The subject Alternative Name that contains other known identity of the entity;
• The hash algorithm;
• Key usage;
• The Certificate Revocation List (view d. Certificate Revocation List section);
• The Authority Information Access (view Authority Information Access).

Certificate is based on a standard called X.509 to be sure that the certificate is interoperable. This standard defines a certificate structure. For example the entity and certificate authority identity must be distinguished name as LDAP protocol (X.501 standard). For more information about X.509 please read RFC 2459 (https://www.ietf.org/rfc/rfc2459.txt).

Certificate Authority

A Certificate Authority called CA, is the trusted third party that digitally signed certificate. So it is the CA that approves certificates that ensures that public key belong to an entity. So it is a critical component in security.

Because a CA digitally sign certificates, it needs also a public and a private key and so a certificate. This certificate can be self-signed by the CA or signed by a top CA. When a CA uses a self-signed certificate, it is called a Root CA while in the other case it is a subordinate CA (called also Sub CA or intermediate CA).

A certificate authority performs mainly these actions:

• Issue certificate requests by signing them;
• Revoke certificates for many reasons (end of validity, compromised key etc.).

A Public Key Infrastructure (PKI) can be composed from one to many Certificate Authorities. Usually at least two certificate authorities participate to a PKI: one Root CA and one Sub CA. A PKI is always composed of one Root CA. The others CA are Sub CA.

Root CA or Sub CA can sign CA certificates or client certificates but as best practices, it is recommended that:

• Root CA should sign only CA Certificates;
• Sub CA should sign for CA certificates OR client certificates but not both.

For example, a PKI architecture can seems as Figure 3.

Figure 3: Example of PKI design

The Root CA signs the CA certificate for Sub CA Users and Computers. The Sub CA users signs Sub CA certificates of Marketing and Engineers. To finish Sub CA marketing and Engineers sign certificates for users while sub CA computers signs certificates for computer.

When a user or a computer uses a certificate, it must verify the validity of its certificate authority and all CA on top until the Root CA: it is called the chain of trust.

Chain of trust

All certificates from Root CA to end-users either a computer, a user, a CA or other entity, is called the chain of trust. When a certificate is used, each certificate in the chain of trust must be checked. Figure 10 is a screenshot of outlook.com certificate on certification path tab. This chain of trust is composed of:

• A Root CA called VeriSign;
• A Sub CA called VeriSign Class 3 Extended Validation SSL SGC CA;
• The end-user certificate.

Figure 4: Chain of trust of outlook.com certificate

When a user connects to outlook.com, he verifies that the certificate is valid from the intermediate CA. But the user must verify also the validity of the intermediate CA certificate from the Root CA VeriSign.

Certificate Revocation List

As I said previously, certificate authorities can revoke a certificate. When a certificate is revoked, it must be no longer useable. This is why Certificate Revocation List (CRL) exists. Each time a certificate is revoked, its ID is added to a file called CRL. This CRL is signed by the CA itself.

To be available to entities which use certificate, CRL is published on distribution point called CDP (CRL Distribution Point). It can be a Web Server, an LDAP server such as Active Directory or a share. These CDP are added to the certificate in CDP extension. Many CDP can be referenced in the CDP extension.

Figure 5: CDP extension of outlook.com certificate

When a client checks a certificate validity, it downloads the CRL referenced in certificate CDP extension. If several CDP are included in CDP extension, the client will download the CRL from the first location. If the client can’t download the CRL from this location, it will attempt with the next CDP included in CDP extension and so on. The CRL is downloaded and cached by the client for the validity period of the CRL.

For example if a CRL has a validity period of 3 days, the CRL will be cached by the client for 3 days. Once 3 days have passed, the client download again the CRL.

Moreover, more the CRL validity period is longer, more you take security risk. If a certificate is revoked when the client has cached the CRL, the client will not know that the certificate is revoked. This topic will be discussed in Design Part.

CRL can become a very large file if your organization revokes regularly certificate. It can be a problem for your bandwidth and sometime because the CRL is very large, the threshold time limit to download CRL can be reached. That result that the revocation checking process fails. To limit these issues, Delta CRL can be used.

Delta CRL is a partial CRL that contains revoked certificate IDs since the last CRL has been published. In this way CRL validity time can be lengthy and the publication of Delta CRL can be performed regularly. So the client will download the CRL for a greater period of time and will download only Delta CRL most of the time. That result to save bandwidth.

Figure 6: Outlook.com certificate CRL

As you have seen, CRL presents some disadvantage:

• CRL can become a large file that result bandwidth issue;
• The validity period must be balanced between bandwidth saving and security risks;
• Depending on where the CRL is located, some client can’t access to it (for example if CRL is hosted on Active Directory, usually the internet client can’t download it).

To resolve CRL disadvantage, an alternative protocol can be used: Online Certificate Status Protocol.

Online Certificate Status Protocol

Online Certificate Status Protocol (OCSP) is a standard protocol used to validate the certificate. OCSP uses ASN.1 as data structure. Usually and in Microsoft world, OCSP uses HTTP to transport messages. OCSP uses the model client/server and the OCSP server is called OCSP responder. Sometime OCSP responder is also called Validation Authority (VA).

When an OCSP responder is asks about certificate validity, it indicates just the certificate status. So the data transmitted over network between OCSP responder and client are always the same, independently of the number of revoked certificates.

Except some case, OCSP relies on CRL published by CA to determine the certificate status. But when an OCSP responder is used, only it will download CRL and no longer clients. So the CRL validity period can be reduced regardless bandwidth saving.

The OCSP responder signs each response made to client with its own private key. So the integrity of this key must be checked by the client after that OCSP responder sends a status.

Because OCSP is usually based on HTTP, the client doesn’t cached a revoked certificate database as CRL process. So each time a certificate must be validated, a request is sent to OCSP responder. So in large PKI infrastructure, OCSP responder can be overloaded and so requires load-balancer and geographical deployment to ensure high-availability.

Authority Information Access

To validate a chain of trust, each certificate in this last must be checked. To validate certificates, the client must access to it to be sure that the certificate is in validity period and to find related CRL or OCSP responder.

Authority Information Access (AIA) is used to locate CA certificate. AIA contains the CA certificate path and is referenced in certificate AIA extension. AIA can indicate CA certificate path over HTTP, LDAP or share.

Figure 7: AIA extension in Outlook.com certificate

Public Key Cryptographic Standards

Public Key Cryptographic Standards (PKCS) are a set a “standards” to describe some cryptographic process. I have written the word standard between quote because it is not really standards. PKCS specifications are published by RSA Security (belong to EMC since 2006) company and only a few of them are taken up by the normalization agency.

PKCS specifications are numbered after a hash. For example the DH key exchange is called PKCS#3. In this part I will not present you all PKCS specification. Only the most important to understand PKI are described. For more information, you can visit https://www.emc.com/emc-plus/rsa-labs/standards-initiatives/pkcs-rsa-cryptography-standard.htm.

PKCS#7 (RFC 2315)

PKCS#7 is standardized by the IETF as RFC 2315. This standard defines syntax for cryptographic message either to sign or encrypt data. This standard also describes how to respond to a PKCS#10 message.

PKCS#7 certificate is based on PKCS#7 specification and it is a X.509 certificate as described previously. PKCS#7 certificates can have these file extensions: .p7b, .p7c, .der, .cer, .crt or .pem. On Microsoft environment, .cer and .der are mainly used.

PKCS#10 (RFC 2986)

PKCS#10 is standardized by the IETF as RFC 2986. This standard describes the certificate request process. Usually this request is sent to a certificate authority. The CA can sign the request and so issue a PKCS#7 certificate. On Microsoft environment, the certificate request file has .req, .csr or .txt extension. On other environment, this file can be found with .p10 extension.

The certificate request contains the identity of the issuer and his public key. The certificate request is signed by the private key of the issuer.

PKCS#11

PKCS11 is an API for security token such as HSM (Hardware Security Module) or Smartcard. When you plug a smartcard on your Windows, the communication is done across PKCS11 API. Usually this API is added to system when you install the smartcard drivers.

PKCS#12

PKCS#12 specification describes how to store and transport safety private keys, certificates or other sensitive information. PKCS#12 file act as a container usually protected by password. Because PKCS#12 can store certificates, the chain of trust can be included in the file. On Microsoft environment, the PKCS#12 file extension is .pfx. On other environment it can be found as .p12 file.

The post Public Key Infrastructure part 2 – main components appeared first on Tech-Coffee.

A Public Key Infrastructure (PKI) is a security component. It signs certificates for different purposes such as encryption, signature or authentication. Because PKI is a security component, the solution has to respond to three criteria:

• Confidentiality: means that only intended recipients can read the information;
• Authenticity: to ensure that the information really comes from the issuer that it claims to come;
• Integrity: mechanisms to verify that information have not been altered.

In this part we will see how to respond to these criteria with technical mechanisms such as encryption, signature or integrity checking.

Confidentiality

Why encrypt?

Encryption is a mechanism to make the information unreadable to anyone except the wanted recipient. The information can be created, stored and sent encrypted. For example in enterprise, some information has to be encrypted such as trade secrets or salaries. Thanks to encryption, the information can be confidential.

In the modern world, there are two encryption ways: the symmetric cryptography and the asymmetric cryptography. The symmetric cryptography is based on a single key which is shared while asymmetric cryptography is based on a two keys. We will see in details these mechanisms after. But now, have a look on an old encryption algorithm (certainly one of the first): the Caesars code.

Example of encryption: the Caesar code

The Caesar code has been created by Julius Caesar to send military orders to his legions. This algorithm is based on the alphabet in plaintext and a key which is a number. To encrypt the message, the alphabet is right or left shifted with the value of the key. Example with a right shift key of 3:

Figure 1: Code Caesar

• Plaintext alphabet: abcdefghijklmnopqrstuvxyz
• Encrypted Alphabet: defghijklmnopqrstuvxyzabc

Example:

• Encrypted message: Pb phvvdjh lv hqfubsxhg
• Plaintext message: My message is encrypted

The main problem of this encryption algorithm is that it is easy to break. For example on the above example you can use a letter that is often used to break the cipher. Moreover it is simple to break the cipher when the word is small. More you use the same key, more it is easiest to break it. It is called the key wear out.

Key definition

As the Caesars code, modern encryption algorithm uses a key. A key is a very long random number generated by the machine. This is these keys that are used to encrypt. There are two sorts of keys: Private Key and Public Key. When a public key is used (cf. Asymmetric cryptography), it is mathematically related to private key.

Symmetric cryptography

Symmetric cryptography is based on the usage of a single private Key shared between two or more entities:

Figure 2: Symmetric cryptography

The key Kpr is shared between entities. In this way, information can be encrypted and unencrypted with this key. But more you share your private key, less it is a private key. This is why asymmetric encryption has been invented. Symmetric cryptography is implemented in AES, 3DES, Blowfish, RC4 etc. Usually the key length is small: a key with 256 bits is a strong key.

The main advantage of symmetric cryptography is that encryption is fast and use few system resources. But because the private key is shared between one or more entities, the security of this solution is lower than asymmetric cryptography.

Asymmetric cryptography

Asymmetric cryptography is based on a bi-key (Private and Public key). These two keys are mathematically related. With asymmetric cryptography, the private key is not shared between entities. Instead of the public key is shared. To encrypt information, the public key is used and on the other side, the private key is used to unencrypt:

Figure 3: Asymmetric cryptography

The public key (Kpu) is sent to the correspondent. This key is used to encrypt the information. The related Private key (Kpr) is used to unencrypt information. So this last is very critical because it permits to unencrypt information. Asymmetric cryptography is implemented mainly in RSA or DH (Diffie Hellman). Usually the key length is long: a 4096 bits key is the minimum recommended today.

The main advantage of asymmetric cryptography is that it is really robust. However this solution consumes a lot of system resources (mainly CPU) and the encryption is slow.

Modern encryption

Each encryption algorithm has advantages and convenient. Symmetric cryptography is fast but is not robust while Asymmetric cryptography is the opposite. So why not associate the two world to have a robust and faster solution?

So modern algorithm uses a session key (temporarily key) to encrypt information with symmetric cryptography. Next the session key is encrypted with the public key of the recipient. To unencrypt information, first the recipient unencrypt the session key with his private key and unencrypt information with the session key.

Figure 4: Modern encryption algorithm

On the sender side, the below action are performed:

1. A temporarily key called session key (Ks) is generated;
2. The information is encrypted with Ks;
3. Next the Ks is encrypted with the public key (Kpu) related to the private key of the recipient. This key is called Kse;
4. The Kse is added to the encrypted information file. This file is sent to the recipient.

On the recipient side, the below action are performed:

1. The encrypted information and Kse are separated;
2. The Kse key is unencrypt with the private key (Kpr) of the recipient and becomes the Ks;
3. The document is unencrypted with Ks.

For the rest, I will use this algorithm as a reference in particular to explain the interaction between integrity checking, signing and encryption. So the good understanding of this algorithm is required before to go further.

Integrity

Why verify integrity?

Integrity checking is the mechanism to verify if the information has not changed. The information can be changed due to encryption malfunctioning, network problem or malicious modification. To validate the integrity, a thumbprint of the information is created. A thumbprint (also called hash or digest) is created by an algorithm that create a shorter bit string from an information. This shorter bit string must be unique.

Sometimes two different information leads to the same thumbprint: it is called a collision. For example MD5 is vulnerable because it is possible to create collision on demand. So it is easy for an attacker to make believe that the information has not changed. The most popular algorithms are SHA-256, SHA-1 or MD5.

Create a thumbprint

To create a thumbprint, the initial information is passed to the input of a hash algorithm. The result is a digest.

Example of thumbprint of “I love Security”:

• MD5: f3f57004371b08ee73327ae2e5353958
• SHA-1: 8c9855b2c81c1e3278a5ce6a771e5c3f74ee09b5
• SHA-256: 1675cd4ee780f6cc04c6d3b54faa2de90fb5b18cdacc974dacf2d99d35307cce

Authenticity

Why sign?

The digital signature enables to ensure the information integrity (using hash algorithm) and the authenticity. Signature is used as in real life. For example, when you subscribe to a service you want:

• A document signed by the company (authenticity);
• Your signature identify you and only you (unfalsifiable);
• Your signature can’t be used for other subscription. If you want to subscribe another service, you have to resign with a new signature (non-reusable);
• Contract doesn’t change over time (unalterable);
• Both side (company and you) can’t deny that they have signed the document (irrevocable).

The digital signature has to be authentic, unfalsifiable, non-reusable, unalterable and irrevocable. When all this property are gathered, the authenticity and the integrity of an information can be verified.

Signature operation

The signature operation is based on asymmetric cryptography. First a digest of the initial information is created and this last is encrypted with the private key. This operation is called the signature.

To validate the signature, the recipient extracts the encrypted digest from the message and use his public key to unencrypt it. Next the recipient creates a digest from the received information and compare it with the previously unencrypted digest. This is the signature checking process.

Figure 5: Signature operation

A good way to remember when the private key is used is to know what information is important in each operation. In signature process, the critical information is the digest so the private key is used to sign. In encryption process, the critical information is encrypted: so the private key is used to unencrypt.

Encryption and signature operation

Now that we are aware about encryption, hash algorithm and signature, let have a look how these elements interact together to make an information confidential, authentic and honest.

Figure 6: Encryption and signature operation

When the signature and encryption are used together, the signing process is done firstly. So this step are performed in this order:

• A digest is created from the initial information;
• This thumbprint is encrypted with the private key (Kprg);
• The thumbprint is added to the initial information (in the same file);
• A temporarily session key is generated (Ks) It will be used to encrypt initial information;
• The session key is encrypted (Kse) with the public key of the rececipient (Kpub);
• Kse is added to encrypted information file. So this file is contains the encrypted information, the Kse and the signature.

When the recipient receives the file from the issuer, it begins by unencrypt file and next to verify the signature:

• The recipient extract the Kse from the received file. This key is unencrypt with the private key (Kprb) to obtain session key (Ks);
• Ks is used to unencrypt information;
• Next recipient extract the encrypted thumbprint;
• The public key (Kpug) is used to unencrypt the thumbprint;
• In the same time, the recipient creates a digest from the previously unencrypted information;
• To finish, the recipient compares the unencrypted thumbprint with the digest generated from unencrypted information. If they match, the signature is verified.

The post Public Key Infrastructure part 1 – Introduction to encryption and signature appeared first on Tech-Coffee.