Recently, a friend of mine asked a question about key exchange in SSL without encrypting the key. His question came after examining a Key Usage certificate extension setting in the certificate template. There are two options: Allow key exchange only with key encryption and Allow key exchange without key encryption. How it can be possible that the key is not encrypted??? Here is an image of the respective setting:

Recently I was tasked to configure SSL/TLS protocols and cipher suites for internal web servers via Group Policy. At first, we collected a list of web server and web client applications to determine the weakest possible SSL/TLS protocols. Once the list was complete, we deployed sample policy in test OU and finally applied them to the rest domain.

Now I was tasked to scan web servers to determine if they match new security policy. In order to minimize my effort in testing, I wrote a simple PowerShell script that accepts a list of web URLs and tests each host with a list of SSL protocols: SSLv2, SSLv3, TLS 1.0, TLS 1.1 and TLS 1.2. Here is a sample code:

Continuing my 2-post series about Certificate Policies certificate extension. In the first part we covered theoretical questions and common design scenarios. In this post I will show how you can add Certificate Policies extension in CA and end-entity certificates.

Certificate Policies extension in CA certificates

When installing Windows CA, either, via Server Manager UI, or PowerShell, there is no way to provide additional information to include in the CA certificate. To include this information, Windows supports a special CA configuration file named “CAPolicy.inf” which must be saved in the %systemroot% directory (usually, it is C:\Windows). CA installation code reads this file in two cases:

1. During new CA installation;
2. During existing CA certificate renewal.

CAPolicy.inf syntax is another story, so we will focus on our subject only. Main section in the INF file is [PolicyStatementExtension] and has the following syntax:

Part2: Certificate Policies extension – all you should know (part 2)

In this post I’ll discuss about Certificate Policies certificate extension. This article assumes that you have understanding about certificate chaining engine basics.

Intro

Not all certificates are the same or issued in the same way. Some certificates are issued in an automated way, some with minimal validation, but some with strong validation and even by requiring a face-to-face meeting. What is the difference here? In these case we usually say that these certificates were issued under different issuance policies.

A company may have certificate templates that are configured to require user key archival (for backup purposes) in the CA database. Another template requires that client certificates must be stored on smart cards. Thousands cases and each case may have a distinct issuance policy. Users should be aware about them. How? As per best practices, a company should have a written policy about their PKI usage. Your policy may be implemented as a single web page (or web site) or downloadable document and has common name: Certificate Practice Statement (CPS). IETF has developed a framework that helps PKI administrators to effectively create a CPS document. CPS Framework is defined in RFC3647. If certificate was issued under specific policy, this information shall be included in the certificate: Certificate Policies extension.

Hello again, PowerShell CryptoGuy is back!

I was impressed how many feedback I received on my proof of concept version of Enterprise PKI health verifier: Enterprise PKI (pkiview.msc) PowerShell Edition (PoC). I carefully reviewed each feedback and implemented almost all requests.