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.

A time ago I quoted a Windows PKI team announce about SHA1 Deprecation Policy by Microsoft.

In short, Microsoft will discontinue SHA1 signatures in SSL and code signing certificates by January 1 2017. This article raised a lot of questions in TechNet forums and these questions shows policy misunderstanding by users. In this article I want to focus on key moments of the policy, common myths and the second part will show the general guidance for moving toward SHA2.

Today I released SSL Certificate Verifier tool to CodePlex. There are plans to enhance the tool (as per customer requests), so I decided to publish it online, rather than maintaining it here.

>> SSL Certificate Verifier <<