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.

Recently I started another work on PKI task automation with PowerShell – PKI Health Tool (aka Enterprise PKI or pkiview.msc). As a start point I took pkiview.msc MMC snap-in functionality which consist of:

1. Enumerate all Enterprise CAs in the forest. Filter inaccessible CAs;
2. Retrieve the most recent CA Exchange certificate for each CA;
   1. Execute chain for each certificate to select trusted anchors and to go through the chain;
3. retrieve all Issuer URLs from AIA;
   1. Validate each url (must be either http or ldap) and attempt to download the contents;
   2. If contents is downloaded, verify whether it is a certificate;
      1. Verify if the downloaded certificate is an issuer of CA Exchange certificate;
      2. Validate other cert properties;
4. Extract URLs from CDP extension;
   1. Validate each url (must be either http or ldap) and attempt to download the contents;
   2. If contents is downloaded, verify whether it is a CRL;
      1. Validate basic CRL properties, like validity (not yet valid, expired, about to expire);
      2. Validate whether the CRL has valid signature (against CA certificate);
   3. Do the same for DeltaCRLs;
5. Extract all OCSP URLs from AIA extension;
   1. Validate OCSP response by sending OCSP request and processing response;
6. Compose status report (managed, I maintain report object and you can access report properties);
7. Repeat steps 3-6 for each subsequent certificate in the chain up to root certificate;
8. Compose summary report.