Web Application Proxy P1

We all know that Microsoft is not investing in TMG and UAG the way it did before and those products are going out of support soon. On the other hand, information worker are now using Laptops and devices all the time and from everywhere.

The way i see it is that end users now have their BYOD devices, have a cool looking apps, and they want to use those cool apps to connect to corporate data without the need to RDP into the corporate network for example and use VDI or RDS Session Host experience.

On the other hand, while VPN and DirectAccess are great technologies for remote access, for IT administrators, those type of technologies will let the user IN or OUT. In other words, VPN solutions will either let you IN or OUT and it is hard to control where the user can go once he is IN.

Microsoft came with a new way for remote access called “Conditional Access”, and added flexible authentication methods to the solution. The solution is called “Web Application Proxy”.

Web Application Proxy (a.k.a WAP) is a new Windows Server 2012 R2 role service under RRAS server role, integrated into Windows Server Manager and RRAS admin experience.

Microsoft now announced another new category, which is conditional access reverse proxy called “Web Application Proxy”. This is not a new technology for Microsoft as they have TMG and UAG before. Whats new about this Web Application Proxy, is its unique interaction with Active Directory Federation Services and devices. Web Application Proxy is part of Windows Server and not a separate installation like TMG or UAG.

From Information worker perspective:

  • Access corporate apps from anywhere, on any device, Windows and non-Windows
  • SSO and native device/app experience

From IT Pro:

  • Selectively publish apps
  • control access per app, user, device, location
  • Better protection with pre-authentication (optional)
  • No change required in existing apps
  • No change required on devices (client-less)

WAP: Fundamental Services

  1. Reverse Proxy Services:
    • Network Isolation
    • Basic DOS : Throttling, queuing, session establishing before routing to backend
    • URL Translation
    • Selective Publishing: Per internal application endpoint
    • ADS Proxy Services
    • Web Protocols Only: HTTP,HTTPS
  2. Pre-authentication services:
    • Rich Policy : user + device identity, application identity, network location
    • MFA Options (multi factor authentication)
    • SSO

Network Topology

Web Application Proxy is usually located in your corporate DMZ with one network card or two network cars.

You can choose not to join it to your domain if you like, but if you want to use Kerberos constrained delegation method, then you have to join it to the domain.

Web Application Proxy can authentication requests before forwarding them to the back end applications (this is called Pre-Authentication), or it can just pass the traffic to the back end application without authentication (this is called Pass Through)

Web Application Proxy cannot live without ADFS becuase ADFS provides the following for Web Application Proxy:

  • Configuration Storage: WAP is a stateless firewall, and its configuration files are stored in the ADFS
  • Pre-Authentication: WAP uses ADFS for authentication.

Web Application Proxy 1

Web Application Proxy Part2

Relying Party

I want to start by defining (Relying Party). ADFS has many Relying Parties, and those are the systems or devices that trust ADFS for authentication. In our context, ADFS has three relying parties:

  1. Web Application Proxy itself is a relying party to ADFS, because it trusts ADFS for authentication.
  2. The LOB applications are relaying parties to ADFS, because they trust it for authentication.

Note: ADFS is called STS which stands for ” Security Token Service”

Suppose we have line of business application (LOB), and we have our ADFS that contains application policies, and we have the Web Application Proxy. The line of business application is accessible internally using http://lob. The ADFS URL is https://sts.fabrikam.com that is published externally via the WAP (Web Application Proxy)


What we will do is to publish the LOB app on the WAP using the fully qualified domain name and with SSL, and the WAP will send 302 Redirect response to https://sts.fabrikam.com to do the pre-authentication. the ADFS will authenticate the user and will send him a token


RMS Client not working after Office 2013 June Patch KB3054774

If you applied June Patches for Office 2013, you may encounter a problem that happened to me. I am running Windows 8.1, Office 2013 with June 2015 Office patches.

Suddenly, RMS (Right Management Services) stop working on my machine. If i open an outlook email and I tried to send an RMS protected email, i am not able to do so.

Moreover, i receive the below error when i tried to use RMS from Office 2013:

“Sorry, something went wrong opening Information Rights Management protected content. A certificate is missing or has an empty value for an important field, such as a subject or issue manner”.


It seems that the reason is that I have this Office 2013 June patch installed on my machine (KB3054774). Uninstalling this patch should immediately solve this problem. I have an open case with Microsoft to try to investigate this error. They recreate the environment that I have and they had the same error. Still waiting them to get back to me.

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.