Certificate Enrollment Web & Policy Service (CES & CEP)

I talked previously here about Certificate Enrollment Web Service CES and Certificate Enrollment Policy Web Service CEP , and in this blog post, I want to share my experience in deploying these services on Windows 2012 R2, using Kerberos Windows Integration as the authentication method.

You can refer to the below Microsoft TechNet pages for step by step details and information:

I guess my previous blog post and these TechNet articles will give you all the information you need to know how to deploy CES and CEP. What is missing is sense of experience and couple of screen shots.

Assumption, you have Microsoft Enterprise CA on your network called CA-1, and it has a common name (Corporate Contoso Issuing CA). You have two Windows 2012 R2 Servers that will be used to install CES and CEP. One is called CES-1 and the other is CEP-1.

We want internal domain joined computers to enroll for certificates using Windows Integration.


Installing CES

First of all, check the installation requirement here, then log on to a new Windows 2012 R2 server using a powerful account

  • Enterprise Admins group.
  • Must have Request Certificates permissions on the target certification authority (CA).

Before you start to install the CES role on CES-1 server, create an SSL certificate with Server Authentication purpose, and put it in the personal computer store on the CES-1 computer.

Now, from Server Manager, follow the below steps to install the CES role:



  • After you finish installing the role using Server Manager, you need to do the Post-deployment Configuration.


  • You have to write down your internal enterprise CA server name. Do not check the (Configure the Certificate Enrollment Web Service for renewal-only mode).


  • Select Windows Integrated Authentication

CES 105

  • On the Service Account page, it is recommended to use custom account and not leave the default. This account is simply the account that will run the application pool.106
  • The account should be:
    • Member of the local IIS_IUSERS group.
    • Has Request Certificate permission on the CA server.
    • Has delegation to do stuff in the CA.
    • Has SPN for HTTP for the URL CES-1.contoso.com.

To do this, go to AD, and create an account called Svc_CES for example, add do the following:

  1. Add it to the local IIS_IUSERS local group on CES-1 server.
  2. Go to the CA server, open the Certification Authority console, check the properties of the CA, and on the Security tab, make sure the account has Request Certificate right.
  3. Open the Account property in AD, go to the delegation tab, use (Trust this user for delegation to specified services only/Kerberos Only), and choose (HOST and rpcss) when targeting the CA-1 server


 Finally register the SPN. Open CMD with domain administration right and register an SPN as per the following:

setspn -s http/CES-1.contoso.com contoso\svc_CES
  • Now select the SSL certificate with subject name CES-1.contoso.com that will be assigned by the installation wizard to IIS web site.


Once the installation is done, go to IIS, and check to see that there is a web site created for CES, and the svc_CES is running the application pool for it.


Important note

My CA common name is (CorporateIssuing CA IV), and it contains spaces. Sometimes, you may need couple of tweaks to make sure the URL format in the IIS is good. Fixes are mentioned here. In my case, although my CA common name contains spaces, I found that everything is working fine and I do not to do any of the mentioned fixes. May be it is because I am running Windows 2012 R2 🙂

Installing CEP

Before you start installing CEP on a different domain joined Windows 2012 R2 server called CEP-1, make sure to request and install an SSL certificate in the computer personal store of this computer.

Now, go to CEP-1 server that should be domain joined and Windows 2012 R2, open Server Manager and start the add roles wizard.


You will be asked to choose an Authentication method (We will use Integrated authentication) in this case.


You then will be asked to choose an SSL certificate, choose the one we installed on this server previously.

Final Steps:

You have to do two things:

  • Configure a friendly name for the Certificate Enrollment Policy Web Service
  • Configure GPO to point targets to the new Policy Enrollment URL.

Details about how to do this can be found here.


[Hash Techniques] : Message Authentication Code MAC, HMAC and Password Salting

In this blog post, I will talk about the authenticity problem in the digital word, and I will start with the basics. It is easier for people to understand encryption (confidentiality), but it becomes tricky when we talk about integrity and authenticity. While Integrity is making sure the data is not modified since the last time we looked at, authenticity means that the recipient may reasonably be certain that a message was truly created by its purported author. Integrity and Authenticity serve different purposes, but they are related to a certain extend. Let us discuss a simple message exchange between Alice and Bob.

Confidentiality via Encryption

Let us suppose Alice and Bob are exchanging a secret message (m) over an open channel. “Eve” on the other hand is listening to the channel. Using an encryption and a shared secret key, both Alice and Bob can exchange their messages without Eve knowing the content, thus confidentiality is ensured.

But there is another problem, Eve can do more than listening to the message if he can have a small control over the channel. In this way, Eve can change the message that Alice sent, so that Bob will receive a different message. The integrity of the message is compromised in this case.
Actually, if Eve has control of the channel, he can do another nasty things. He can learn the message (m), record it and then resend it to Bob, or even delete the message completely so that Bob will not receive anything.


Hash functions alone does not equal integrity 

One solution to the integrity problem is that Alice could compute the hash of the message, and send both the message and the hash to Bob. Bob can then read the message, and then recompute the hash of the message and compare it with the hash value received from Alice. The problem here is that Eve could interrupt the message that Alice sent, create a new message and then send the new message and the hash of the new message to Bob. Bob then will do the same computation and he would think that the message was sent by Alice.

Message Authentication Code MAC

Consider that Bob just received a message. Why should Bob believe the message came from Alice? This means that the message is completely useless.  Eve as we talked before, could send a new message to Bob with a hash value to trick him.

To resolve this problem, Authentication is introduced. Like encryption, authentication uses a secret key that Alice and Bob both know. We will call this the authentication key (Ka). When Alice sends the message m, the following occurs:

  1. Alice and Bob share a secret authentication key Ka.
  2. Alice computes a message authentication code, or MAC as a function of both the message m and the authentication key Ka.
  3. Alice then sends both the message m and MAC to Bob.
  4. Bob will receive both message m and the MAC.
  5. Bob re-computes what the MAC value should be using his own copy of the authentication code Ka, and the received message m.
  6. Bob checks if the received MAC value equals his computation of MAC.

In this way, there is now way that Eve could change the message and send his own hash value, because he does not know what it takes to compute an authentic MAC, as he has no knowledge of the shared secret Ka.


Now Eve wants to modify the message m to a different message m2. Bob will then compute the MAC value as a function of (m2, Ka), and compare it to the received MAC value. But a good MAC function will not give the same result for two different messages, so Bob will recognize that the message is not correct.
Eve can still do nasty things. For example, Eve can replay or resend the same messages to Bob or even change the order for messages. To sort this issue, a sequence numbering can be applied to each message, so that Bob can verify that order and uniqueness of incoming messages.

MAC modes

So how MAC is computed? MAC is a function of a shared secret Ka, and the input message m.  Both parties should share a secret authentication key before starting to use MAC. MAC can be computed via encryption or hashing as we will see next.

Via Encryption (CBC-MAC)

Encryption can be used to compute MAC value, like when using CBC encryption. In this block cipher encryption mode, the message is encrypted using CBC mode, and then we throw away all but the last block of cipher text.

Via Hashing (HMAC)

It is so trivial to use hash function to compute the MAC. To do this, you perform the following computation:

h(Ka XOR a || h(Ka XOR b || m))

  • XOR = Exclusive OR
  • || = Concatenation
  • h = hashing
  • a,b = padding constants


Salting vs MAC

Hashing can be used in many different ways. You can use it with an extra data and computation to get different usages. Here are two examples:

  • Add a shared secret key to the message and you can use Hash as MAC to preserve integrity and authenticity.
  • Add some extra (not secret) data to the message before you hash it, and you make your hash function more resistant to rainbow attacks [salting technique]

So we have talked about MAC in the blog post, so I will be talking about Salting technique here.

Password salting is a way of making password hashing more secure by adding a random string of characters to passwords before their hash is calculated, which makes them harder to reverse.

Important points :

  • In MAC, the shared key is secret while the message is not.
  • In Password Salting, the password is the secret while the additional data (Salt) is not secret
  • No two different passwords should use the same Salt value.

We use salting when storing passwords. Passwords are stored using hash techniques and never using encryption. The reason is that encryption is two direction operation, while hashing is one way operation. The most famous attack against hashing is a technique called rainbow tables, where all words and phrases in the dictionary are hashed, and a look-up is made to compare the stored hash value with the rainbow table content for a match. So if someone has his password as (Password), then most probably the hash value of this password exist in the rainbow table, and thus can be racked.

 Unsalted passwords chosen by humans tend to be vulnerable to dictionary attacks since they have to be both short and meaningful enough to be memorized. Since salts do not have to be memorized by humans they can make the size of the rainbow table required for a successful attack prohibitively large without placing a burden on the users.

Final Thoughts

MAC can be said to provide authenticity and integrity to some extend. TLS is a practical example of where MAC is being used in real life.

Salting is used when storing password hash values to make it more resistant to attacks using rainbow tables. You should always use different salt for each password hash.

You should never use the same key for authentication and encryption unless you know what you are doing. For example, do not use the same key for encryption and for the MAC shared key.

In PKI world, digital signature is the equivalent of MAC. But instead of having the same shared secret between Alice and Bob, in digital signature, Alice computes the MAC using her private key, while Bob re-computes the MAC using Alice’s public key. While MAC is similar to digital signature, MAC is faster, but on the other hand, does not provide non-repudiation as digital signatures do.

Hash Function – Simplified in cool slides

I was presenting the concept of hash function to some developers who have little knowledge about cryptography, and it was very challenging to simplify the concept in a visual way. So I decided to use an extra ordinary example to accomplish this job.

Here we go !!


Facebook wants to buy WhatsApp, and they want to send the agreement over the internet, but they want the agreement to be confidential.

hash vs -MAC  1

Now both Facebook and WhatsApp have a shared secret key Key(K), that no one else know about. So Facebook will encrypt the agreement using an encryption algorithm using the shared secret key Key(K).

hash vs -MAC  2

WhatsApp on the other side, will decrypt  the message using the same shared secret key, and everyone is happy. Since the same key is used for encryption and decryption, we will call this (Symmetric Encryption)

hash vs -MAC  4

Now, what if some third party tries to change some bits during the transmission of the encrypted agreement? This third party will not able to see the content of the agreement, because it does not know about the encryption key Key(K), but it can change couple of bits.

hash vs -MAC  5

So now when WhatsApp tries to decrypt the modified the message,  they may end up with a funny output 🙂 Now WhatsApp thinks that the offer is 229 Billion.

hash vs -MAC  6


So how to protect the integrity of the agreement during transmission?

hash vs -MAC  7

The answer is Hash Functions. Hash functions are taking any size of data, and produce a unique fixed size output. It is impossible to take the output of the hash function and reproduce the message again. This is why we call it One-Way function.

hash vs -MAC  8

The other property of hash function is collision free (almost free). This means that it is so hard to generate two different messages that produce the same hash output. This also means, that no matter how many time you hash a message, the output will be always the same.

hash vs -MAC  9

Any simple change in the input message will produce a complete different hash output.

hash vs -MAC  10

So now Facebook will do things differently. it will start with encryption to ensure confidentiality.

hash vs -MAC  11

It will also compute the hash  of the message to ensure integrity.

hash vs -MAC  13

Both are to be sent to WhatsApp.

hash vs -MAC  14

Now WhatsApp will decrypt the message using the shared secret key, and now to ensure that the message was not changed in transmission, it will also compute the hash of the message received, and compare the value with the hash value sent by Facebook. If both unique values are equal, then everything is okay.

hash vs -MAC  15

I hoped you enjoyed the cool presentation. Keep in mind, that there is a lot to be said here. For example, you should use MAC techniques to authenticate the sender in addition to just hash function.

Download the slides

Feel free to use the slides. Download them : Hash Function Simplified

Backup Certificate Authority PowerShell Script

Hi everyone,

As it is so important to backup your Certification Authority servers, automating this task is a bonus thing here.

As you may already know, you need to backup usually the following:

  • CA Private Key.
  • CA Database Files.
  • Configuration in the registry.
  • Perhaps the CAPolicy.inf file if any.

I was browsing the internet and i have found a brilliant PowerShell script that will do the trick in a professional way indeed.

The script is written by a PKI geek and you can download his PowerShell Script here. [ I guess it is relocated here:

http://www.sysadmins.lv/content/scripts/Backup-CertificationAuthority.ps1 ]

The script will backup all the previous files in a nice way. I have tested the integrity of the script by trying to restore a CA from the backed up files, and everything was working fine.


Now, you can create a scheduled task, with :

Program/script: %SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe

Add Arguments(optional) : type the path of your PowerShell Script, for example C:\Backup_CA.PS1

Finally, make sure it is running as a SYSTEM security context.


Cryptography Fundamentals

Hi everyone,

It becomes so challenging to describe cryptography for normal people or even to your IT colleagues. I was asked to present couple of PowerPoint slides for 20 minutes to introduce this topic to couple of developers, so that they will have sense of responsibility to enhance their code security.

Crypto Slide

Download PowerPoint Slides

Please find my slides here

See Also

Deploy Offline Root CA in Windows 2012 R2 – SHA-2 Ready

Contoso Corporation decided to deploy an offline Root Certification Authority. The security team started to prepare for deploying the offline root CA. The idea is to create an Enterprise PKI infrastructure that uses advance cryptography and supports SHA-2

Prepare the Windows Machine

Since the root CA will be offline most of the time, it is a recommended to deploy it on a virtual machine.

Machine Specifications:

  • 2 GB RAM.
  • Normal processing power.
  • 40 GB C drive at a minimum.
  • Network Card

Note: the network card is needed only during the installation of the Root CA and taking backup. After you finish deploying the Root CA, disconnect the network card and shut down the machine.

Windows Specifications:

  • Windows 2012 R2 (Standard or Datacenter) [Preferable not Windows Core].
  • Machine name : ContosoRootCA.
  • Create the following folders under the C:\ Drive
    • C:\CA Database Files\CertDB
    • C:\CA Database Files\CertLog

Lock Down the Windows Machine

It is so important to secure the Root CA server. Here is a TechNet article talking about the same subject and applies to all Windows Server versions. Below is my recommendation:

  • Apply Windows patches to the Root CA machine.
  • Disable CD-ROM Autoplay.
  • Disable LM and NTLMv1 authentication protocols.
  • Enable and configure inbound and outbound firewall rules  using the built-in Windows Firewall.
  • Enable Audit Object Auditing using the local security policy [This is needed to audit certain CA actions]

Enterprise PKI Root CA 3

  • I recommend also to configure the Password Policy using local group policy. In the Local Security editor,configure the password policy as per the below figure:Enterprise PKI Root CA 5
  • Rename the local administrator account and the guest account, then disable the guest account, and assign a complex password to the local administrator account.You can use the local group policy to help you and enforce some of those tasks:

Enterprise PKI Root CA 6

  • After you finish installing and configuring this Root CA server, disconnect the network card, and power the machine off. I recommend also to export the VM (the OVF file if you are using VMware) on a removable media or backup tape and store it in a very secure location.


First thing to do is to install the Active Directory Certificate Services and their management tools. I prefer doing the whole installation in PowerShell as this give me the ability to rebuild the whole environment easier.

Since we are working with Windows 2012 R2, then the PowerShell ISE editor is available for us. I prefer open it and run all the PowerShell commands from it.

To open the PowerShell ISE, go to the Windows Search, and type PowerShell ISE

Enterprise PKI Root CA 1

Make sure that the PowerSehll execution policy is set to RemoteSigned by running

Set-ExecutionPolicy RemoteSigned

Then type:

Install-WindowsFeature Adcs-cert-Authority -IncludeManagementTools
Install-WindowsFeature RSAT-ADCS-Mgmt

Enterprise PKI Root CA 2


The CAPolicy.inf file provides Certificate Services configuration information, which is read during initial CA installation and whenever the CA certificate is renewed. The CAPolicy.inf file defines settings specific to root CAs, as well as settings that affect all CAs in the CA hierarchy.

By default, the CAPolicy.inf file does not exist when  Microsoft Windows Server  is installed. It should be manually created in the Windows operating system folder (%windir% folder). When Certificate Services are installed, the operating system applies any settings defined in the CAPolicy.inf file.

While still in PowerShell ISE Editor, type the following to create a file called CAPolicy with extension .inf :

notepad c:\windows\capolicy.inf

Copy and paste the below into the capolify.inf file you had created.

Signature="$Windows NT$"


Notice="Corporate Policy Statement"





  • <Renewalkeylength> : Only used when you renew your CA certificate.
  • <RenewalValidityPeriodUnits> and <RenewalValidityPeriod> : Specify the validity of the CA certificate.
  • <CRLPeriod> and <CRLPeriodUnits> : Specify the frequency of the CA Revocation publication, which is “which is how often you will be bringing up the offline root CA in order to regenerate the CRL“.
  • [CRLDistributionPoint] : Leave blank for Root CA.
  • [AuthorityInformationAccess]: Leave blank for Root CA.
  • [LoadDefaultTemplates = 0]: Prevents CA for publishing and start using default template and cause undesired enrollment.
  • [AlternateSignatureAlgorithm = 0] : configures the CA to support the PKCS#1 V2.1 signature format for both the CA certificate and certificate requests. Because it is not widely supported, we will keep it as 0.
  • [PolicyStatementExtension]: is the location the points to your policies [Certificate Practice Statement CPS and Certificate Policy CS]

Note:  CAPolicy.inf Usage is defined here and here.

Install Certification Authority Services

Run the following PowerShell Command:

 Install-AdcsCertificationAuthority -CAType StandaloneRootCA `
 -CACommonName "Contoso Corporate Root CA II" `
 -CADistinguishedNameSuffix "OU=PKI,O= Contoso,C=US" `
 -KeyLength 2048 `
 -HashAlgorithmName SHA256 `
 -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
 -DatabaseDirectory "C:\CA Database Files\CertDB" `
 -LogDirectory "C:\CA Database Files\CertLog" `
 -ValidityPeriod Years `
 -ValidityPeriodUnits 20

Enterprise PKI Root CA 7

Configuring Certification Authority Services


Open CMD and run Certutil -CAInfo , and verify that the CA type is  Stand-alone Root CA.

Enterprise PKI Root CA 8

Run Certutil -getreg and verify the database and log locations

Enterprise PKI Root CA 9

Map Namespace of AD

Because the offline root CA is not connected to the domain and does not automatically publish the CRL to Active Directory, you must set a key in the registry to assign a variable that will point to your Active Directory namespace. To do this, at a command prompt, type the following command and then stop and start the CA service:

certutil.exe –setreg ca\DSConfigDN CN=Configuration,DC=contoso,DC=com

Where DC=contoso,DC=com is the namespace of the forest root domain. This setting is primarily required for CRLs and CA certificates (AIA) that are published in Active Directory.

This registry value sets the %6 replacement token that is required for the CRL location attribute. You have to restart the certificate services in order for changes to take effect.

CA Time Interval (Frequency) settings

Note that during the installation, we specified the validity period for the CA certificate (20 years).This is because there is no parent CA from which the validity period can be specified. Because this CA will issue future certificate ,there must be a way to specify the validity period for issues certificates. So run the following command from the CMD on the root CA to specify the validity period for the second tier issued certificates.

certutil -setreg ca\ValidityPeriodUnits 10
certutil -setreg ca\ValidityPeriod "Years"
net stop certsvc & net start certsvc

Now, we have to define the CRL interval, CRL Delta interval, and the CLROverLap period by running the following on the Root CA:

certutil.exe –setreg CA\CRLPeriodUnits 26
certutil.exe –setreg CA\CRLPeriod “Weeks”
certutil.exe –setreg CA\CRLDeltaPeriodUnits 0
certutil.exe –setreg CA\CRLDeltaPeriod “Days”
certutil.exe –setreg CA\CRLOverlapPeriodUnits 12
certutil.exe –setreg CA\CRLOverlapPeriod “Hours”

Notice that we have disabled Delta CRL Period, because it is not recommended to enable delta CRLs on the Root CA. To learn more about the best practices of setting these values, please check my previous blog post here.

Configure CDP

CDP stands for Certificate Revocation List Distribution Points, and it points the consumer of your digital certificates where to locate the CRL for your Root CA.

It is recommended to publish the CRL in both Active Active Directory and also on a http web site. Make sure you have a web site accessible using http://pki.contoso.com/CertEnroll , so that we can through the CRL files under that virtual directory.

First of all, use PowerShell to run the following command to empty the default CDP locations

$crllist = Get-CACrlDistributionPoint; foreach ($crl in $crllist) {Remove-CACrlDistributionPoint $crl.uri -Force};

Then use CMD to configure the new CDP locations [not from PowerShell]:

certutil -setreg CA\CRLPublicationURLs "1:%WINDIR%\system32\CertSrv\CertEnroll\%3%8%9.crl\n10:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10\n2:http://pki.contoso.com/certenroll/%3%8%9.crl"

The numbers appearing in the previous command represent option variables that you add up. For example, (\n2) means “Include in the CDP extensions of issued certificates“, while (\n10) is the combination of option 8 and option 2, so it means “Include in the CDP extensions of issued certificates” and “Include in all CRLs. Specifies where to publish in the Active Directory when publishing manually“. The below table list those variables:

0 :No Options Defined
1 :Publish CRLs to this location
2 :Include in the CDP extensions of issued certificates
4 :Include in CRLS. Clients use this to find Delta CRL Locations
8 :Include in all CRLs. Specifies where to publish in the Active Directory when publishing manually
64 : Publish Delta CRLs to this location
128 :Include in the IDP extension of issued CRLs

Where as the variables appearing with (%) are another set of variables that you can find more information about here.

Now run certutil.exe -crl command from CMD to generate the new CRL, and drops it as configured, into “C:\Windows\System32\CertSrv\CertEnroll” directory.

Configure AIA

Authority Information Access AIA locations are URLs that are added to a certificate in its authority information access extension. These URLs can be used by an application or service to retrieve the issuing CA certificate. These CA certificates are then used to validate the certificate signature and to build a path to a trusted certificate.

First of all, use PowerShell to run the following command to empty the default AIA locations

$aialist = Get-CAAuthorityInformationAccess; foreach ($aia in $aialist) {Remove-CAAuthorityInformationAccess $aia.uri -Force};

Then use CMD to configure the new AIA locations [not from PowerShell]:

certutil -setreg CA\CACertPublicationURLs "1:%WINDIR%\system32\CertSrv\CertEnroll\%1_%3%4.crt\n2:ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11\n2:http://pki.contoso.com/certenroll/%1_%3%4.crt"

Auditing Certification Authority Services

To enable Auditing on the Root CA server for Certificate Services operation, run the following command from CMD:

certutil -setreg CA\AuditFilter 127

Publish to Active Directory

Now, if you go to C:\Windows\System32\CertSrv\CertEnroll , you will see two files:

  • Root CA Public Key (Certificate)
  • Root CA Revocation List

Enterprise PKI Root CA 10

Copy those two files to your corporate domain controller (C:\) drive for example, and log on to your domain controller with an account that is member of both Domain Admins and Enterprise Admins. Open an elevated PowerShell and enter the following commands, using the file names for your instance. This will publish the offline root CA information to AD, just as if it were an online CA. By doing this all domain joined clients will automatically trust your root CA. If you have standalone computers, then you can import the .crt file into their trusted certificate store.

certutil.exe –dspublish –f “ContosoRootCA_Contoso Corporate Root CA II.crt” RootCA
certutil –f –dspublish “Contoso Corporate Root CA II.crl”
certutil.exe –addstore –f root “ContosoRootCA_Contoso Corporate Root CA II.crt”

The first command adds the offline root CA public certificate to the AD DS, Configuration naming context. The second and third commands add the root CA and the root CRL to the relevant certificate stores on the subordinate CA.

See Also

SHA-1 Broken, Migrating to SHA-2

SHA-1 is broken, and there is bold moves from Microsoft to move away from SHA-1 after announcing their deprecation plan for SHA-1 on November 2013. If you want to know the whole story about SHA-1 and why it is being phased out by everyone, then read this blog post [PKI Certificate Services SHA-1 Deprecation]

I spent sometime reading and understanding the answer of the following questions:

Moving to a new blog

I am moving to a new blog format, please follow this link to continue reading 🙂


What makes a CA capable of issuing certificates that uses SHA-2?

This is the million dollars question:) We are talking about Microsoft Certification Authority Servers here.

  • The short answer is that this depends on the Cryptographic Provider that CA is using. And since each Windows version ships with specific set of providers, you may need to upgrade your CA to a newer version of Windows in order to support SHA-2.
  • Even if you are using a cryptographic provider that supports SHA-2, you need to instruct the CA to use SHA-2 for future signing requests.

Check these posts to help you get more familiar about this topic:

Moving to a new blog

I am moving to a new blog format, please follow this link to continue reading 🙂


SHA-2 Support – Migrate your CA from CSP to KSP


In this blog post, I will be talking about [Migrating a Certification Authority Key from a Cryptographic Service Provider (CSP) to a Key Storage Provider (KSP)], inspired from Microsoft TechNet Article talking about the same topic. I will try to give you more information and more examples about this topic, and how this plays big role in your journey to phase out SHA-1 and start using SHA-2

Please read the following topics before continue reading this blog post:

I will not discuss why and when you should migrate from CSP to KSP. However,I will only talk about the steps needed to migrate. After the migration, you can then reconfigure the CA to issue certificates by using the SHA-2 hash algorithm rather than the less secure hash algorithm of SHA-1

Moving to a new blog

I am moving to a new blog format, please follow this link to continue reading 🙂



Cryptographic Providers: SHA-1 & SHA-2 support

As everyone is talking about phasing out SHA-1 and Microsoft had announced their deprecation plan for SHA-1 already, I would like to dedicate a full blog post to talk about Cryptographic Providers and the role they play when it comes to supporting SHA-2

It cannot be ignored that basic knowledge about this topic is necessary when you phase out SHA-1 in your enterprise and start using/issuing new certificates that uses SHA-2 hash function.

I highly recommend that you read my previous blog post talking about hash functions, and why SHA-1 should be phased out. This blog post shows how to move away from SHA-1 and gradually move to SHA-2.

In Summary, your choice to move away from SHA-1 and start using SHA-2 depends directly on the type of Cryptographic Providers you are using.


Moving to a new blog

I am moving to a new blog format, please follow this link to continue reading 🙂


PKI Certificate Services SHA-1 Deprecation

So everyone one is talking about SHA-1 and how it becomes less secure hash function. People are talking about a quick phase out and move to more secure alternative. So what’s the story?

I would like to share with you my own thoughts and research in the whole SHA1 being insecure and the need to go to another alternative. I will also talk in future posts about how to migrate your Microsoft PKI to support the new SHA-2 hash function.

But i cannot start talking about how to solve the problem before spending some time analyzing the current situation and talking about some cryptography theories. It is hard to jump to conclusions and solutions if you are not fully aware of the current situation.


This blog post is moved to my new blog platform here:


Upgrade your Root CA to Windows 2012 R2 – PKI

I was doing an upgrade for a Certificate Authority Windows Server acting as a stand alone Root CA from Windows 2008 R2 to Windows 2012 R2. The procedure is the same if you are upgrading form previous Windows versions.

To the upgrade, you have to do the following:

  • Backup the old Root CA.
  • Install Certificate Services in a new Windows 2012 R2.
  • Restore the DB, Private Key, and the CertSvc registry key on the Windows 2012 R2 server.
  • Perhaps decommission or destroy the old Root CA.

Backup the old Root CA

Let me say this. A Certification Authority Service is nothing but three components:

  1. The Certification Authority Private Key.
  2. The Certification Authority Database Files (DB and Log) : here is where all issuer and revoked certificate information resides.
  3. The Certification Authority Configuration : This is where all CA settings are preserved, like the CA CDP and AIA locations. The whole configuration is stored in this registry key [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc].

Certificate templates are stored in Active Directory under the Configuration Partition, so no need to worry about them.

 So let us start performing a full backup of the old CA server:

  • Log on to your Root CA, open the Certificate Authority console.
  • Right click the CA name and go to All Tasks> Back up CA..


  • Click Private key and CA Certificate and Certificate database and certificate database log. Choose a backup directory
  • You have to protect the exported private key with a password. Enter a strong password. Click Next and you are done.



  • Now open the registry and Export the following registry: Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc.


  • It is also a good idea to backup the CAPolicy.inf file located at C:\Windows directory if it exist.
  • Finally, make sure you document the state of the old Root CA, like:
    • Server Name
    • Drives layout
    • Location of the folders where the CA database and logs are stored
  • I also recommend taking Full Server Backup and System State backup to the old Root CA server just in case. System State backup is the best bit for restoring a CA server.

Note: A good way to document the configuration of the CA is to use certutil –getreg command [check this article]. You can output the result in text file if you want by typing:

certutil –getreg  > C:\oldCA_config.txt


Restore Root CA to Windows 2012 R2

Install Windows 2012 R2 on a new server with same name and drives layout, make sure it is fully patched, and then follow the below steps:

  • If in the old Root CA, you are storing the CA database in C:\DB and the CA DB logs at C:\Logs, then make sure to create these folders in advance on the new Windows 2012 R2 server.
  • It is recommended that drives match. So if you have C and D drives in the old Root CA, make sure you have the same drives on the new Windows 2012 R2 server.
  • Go to Server Manager and Click Add roles and features.


  • Click Active Directory Certificate Services.


  • Since this is Root CA, only pick the Certificate Authority role service. Complete the wizard till the end.


  • Go to Server Manager again, click the flag icon that has a warning sign on it, and choose to Configure Active Directory Certificate Services... .


  • Select Certification Authority for services to configure.





  • In this step, you have to choose the old Root CA private key file that you have from your backup.


  • In the Certificate Database location page, make sure to choose the same location the old Root CA has. Pre-create folders if you are using custom locations.



  • Now we have installed the Root CA on a new server and the only thing we have restored is the CA Private key.
  • Open the Certification Authority Console. Right click the CA name, and choose All Tasks > Restore CA.. .


  • Choose only Certificate database and certificate database log. No need to choose Private key and CA certificate as this was restored during the installation.

Note: An important note to mention here is the following. If you have clicked Browse and you’ve picked the folder named Database that the Backup wizard in the old Root CA generated before, you will get an ugly error. The restore wizard expects you to choose a folder that contains a sub-folder called DataBase, not to choose the DataBase folder itself.


  • Finally, browse the registry to Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc, and backup that registry location just in case.
  • Then go to to your backup, copy the registry key backup that you made for the same registry location, right click it and click Merge.


  • The registry keys you have merged contains all the CA settings, including the CDP and AIA extensions.  Just to make sure everything is fine, open the CA properties on the new Root CA, and compare them with the old Root CA properties. Pay attention to the Extension tab.

Final Tasks

Finally, I would go and use the Backup CA wizard in the new CA, to backup the private key and database files, and i would also using Windows Backup to take Full Server backup to the new CA just in case. Do not forget to reset the local administrator password and use complex one instead.

As for the old CA, usually it is a virtual machine, i would typically destroy the VM and that’s it.

I want also to recommend this YouTube video that goes through the whole process.

Public Key Infrastructure PKI Presentation PPT – how it works and why we need it

Hi everyone,

That day, I was presenting PKI to people who do not know anything about cryptography, yet I wanted to sell them the PKI service.  So i prepared a presentation that shows from logical and business perspective why we need PKI and how it works.

You can download the PowerPoint presentation here: PKI_Overview

Note: The presentation contains notes for each slide, so it can help you figure out what each slide is talking about.

Please watch this presentation video online also :





How to set your SLA for Certificate Authority?

When I was planning a PKI solution for one of my customers, the first thing that came to my mind is how to define the SLA for the PKI solution? That is, how much time can a corporate wait for a failed CA server for example?

This led me to another question, what is the consequences for having CA down? To answer this question, I may ask myself: What cannot be done if a CA is down.

The answer is simple, if CA is down, two things are immediately get affected:

  1. Your ability to issue certificate
  2. Your ability to recover keys
  3. Your ability to sign CRLs

Well, in small environments, you do not care that much for point 1 and 2, and your focus shall go to point 3. Let me start by stating the urgency of signing CRL.

If you do not sign CRLs and publish them before the current CRL expires, any service that performs CRL checking will eventually stop working or accepting your internally issued certificates. This is a huge thing!!

So, point 3 is the most important factor to look at when you have failed CA. You can do one of two things:

  1. If you possess the private key of the CA, you can manually sign and publish a CRL.
  2. You have to recover the CA before the current CRL expires.

As point 1 is not an easy thing or normal thing to do, my focus is point 2, which is fixing the CA before the current CRL expires.

So, if I have a 3 days CRL validity period, then I can have as much as 3 days until the current CRL expires (this is when the CA published a CRL and fail immediately), or I can have up to one second before the current CRL expires (this is when the CA published a CRL and failed after 3 days and right before publishing the next CRL).

Well, this opens the door for so much tolerance an inaccuracy in defining an SLA to recover a CA, right?  The option that give you more flexibility is CRL overlap.


“Let us focus on how Base CRLs works with overlap. As mentioned there is some additional configuration that can be performed that can optimize your CRL publishing intervals so that you have adequate time to perform Emergency CRL Signing or to recover your CA.  What will need to be configured is the CRL Overlap Period.  In order to configure the CRL Overlap Period both the CRLOverlapUnits and CRLOverlapPeriod registry settings need to be configured.
So, in my previous example my CRL had a validity period of 3 days.  What I can do now is add a CRL Overlap Period of 3 days.  With this configuration, my CRL will be valid for a period of 6 Days.  However, at 3 days a new CRL will be published as well.  This is illustrated in the graphic below:


In the example illustrated in the graphic above, CRL 1 will be valid for a period of 6 days.  CRL 2 will be published at Day 3.  So, if my CA fails between Day 1 and Day 3, I would still have 3 Days (Day 3 through Day 6) to perform Emergency CRL signing or to recover my CA in event of failure.  If my CA fails between Day 3 and Day 6, there is a new CRL (CRL 2) that is valid through Day 9.  So, in short if my CA fails between Day 3 and Day 6, I still have at least 3 days to perform Emergency CRL Signing or to recovery my CA, before revocation checking starts to fail.  And the reason that I have the 3 days is the CRL Overlap Period extended out my CRL for 3 days and staggered the Next Publish and Next Update times by 3 days”

[Quoted text are taken from http://blogs.technet.com/b/xdot509/archive/2012/11/26/pki-design-considerations-certificate-revocation-and-crl-publishing-strategies.aspx]

So far we have identified the concept of CRL overlap. This is an important thing to consider when planning for CA SLA. CRL overlap also helps in the following cases:

  • Active Directory replication delays;
  • CRL distribution from CA server to revocation server delays;
  • Temporary network connectivity issues;
  • Unexpected server failure.

CRL Overlap Configuration:

Under the Certification Services configuration hive in the registry two values control the overlap period for the base CRL and two registry values define the overlap period for delta CRL creation:

HLKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA Name>:

  • CRLOverlapPeriod=REG_SZ:Hours|Minutes      (Units)
  • CRLOverlapUnits=REG_DWORD:0x0       (Value)
  • CRLDeltaOverlapPeriod=REG_SZ:Hours|Minutes       (Units)
  • CRLDeltaOverlapUnits=REG_DWORD:0x0     (Value)

You can verify the settings for the above registry keys on your CA computer with the following commands:

  • certutil -getreg CA\CRLOv*
  • certutil -getreg CA\CRLDeltaOv*

Applies to both Windows 2008 R2 and Windows 2012: Microsoft states that the default setting is 10 percent from the CRL lifecycle, and if not configured manually, it will have maximum of 12 hours. If configured manually, the overlap period cannot exceed the publishing period. [http://technet.microsoft.com/en-us/library/cc731104.aspx]

I could not find a blog post that describes how CRL overlap works better than this :http://social.technet.microsoft.com/wiki/contents/articles/20652.how-thisupdate-nextupdate-and-nextcrlpublish-are-calculated.aspx

CRL Certificates Extensions 

There are three terms used to describe the base and delta CRLs:

Effective Date (aka ThisUpdate):

[The term Effective date is used in the Windows certificate dialog while certutil.exe and the RFC name this field thisupdate.]
Mandatory field. The date that a CRL became effective. The effective time, by default, is set to 10 minutes prior to the current date and time to allow for clock synchronization issues.

ThisUpdate = MaximumOf(CurrentTime – ClockSkewMinutes, CANotBefore)

In other words, usually ThisUpdate field value is CurrentTime minus ClockSkewMinutes (10 minutes by default). However, there is an exception when CA certificate is renewed. In this case, CurrentTime minus ClockSkewMinutes may occur prior to CA certificate validity. In this case, ThisUpdate field value equals NotBefore value of the CA certificate.

Next CLR Publish

 This is non critical extension (optional), which means that it is not mandatory for the application to consume it. This indicates the date and time when a Windows CA will publish a new CRL. When a Windows computer uses a CRL for certificate verification it also examines the Next CRL Publish extension. If the Next CRL Publish date is already in the past, it connects to the CRL distribution points (referenced in the certificate) and attempts a download of a newer CRL.

The time after the Next CRL Publish and before the Next Update is a buffer time to allow Windows computers retrieval of a CRL before the CRL has actually expired, and a buffer for you to recover a failed CA.

NextCRLPublish (Base CRL) = MinimumOf(CurrentTime + CRLPeriod, CANotAfter)

NextCRLPublish (Delta CRL) = MinumumOf(CurrentTime + CRLDeltaPeriod, CANotAfter)

Note: There is a feature called (CRL prefetching) that allows certificate consumer to look at the Next CRL Publish extension and get newer CRLs in case they are available, that is the time between Next CRL Publish and Next Update. The way how CRL pre-fetching work is beyond the scope of this blog post, but it is worth knowing that if the CRL is locally cached, and under certain conditions, download of new CRL might be skipped, even if Next CRL Publish date is already in the past.

(please see http://technet.microsoft.com/en-us/library/ee619723(v=ws.10).aspx).

If CRLDeltaPeriod is equal to zero, Delta CRL is not published. CRL cannot be valid after CA certificate expiration.

Next Update

Mandatory field. The date and time that a Windows client considers as the expiration date of the CRL. From an operational viewpoint, this is the most critical information. If this date passes, Windows computers will invalidate certificates that are checked against this CRL. You have to recover a failed CA before the date specified in this extension.

NextUpdate (Base CRL) = MinimumOf(NextCRLPublish + InterimBaseCRLOverlap, CANotAfter)

NextUpdate (Delta CRL) = MinimumOf(NextCRLPublish + InterimDeltaCRLOverlap, CANotAfter)

Public key Infrastructure from IT and Business Perspective

Imagine that the internet is a city, it would be the most crowded city in the world. Inside this city, you would also discover that not everyone is who they seem to be even yourself.

Internet like a city

Inside a small company and with face to face interactions, you would use badges with pictures and names on them to identify people working in the company. If the badge has the company’s logo, then you can assume that the person is authentic.


When it comes to digital collaboration and e-commerce transaction, you usually to deal with people who you did not meet before, maybe located at the other side of the word, but yet you need a way to verify their identity and perhaps send them information that no one should see across the open internet.

Public Key Infrastructure is a framework that helps identify and solve these problems for you by establishing safe and reliable environment for electronic transactions in the internet. It uses public key encryption techniques to protect the confidentiality, integrity, authenticity and non-repudiation of data.

PKI Framework

People and services in the internet are issued a digital certificates that uniquely identify them in the digital word, much like the corporate badge with your photo and name on it.

The Certificate Authority is the component responsible of issuing digital certificate after verifying the identity of the requester. If you trust the certificate authority, then you can trust digital certificates it issues.

A certificate authority maintains a revocation list that contains all digital certificates cancelled or suspended before their expiry dates.

Each digital certificate contains a pair of keys. A private key kept secretly by the holder of the digital certificate and corresponding public key which is known to others.

Digital Certificate Picture

This pair of asymmetric but matching keys will be sued for data encryption to ensure confidentiality.

Take email message transmission as an example. A sender can use the intended recipient’s public key to secure the content of an email message. When the recipient receives the message, he will need to use the corresponding private key that he keeps to unsecure the message. By doing so, the confidentiality of the email content will be secured.

Furthermore, integrity, authenticity and non-repudiation of the email message can happen by creating a message digest to ensure the message is not altered during transmission.

Public Key infrastructure enables a wide variety of technologies, like SSL for secure browsing and transactions, enhance your wireless security by implementing industry standard verification and authentication, secure remote access to your enterprise network. In addition, you can start providing encryption and digital signature to your corporate email communication, and maybe encrypting your sensitive documents on your local drives. As passwords are very basic method for authentication, two factor authentication is the best way to raise your authentication level by implementing smart cards.

Public Key Infrastructure Technologies

Watch this post as a YouTube Video