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.

ces-cep11

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:

CES 1

CES 2

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

CES 3

  • 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).

CES 4

  • 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

ces-cep2

 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.

ces-cep3

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.

ces-cep4

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.

CES-CEP5

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

CES-CEP6

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.

MAC1
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.

MAC2

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.

MAC3

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

MAC6

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 !!

Problem

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

Solution

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.

CA_Backup_Script

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.

Bckup_CA_Task

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.

Prerequisites 

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

CAPolicy.inf

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.

 
[Version]
Signature="$Windows NT$"

[PolicyStatementExtension]
Policies=InternalPolicy

[InternalPolicy]
OID= 1.2.3.4.1455.67.89.5
Notice="Corporate Policy Statement"
URL=http://www.contoso.com/PKI/policy.aspx

[Certsrv_Server]
RenewalKeyLength=2048
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=20
CRLPeriod=years
CRLPeriodUnits=1
CRLDeltaPeriod=Days
CRLDeltaPeriodUnits=0
LoadDefaultTemplates=0
AlternateSignatureAlgorithm=0

[CRLDistributionPoint]
Empty=True

[AuthorityInformationAccess]
Empty=True

Where:

  • <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

Verification

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:

Healthy Enterprise PKI infrastructure 

Before jumping into how to migrate to a SHA-2 ready PKI infrastructure, I want to help you picture a healthy PKI infrastructure that will not be affected by the deprecation plans of SHA-1.

Microsoft’s SHA-1 deprecation plan affects the following for Enterprise PKI deployments:

  • SSL and Code Signing –  end-entity certificates   >> these should be SHA-2 and code signing certificates should be time-stamped.
  • Intermediate CA certificates >> the certificate for the CA server acting as intermediate CA server.

Saying that, the below are not affected by Microsoft’s SHA-1 deprecation plan, and can keep using SHA-1:

  • The Self-Signed Certificate of the Root CA server: So only the self signed root CA server can keep using SHA-1. Microsoft said “The SHA1 deprecation policy does not impact SHA1 privately deployed root certificates, because Windows relies on other means to validate root certificates besides the signature” . Google Chrome will not issue warning also for privately deployed root CA certificates.
  • Al self signed certificates : for the same reason self signed root CA certificate is excluded from the deprecation policy.

sha-1 Deprecation

Let me give you an example. If you have an Offline Root CA server and an online Issuer CA server (Intermediate) that produces end-entity certificates, then this two-tiered private PKI deployment should look like this to comply with SHA-2 and avoid any interruption caused by Microsoft’s SHA-1 deprecation plans:

  1. For the Privately deployed  Root CA server:
    • The Root CA Certificate that is self-signed can be either use SHA-1 or SHA-2 as it is not affected by SHA-1 deprecation plan.
    • When the Root CA server signs a CRL, or signs a certificate request, this signing operation should be performed by SHA-2
    • According to the previous point, the Root CA server should be able of performing SHA-2 operations even if its self-signed certificate is using SHA-1
    • In order to do signing operations using SHA-2, the Root CA should be using cryptographic provider that supports SHA-2 (i.e Microsoft Key Storage Provider)
  2. For the Intermediate Issuing CA server:
    • The CA certificate itself should be using SHA-2.
    • Any signing operation done by the server should be done with SHA-2.
    • In order to do signing operations using SHA-2, the issuing CA should be using  cryptographic provider that supports SHA-2 (i.e Microsoft Key Storage Provider)
  3. For end-entity SSL and Code Signing Certificates
    • Should be using SHA-2 and the certificate chain should be using SHA-2 except for the root CA certificate, as the root CA certificate can use SHA-1 or SHA-2
    • For code signing certificates, a time-stamp should be included to validate the signature.

SHA-2 Green

SHA-2 RED3

SHA-1 Red1

 Migration Plan

I guess it is wise to start from now, and to prepare your self so that you will not be affected by Microsoft deprecation plan for SHA-1. I also get to know that many big companies are requiring SHA-2 certificates for their systems from now. VMware is one of them for sure.

The time you spent in designing and planning the migration now, will pay off for many years. I read once that PKI is a 90% designing science, and 10% doing and implementing. So let us start by describing our migration plan. I will do my migration plan on two tiered PKI infrastructure (Offline root CA and one intermediate issuer CA). The same applies if you have more tiers.

Approach 1 : “Side by Side , different Root CA”

Keep your current PKI infrastructure as is, and deploy a parallel PKI infrastructure (on Windows 2012 R2 perhaps) that uses only SHA-2 for issued certificates and  for CA certificates. Start issuing new certificates from the new hierarchy and re-issue SSL certificates from the new hierarchy.

You will have here two Root CA servers. Enterprise subscribers and relying parties will need to trust both roots during the migration. The benefits of this approach is that you can carefully and slowly migrate applications to a new SHA-2 based PKI in a controller manner. Finally, when all subscribers, relying parties and applications have migrated, the old SHA-1 based PKI can be decommissioned.

In this way, you could keep your old PKI hierarchy to support legacy applications and devices that is not SHA-2 ready, while supporting SHA-2 completely in the new hierarchy.

It is worth mentioning that you have to create a separate enterprise Certificate Policy (CP) for the adoption of SHA-2 and the discontinuation of SHA-1 hashing algorithm.

 sha-2 migration

Approach 2 : “Side by Side , Same Root CA”

In this approach, you will do side by side for intermediate CA servers, but you will keep the same Root CA.

Idea is simple. Root CA self signed certificate is not included in Microsoft’s deprecation plan for SHA-1, and Google Chrome will not give warning for that. Just keep the self signed root CA certificate without any modification.

In Parallel, create a new Intermediate Issuer CA (recommendation is to install the CA on Windows 2012 R2) that is capable of issuing SHA-2 certificates and that uses SHA-2 for its CA certificate itself.

Certificates issued from the new Intermediate Issuer CA, will use SHA-2, and will chain up to SHA-2 intermediate. It does not matter if it chained up to SHA-1 root CA.

sha2 3

First, you should upgrade the O.S version of your Root CA to Windows 2012 R2. This is highly recommended to enable the CA to perform CRL signing later using SHA-2 and to migrate to a storage provider that supports SHA-2. You can find the details of how to upgrade your Root CA server to Windows 2012 R2 in this blog post.

You are still safe if your Root CA is running Windows 2008 R2. Next you have to check the Cryptographic Provider for your Root CA, and make sure it is supporting SHA-2. Although the root CA certificate itself can be signed with SHA-1, the Root CA still needs to sign the CRL and the new Intermediate CA with SHA-2. You can know more about how to check the CA cryptographic provider SHA-2 support and how to upgrade to a provider that supports SHA-2 in this blog post. Now you have your Root CA supporting SHA-2.

Second, install a new Intermediate Issuer CA (Windows 2012 R2 is recommended), with SHA-2 CA certificate, and make sure the CA uses SHA-2 for issuing end-entity certificates.

Note: if your CA is using cyrptographic provider that supports SHA-2, you can configure your CA to issue SHA-2 certificates by running:

certutil -setreg ca\csp\CNGHashAlgorithm SHA256

Final Thoughts

If you use the Side by Side Same Root CA approach, and you configure the root CA to use SHA-2 as part of the plan, note that the CA also signs CRLs using the new algorithm. So in case your CA had issued certificates that are validated by applications that don’t understand SHA-2 and in case those apps check CRLs, then those applications would fail.

My recommendation is to use the side by side migration with different Root CA, so you will build a completely separated PKI infrastructure and gradually phase out the old PKI infrastructure.

See Also

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:

View your CA capabilities 

In the below figure, there is a standalone root CA server installed on Windows 2008 R2 using default installation options. If you open the Certification Authority console, and you check the CA properties, you can see in the general tab two interesting things:

  1. You can see the CA Certificate(s), and if you view the certificate, go to Details tab, and then see the (Signature hash algorithm) field, you can see what is the hash function used to sign the CA certificate itself, in this case SHA1.
  2. You can see the Cryptographic settings (Marked in yellow in the figure below), that shows two interesting information
    • Cryptographic Provider: Microsoft Software Key Storage Provider
    • Hash Algorithm: SHA1 – This is the hash function used to sign the CA CRL, and to sign certificate requests submitted to this CA.

In summary, the CA certificate  uses SHA-1, and whenever it signs a request or CRL, it will use SHA-1 also.

matrix101

Is my CA capable of issuing SHA-2 Certificates?

Check your CSP

First of all, check your CA Cryptographic Provider as shown in the above picture. The CA cryptographic provider determines whether your CA supports SHA-2 or not.

If your CA is using one of these Cryptographic providers, then you are using the new CNG KSP (Key Storage Providers) that definitely supports SHA-2.

If your CA is using one of these Cryptographic providers, then you are using legacy CryptoAPI provider, and you have to check if it supports SHA-2 or not.

Else, if you are using third party provider, you have to check with the supplier.

Configure your CA to use SHA-2

If for example you are using CNG KSP provider, then you can configure your CA to issue SHA-2 certificates by running this command

certutil -setreg ca\csp\CNGHashAlgorithm SHA256

You may need to stop and start your CA services. This means that the CA will use SHA-2 to sign the following

  • Any CRL it produces.
  • Any issued Certificate.
  • The CA certificate when renewed.

Renew your CA certificate to use SHA-2

What about the CA Certificate itself? Since the CA is now configured to use SHA-2 for all signing operations, if you renew your CA certificate, it will be signed with SHA-2. I will redirect you to this blog post for steps to renew your CA certificate and verify it is using SHA-2.

TechNet Resources

https://technet.microsoft.com/en-us/library/dn771627.aspx

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

The below procedures Applies To: Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2

Clarification 

It can happen that your CA is using legacy CryptoAPI provider even if your CA is running Windows 2012 R2. Let me give you an example. Suppose you have a Root CA running on Windows 2003. You decided to upgrade that CA to Windows 2008 or higher (let us assume you did the upgrade to Windows 2012 R2). After the upgrade [check this post on how to upgrade your root CA O.S version], you will notice that the Certification Authority Service on this Windows 2012 R2 is using legacy CryptoAPI provider [like Microsoft Strong Cryptographic Provider]. This is normal since the private key of the CA was created using that legacy provider when you first installed the CA services on Windows 2003. Now when you perform the migration to Windows 2012 R2 CA, and during the CA installation on Windows 2012 R2, the installation will prompt you : do you want to use new private keys or existing ones? , and you answered that you want to use existing ones, and you point to the backed up private keys of your Windows 2003 CA. When you do that, the installation wizard will see that those keys are created via legacy provider, so a legacy provider will be used by the Windows 2012 R2 CA.

How this is done?

 You take the private key that was issued by legacy CryptoAPI , you import it to Key Storage Provider (KSP) on Windows 2012 or Windows 2012 R2.

Now you export it again from the KSP to PFX file, and it is now KSP compatible if I may say that and you can import it back to your CA.

Upgrade your CA key to KSP 1211

So you have your Winodws 2008 or Windows 2008 R2 server, you check what provider your CA is using, and you discovered it is legacy crypto provider (Details below on how to check this).

Although Windows 2008 R2 and Windows 2008 support the new Key Storage Providers (a.k.a KSP), the private key of your CA is still using a legacy provider that does not support SHA-2. This is possible because of many reasons, one of them if you have your PKI set up since Windows 2003 and you upgraded the CA to new Windows version that supports KSP, but the key itself is never upgraded. The private key itself is still generated using the old provider.

The first thing i would do is to upgrade my CA to Windows 2012 or 2012 R2 (THIS IS NOT REQUIRED, but will make your life easier in the next steps).

Once this is done, you will export the private key from your CA, and copy it to Windows 2012 or 2012 R2 normal server with no roles installed on it.

Then while you are on the Windows 2012/R2 server, you will import that private key to the KSP certificate store if i may say that. This will makes your private key KSP compatible.

The next step is to export that private key as it is now KSP ready, and import it back to your CA and mission accomplished. This will makes your CA private key able to use SHA-2. The next step is to configure your CA to use SHA-2. I hope this makes sense.

I faced some difficulties doing this, and upgrading my CA to Windows 2012/R2 before anything, makes my life easier. The blog post will go through all the steps. They may seem complicated but these are simple steps and easy to roll back any time.

What happen after configuring your CA to use SHA-2?

After your CA is configured to use SHA-2 for signing, the following will happen:

  • Any newly issued certificate will be signed using SHA-2.
  • Any new CRL issued will be signed using SHA-2

It is hard to answer the question about the effect of doing that. It depends on your applications and if they support SHA-2 and depends on how deep your PKI hierarchy is. The best way to go is to create parallel and separate PKI infrastructure to support SHA-2 and start issuing certificates from there and leave your old PKI infrastructure in place to support your old certificates. Also i recommend you read the last part from this TechNet blog post.

Also in a TechNet Forum discussion, the advise is to move to a separate hierarchy.

Step 1: Windows O.S Version

First of all, Key Storage Providers only exit on Windows 2008 or later, so if your CA server is running previous version of Windows, then you cannot use KSP or CNG.

Another recommendation, if we are talking about the Root CA server, I personally prefer that you upgrade it to Windows 2012 R2. Steps to upgrade it are described here, and it will take you no time to perform the upgrade. Many steps mentioned here rely on Windows 2012/Windows 2012 R2.

I actually tried to configure a Root CA running Windows 2008 R2 to use KSP instead of CSP, but i have found difficulties. So I upgraded the root CA to Windows 2012 R2, and then I upgraded from CSP to KSP so easily.

Step 2: Which provider my CA is using?

Run the following command from CMD on your CA:

Certutil –store my <Your CA common name>

For example, if you run Certutil -store my  “Corporate Contoso CA” , the output will look like this:

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

As you can see, the Provider= Microsoft Strong Cryptographic Provider. Is this a legacy CryptoAPI provider or new KSP CNG provider?

Legacy Providers are listed here, while CNG providers are listed here. So this is a CryptoAPI provider.

Also, if you open the properties of the CA name from the Certificate Console, you will see what Cryptographic Provider being used along with the hashing algorithm used to sign requests by this CA.

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

Step 3: Backup your CA

It is normal that you need to backup your CA before doing any changes. To backup the CA, you need to backup three things:

  • CA Private Key
  • CA Database Files
  • CA Configurations stored in the registry

Another way to backup your CA is to take System State backup or Full Server Backup via Windows Backup.

I recall that I had wrote a blog post about how to do such backup here, or you can check this TechNet Article.

Step 4: Delete the CA Private Key

Save your CA private key to C:\. To do that, open the Certification Authority Snap-in, right click the CA name > Back up CA..> choose only “Private Key and CA Certificate” > Browse to C:\ to store the private key. Now you have the private key with .P12 extension. Later on, we will use this key and I will refer to it by C:\RootCA.P12

Stop the CA service, by right clicking the CA name, and click Stop, or by running :

Stop-service certsvc

Now, in order to delete the CA private key, we need two values:

  1. Cert Hash value
  2. Key Container value

Both these values can be obtained from the command we performed earlier (Certutil –store my <Your CA common name>)

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

To perform the actual deletion of the CA private key, procedures are different according to the O.S version:

Windows 2012 and Windows 2012 R2 

Open a Windows PowerShell window with the Run as administrator option, and then run:

Cd cert:\localmachine\my

Del –deletekey <Certificate HASH>

Migrate to KSP-4
You can see form the figure above that I have opened PowerShell, then I’ve used the PowerShell Certificate Drive by typing (CD cert:\localmachine\my), which will browse to the computer store of the CA, and then I deleted the certificate by providing the hash value.

Now if you open the Certificates MMC snap-in, and browse to the computer certificate store >Personal. You will see that the private key of the CA certificate is deleted.

Windows 2008 R2

Here you need to do two things:

  • Delete the certificate that you want to migrate itself from the Personal Computer Certificate Store. [Open Certificate Snap-In> Computer Store>Personal]
  • Run this command from CMD [Replace the Key Container value with the one you obtained earlier] :

Certutil –csp <Your current CSP> -delkey <Key Container Name>

So in our case, you should run this :

Certutil –csp "Microsoft Strong Cryptographic Provider" -delkey "Corporate Root CA"

Step 5: Import the private key to KSP

Windows 2012 and Windows 2012 R2

Run this command:

Certutil –csp <KSP name> -importpfx <Your CA cert/key PFX file> 

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

In our case,

Certutil -csp "Microsoft Software Key Storage Provider" -importpfx c:\RootCA.P12

The RootCA.P12 is the private key that we backed up in previous step before deleting the CA private key [Check Step 4 above]

Windows 2008 R2

Because this server version does not support converting the key, you must copy the backed up private key to a computer that does support this procedure – for example, a computer running Windows Server 2012 R2 or Windows Server 2012. However, you can also use a computer running Windows 8.1 or Windows 8. Then run the same command in the Windows 2012 section from this Step.

Step 6: Export the private key from KSP

Now that your Private key is imported to KSP, you have to export it so that it can be used by the CA. Run this command [while you are in Windows 2012 or Windows 2012 R2]:

Certutil -exportpfx my <CA Common Name> <PFX file path for export>


Migrate to KSP-6

Now that you have C:\NewCert.P12 , this is the private key of your CA in the new KSP format if i may say that.

Step 7: Configure the CA to use the new Key

If you have originally Windows 2008 R2 CA, then copy the P12 PFX file that you exported [While you are on Windows 2012/Windows 2012R2] from the previous step to your Windows 2008 R2 CA, before moving on.

Run this command from CMD on your CA:

Certutil –restorekey <PFX file path>


Migrate to KSP-7

So in our case, it would be Certutil -restorekey C:\RootCA.P12

Step 8: ADD CSP Registry Keys

In this step,  make sure you create a perfectly formatted registry key file , I prefer you go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Certsvc\Configuration\<CA Common Name>\CSP  Registry key, and export that key to a registry file called E.Reg for example.

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

Now, open E.reg using notepad, Keep the header information [Windows Registry Editor Version XXX] , and delete anything else and replace it with the below:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<Your CA Common Name>\CSP]
"ProviderType"=dword:00000000
"Provider"="Microsoft Software Key Storage Provider"
"CNGPublicKeyAlgorithm"="RSA"
"CNGHashAlgorithm"="SHA1"


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

Now before you carry on, just let us confirm that the CA was using SHA-1 as hashing algorithm before importing this registry key.

To confirm that, run:

Certutil –v –getreg ca\csp\HashAlgorithm

The output will look like this

HashAlgorithm REG_DWORD = 8004 (32772)
CALG_SHA1
Algorithm Class: 0x8000(4) ALG_CLASS_HASH
Algorithm Type: 0x0(0) ALG_TYPE_ANY
Algorithm Sub-id: 0x4(4) ALG_SID_SHA1

If you do not see SHA1 in your output, modify the CNGHashAlgorithm key value in the file to have the appropriate name.

Now save and run the E.Reg file.

Step 9: ADD CSP Encryption Registry Keys

Now rename the E.Reg file to E2.Reg file, keep the header information and delete anything else and replace it with:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<Your CA Common Name>\EncryptionCSP]
"ProviderType"=dword:00000000
"Provider"="Microsoft Software Key Storage Provider"
"CNGPublicKeyAlgorithm"="RSA"
"CNGEncryptionAlgorithm"="3DES"
"MachineKeyset"=dword:00000001
"SymmetricKeySize"=dword:000000a8

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

Before you save the file, confirm that you are using 3DES for the encryption algorithm by running the following command:

certutil -v -getreg ca\encryptioncsp\EncryptionAlgorithm

The output will look similar to the following:

EncryptionAlgorithm REG_DWORD = 6603 (26115)
CALG_3DES
Algorithm Class: 0x6000(3) ALG_CLASS_DATA_ENCRYPT
Algorithm Type: 0x600(3) ALG_TYPE_BLOCK
Algorithm Sub-id: 0x3(3) ALG_SID_3DES

If you do not see 3DES in your output, modify the CNGEncryptionAlgorithm key value in the file to have the appropriate name.

Finally, save and run E2.reg

Step 10: Optionally, Change the CA hash algorithm to SHA-2

Now that your CA is using CNG KSP, you can instruct the CA to use SHA-2 whenever it signs something, like CRLs and Certificate requests. To do that, just run:

certutil -setreg ca\csp\CNGHashAlgorithm SHA256

net stop certsvc

net start certsvc

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.

What is Cryptographic Provider?

Cryptographic Provider is the component that performs cryptography algorithms, generates keys, provides key storage and authenticates users. This provider can be implemented in hardware, software, or both. Those providers are created by Microsoft, or by third party that distributes them.

In Microsoft Windows, two implementations are available:

  1. Microsoft Cryptography API (CryptoAPI)
  2. Cryptography API: Next Generation (CNG)

Active Directory Certificate Services and Certificate Enrollment API rely on those two providers. Other applications can use CryptoAPI or CNG to use the services they offer, but they cannot alter the cryptographic algorithm implementation or alter the keys created by those providers. This layer of security and such abstraction is the key goal for creating those providers in the first place. So if your application needs to create encryption or signing keys, they can use those providers in Windows to generate the key pairs so that they can signed later by a trusted Certification Authority.

CryptoAPI

This is the older of the two providers in Windows. this provider implements both:

  • Key Storage
  • Cryptographic algorithm

So a specific CryptoAPI provider will list its key storage capabilities and its supported cryptographic algorithms. Saying that, if you give me a specific CryptoAPI provider, I can list you its cryptographic algorithms and its key storage capabilities. You can refer to this MSDN article to see the capabilities of each CryptoAPI provider.

Cryptography API: Next Generation (CNG)

First introduced in Windows Vista, and it is meant to replace the old CryptoAPI. I cannot mention here everything about CNG, but it is worth mentioning that the new provider has kernel mode API that implements threat safety throughout the stack, provides process isolation for its operations and extensive auditing features.

One of the great features of CNG is backward compatibility. CNG provides support for the current set of algorithms in CryptoAPI 1.0. Every algorithm that is currently supported in CryptoAPI 1.0 will continue to be supported in CNG.

CNG came to comply with Federal Information Processing Standards (FIPS) 140-2, and it supports new enhanced algorithms. These new algorithms are called Suite B algorithms. These algorithms are announced by the National Security Agency NSA for future U.S government use back in 2005.

Well, enough with the standards. What this means? It means that CNG now supports Elliptic curve cryptography (ECC) which is a new approach for public key cryptography. In addition, CNG supports AES (all key sizes), the SHA-2 family (SHA-256, SHA-384 and SHA-512) of hashing algorithms, ECDH, and elliptic curve DSA (ECDSA).

Unlike Cryptography API (CryptoAPI), CNG separates cryptographic providers from key storage providers (KSP). CNG includes:

  • Cryptographic Algorithm Provider that includes Symmetric, Asymmetric, Hashing and Key Exchange algorithms listed here.
  • CNG Key Storage Provider (KSP) that is used to create,delete,export,import, open and store keys. There are many CNG KSP providers and they are listed here.

In summary, if you are using any CNG KSP provider, then you can use any of the algorithms available in the CNG Cryptographic Algorithm Provider , including SHA-2.

SHA-2 Support

It is highly recommended to move to CNG KSP for your Certification Authority server in order to support SHA-2. Since CNG is available only on Windows Server 2008 or higher, you may need to upgrade your CA server.

Which provider my CA is using?

Run the following command from CMD on your CA:

Certutil –store my <Your CA common name>

For example, if you run Certutil -store my “Corporate Contoso CA” , the output will look like this:

66

From the picture you can see  Provider = Microsoft Storage Key Storage Provider , which indicates the name of the KSP used , thus CNG provider is used.

How do I know that? If you go to this MSDN page, it will list the CNG Key Storage Providers in Windows:

33333

What is next?

In your journey to phase out SHA-1 and start using SHA-2, you need to identify if you are using the legacy CryptoAPI providers or the new CNG Key Storage Providers. Accordingly, you may need to move to CNG KSP, and may be upgrade your CA Windows version accordingly to at least Windows 2008. Future posts will illustrate the whole process.

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.

SHA-1?

Hash algorithm is a one-way function (a cryptography construct) that is used with public key infrastructure to provide encryption and digital signature services, beside integrity checking and authenticity.

So this is the scientific definition. In simple words, the hash function will take an input of any length, and will produce a unique fixed length output for each different input. The values returned by a hash function are called hash values, hash codes, hash sums.

Hash function efficiency is defined by two factors (properties):

  • They are one-way : It is easy to compute the hash value, but it’s impossible (not possible in reasonable time) to take the hash value and produce the original message.
  • Collision Free :  it is impossible (not possible in reasonable time) to find two messages that hash to the same hash value.

This also implies another rule. The same message should always produce the same hash value, and two different messages must always produce different values.

In 1990, Rohn Rivest came up with MD4 hash function, followed by MD5 in 1992. A year later, the National Security Agency published the SHA (Secure Hash Algorithm). In 1995, a weakness was fixed in SHA by doing some changes, and the new updated hash function was called SHA-1.

Hash Function Evolution

What is wrong with SHA-1 and why now ?

SHA-1 is most commonly used hash functions for years, and it is becoming the standard algorithm for hash functions. I can remember way back when white papers specified that it is recommended to use SHA-1 for absolute security. No one nowadays is using MD5 or MD4 anymore as they are weak hash functions. MD stands for Message Digest.

So why SHA-1 is becoming at risk? As I have explained earlier in this blog post, the hash function strength is measured by how it implements the two properties (One-Way and Collision Free). It all started in 2005 , when three Chinese cryptographers showed that SHA-1 is not collision-free. That is, they developed an algorithm for finding collisions faster than brute force. If you like to get more information about how SHA-1 get attacked, please check this paper, written by my mentor in Cryptography “Bruce Schneier“. In simple words, they could produce two different inputs that SHA-1 computes the same hash value for.

Attacks always get better; they never get worse.” , an old saying inside the NSA.

 “It’s time to walk, but not run, to the fire exits“, John Callas, PGP’s CTO said at the time.

Moreover, i quote from SC Magazine: “Benjamin Jun, vice president and CTO of San Francisco-based Cryptography Research, a Divison of Rambus, told SCMagazine.com that 2012 revelations about Flame, sophisticated cyber espionage malware that targeted Iran’s oil ministry, also intensified misgivings about the integrity of SHA-1 in the face of evolving threats

SHA-1 is widely used in the internet nowadays. In fact, 98% of the SSL certificates in the web are using SHA-1 (85% percent according to Google). There is no clear and announced attack on SHA-1 right now as per the online communities and bloggers, but it is just a matter of time before they appear.  Nevertheless, many parties start to communicate their deprecation plan for SHA-1 right now, including Google and Microsoft .

sha-1 percentage

If not SHA-1 then what?

SHA-1 produces 160 bit hash value, so to make collision attacks more difficult, we need to increase the bits of the output value. A new hash function called SHA-2 solves this issue by producing hash values that are 224, 256, 384 or 512 bits: SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256.

So any output more than 160 bit is called SHA-2. SHA-2 is a collective term for the hash functions SHA-224, SHA-256, SHA-384, and SHA-512.

The SHA number specifies the number of bits in the hash, so the larger the hash number, the more secure the certificate, but possibly less compatible.

SHA-3 standard was recently finalized, but it will take a long time to be widely deployed (not commercial yet).

PCI Compliance scanners currently require their clients to use SHA-2 compatible SSL certificate.

What happened since then?

In 2011, the CA/Browser Forum, an industry group of leading web browsers and certificate authorities working together to establish security requirements for SSL certificates (published here), and they recommend CAs transition away from SHA-1 as soon as possible.

In 2013, Microsoft issued a Security Advisory to discontinue use of SHA-1 , and they described their Depreciation Policy here.  Starting 2016, things will change from Microsoft regarding supporting SHA-1.

Google also start to move away from SHA-1 since November 2014 with Chrome. People will start getting certificate warnings when using chrome to browse SSL sites using SHA-1. Actually, depending on the Chrome version, three different signs will start to appear when browsing SHA-1 SSL sites. An example of such chrome warning signs is shown in the below figure. Google is trying to spread awareness to everyone that SHA-1 is not secure anymore and people should start phasing out from it soonest.

Capture

Microsoft Deprecation Plan

In November 2013, Microsoft announced their deprecation plan for SHA-1 SSL and code signing certificates, and they announced that they will give a new consideration to the SHA deprecation deadlines in July 2015. In summary, Windows will not accept SHA-1 SSL certificates by January 2017. This date seems to be far away, but you should start working on the transition from now.

Microsoft SHA-1 Deprecation Plan

I will try to break down Microsoft deprecation plan, and i will quote from their blog post:

For SSL Certificates :

“For SSL certificates, Windows will stop accepting SHA1 end-entity certificates by 1 January 2017. This means any time valid SHA1 SSL certificates must be replaced with a SHA2 equivalent by 1 January 2017”

So your client machine when it connects to a web site secured with SSL certificate that uses SHA-1, this is when your client machine running Windows will start to behave badly and reject that certificate.

Code Signing Certificates:

I have to take a minute and describe what is a time stamp and what it has to do with code signing. Time-stamping is used to specify the time when the digital signature is made. This is needed to properly validate the signature.

You can choose not to include the time-stamp when use code signing. However, if the signature time-stamp is present, the application which validates the signature, will check whether the certificates involved into signature validation were valid at the moment of signing.

If there is no time-stamp for the signature, certificate validity is checked for the moment of signature validation.

Time-stamp is so important for the following reason. Suppose you have a code signing certificate that is valide from 2008 till 2010, and you sign a document in 2009. Suppose then that an application needs to verify the signing today (we are in 2015). If there is no time-stamping, then the application will fail to validate the signature, since the code signing certificate used to sign the document in 2009 has already expired.

Since you can use code signing with or without time-stamp, Microsoft deprecation plan will affect your choice here.

“For code signing certificates, Windows will stop accepting SHA1 code signing certificates without time stamps after 1 January 2016” , in other words, Windows will stop accepting code signed by a SHA1 certificate where the signature does not include a time-stamp. However, “SHA1 code signing certificates that are time stamped before 1 January 2016 will be accepted until such time when Microsoft decides SHA1 is vulnerable to pre-image attack.”

So, first of all, start using time-stamp for all your code signing certificates. Second, for code signing certificate stamped before 1st January 2016, no worry.

Infrastructure (Clients)

So as people are shifting to SHA-2, what versions of Windows support this new has function?

Windows XP SP3 already supports SHA2 SSL certificates, while Windows Server 2003 SP2 or later should apply KB968730 and KB938397. More details can be found here.

Windows XP SP3 and Windows Server 2003 with the hotfixes, have limited support for SHA-2. Support for SHA-2 on these platforms is limited to SSL/TLS capabilities.

Windows 2008 and later, and Windows Vista and later are fine as they already support SHA-2.

Microsoft had published a blog post about (SHA-2 and Windows) showing the compatibility with SHA-2.

Infrastructure (Web Servers)

Web sites administrators should replace their  SHA-1 SSL certificates expiring after 1st January 2017.

Infrastructure (S/MIME)

“Windows has not set any dates for blocking other types of certificates (e.g., S/MIME)”

Infrastructure (CRL and OCSP)

“CRLs and OCSP responses themselves have to be signed with SHA-2”

Application Support

“Some applications do not support SHA2.  Before using SHA2 signed certificates with a specific application, it is recommended that all PKI dependent components of that application be tested.  For example, if SHA2 will be used for S/MIME; then every email client, email server, relay, spam filter, security device, etc belonging to both one’s own organization and those of external organizations (which exchange S/MIME messages with one’s organization) would need to be validated that they can process S/MIME with SHA2. For this reason, both old and new PKI hierarchy may need to operate while applications are upgraded/migrated”

Infrastructure (CA)

This part is about your corporate enterprise PKI infrastructure. This part depends on the number of tiers and the version of CA Operating system (weather it is Windows 2008 R2 or later).

I will not be talking about how to make your PKI support SHA-2, or how to plan for migration to SHA-2 ready PKI infrastructure. I will talk about this in future post. Now for CA servers, we have Root CA servers and Intermediate and Issuer CA server.

Root CA Servers:

Side Note: If your CA is member of the Windows Root Certificate Program who issue publicly trusted certificate, then it affects you.

Have you read the side note above? Well, now let us focus on Enterprise PKI deployments. Focus with me for a minute. Microsoft deprecation policy targets intermediate and end-entity certificates. The new deprecation policy does not affect Root CA Certificates of the CA that is acting as only Root CA and not issuer (and Chrome won’t warn about them).

I quote from Microsoft Deprecation plan blog post:

“The SHA1 deprecation policy does not impact SHA1 privately deployed root certificates, because Windows relies on other means to validate root certificates besides the signature. But all root CAs are expected to switch to use SHA2 to sign any subordinate CA certificates, CRLs, etc.”
” To meet the policy, the root CA will have to switch to use SHA2 by 1/1/2016 when signing new certificates and CRLs. However, the hash algorithm used on the root certificate is excluded from this policy”

What this means? are you confused? If you have for example one Root CA, and then a child issuer that issues end-entity certificates, then the following applies:

  • The Self-Signed Certificate of the Root CA can keep using SHA-1, as this certificate is not included in Microsoft deprecation plan for SHA-1.
  • When the Root CA needs to issue a CRL, it has to sign the CRL with its Self-Signed Root Certificate. When it performs this operation (signing CRL), SHA-2 should be used.
  • When the Root CA needs to sign the certificate for child CA servers, the signing operation should be performed using SHA-2

So the Self-Signed certificate for the Root CA itself, can still use SHA-1 and there is absolutely no harm for that, because clients will use other means to validate that certificate. However, any operation performed by the Root CA that includes signing (CRL signing, issuing child CA certificates), should be performed using SHA-2.

So, you can keep your Root Self-Singed certificate with SHA-1, but you have to make sure that your Root CA is capable of performing SHA-2 signing operations from now on.

Intermediate CA Servers:

The Intermediate CA certificate that is signed by the Root CA, should be signed with SHA-2. Any operation performed by the CA like CRL signing and issuing SSL or code signing certificates, should be done with SHA-2 also and is affected by Microsoft SHA-1 deprecation plan.

sha-1 Deprecation

Important Note

Any SHA-2 certificate chained to an SHA-1 intermediate certificate should be replaced with another one chained to an SHA-2 intermediate certificate.

Infrastructure (self-signed certificates)

For the same reason that root CA certificates are not affected by the SHA-1 deprecation plan, self-signed certificates are also not affected. For example, Microsoft Exchange servers generates self-signed SHA-1 certificates during the installation, those will still work after the deadline.

Is my web site using SHA-1 ?

There are many ways to check if your SSL web site is using SHA-1. Just open the SSL certificate, go to Signature and Hash Algorithm extension, and check if SHA-1 is listed there.

SHA1

To check what hashing algoirthm your Certification Authority is using to sign CRL and issued certificate, open MMC for your Certificate Authority, righ click and select properties; in the general tab it will state which hash algorithm is used.

sha-1

There are many online tools that you can help you discovering SHA-1 usage in your internet facing SSL sites:

What should I do as a developer?

Well, if you are responsible of signing application packages, then make sure that you are using SHA-2 hash function when signing the app. Most signing tools defaults to SHA-1 unless you explicitly specify SHA-2 as your choice.

Take the SignTool to sign your application, then make sure you specify the (/fd SHA256) switch to specify SHA-2 as your choice of has function. Also you must include a time-stamp when signing apps, by specifying the (/tr timestampServerUrl) switch.

Also, you should use the SHA256 Class to compute hash values when needed. In summary, you should question the type of hash function being used whenever you are doing digital signature, code signing, or computing hash values.

What should I do as a IT Pro?

Here’s what i recommend:

  • Read carefully Microsoft and Google deprecation plans.
  • Ensure that any new certificate and their chains (except privately deployed root ca certificate) use SHA-2. So this point is about two things:
    • New issued end-entity certificates should use SHA-2
    • New issued end-entity certificates should have intermediate CA certificates that use SHA-2 only.
  • Inventory existing certificate and identify the SHA function used and the expiry date for each.
  • Replace SHA-1 SSL certificates that expire after 2016 then work your way back to replace the remaining certificates.
  • For code signing certificates, make sure they are time-stamped, and start replacing them before 2016.

SHA-2 Green

SHA-1 Red1

SHA-2 RED3

SHA-2 and CNG

They are not related. This is the scientific professional answer.

Well, I have to argue here that they are relatively related. If you have a little bit of knowledge about Cryptographic providers (Check my Post) , then you should know that you can use legacy provider (CryptoAPI) that implements SHA-2. You can use third party provider that support SHA-2.

Nevertheless, the easiest and recommended way to implement SHA-2 is to move to CNG KSP (Key Storage Provider) for your CA, and configure the CA to issue SHA-2.

See Also

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..

rootca1

  • 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.

rootca2

rootca3

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

ROOTCA4

  • 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

certutil

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.

lol1

  • Click Active Directory Certificate Services.

lol2

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

lol3

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

lol5

  • Select Certification Authority for services to configure.

lol6

lol7

lol8

lol9

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

lol10

  • 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.

LOL11

LOL12

  • 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.. .

Rootca101

  • 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.

Rootca102

  • 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.

rootca103

  • 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.

The story of Multi-Factor Authentication and the Azure MFA [Updated Feb 2017]

This blog post is moved to my new blog platform:

 

https://blog.ahasayen.com/azure-multi-factor-authentication-azure-mfa/

https://blog.ahasayen.com/multi-factor-authentication-as-a-service-model/

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 :

http://www.youtube.com/watch?v=AE5do-PYpJw

 

 

pki2

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.

l

“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:

CRL2

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)