Hello, PowerShell Crypto Guy is here again. A time ago I went through one article: http://www.solution-soft.com/whitepapers/Hyper-V/TimeMachine_Hyper-V_guide.htm which is pretty interesting. However it complains that a related TechNet article Configuring Certificates for Virtual Machine Connection won't work due of the following limitations:

• PowerShell or DOS cannot seem to create a Qword value.
• The VMMS service requires two critical certificates Extension Fields These are:
  Field= “Key Usage” Value = “Key Encipherment, Data Encipherment (30)”
  Field= “1.3.6.1.4.1.311.62.1.1.1 Value = “02 01 04"
  These fields are present in the local host certificates created locally by VMMS. As of the writing of this paper & working with Microsoft support we have been unable to create a certificate with these values using any other means.

Fortunately both statements are not correct:

Table of contents:

• Understanding certificate chains
• Exploring SSL certificates in action
• Building the Certificate Chain
  • Local certificate store method
  • PKCS#7 method
  • Authority Information Access method
  • Crypt32.dll and Microsoft Update
• Binding Certificates
  • Binding Certificates: Exact Match
  • Binding Certificates: Key match
  • Binding Certificates: Name match
• Signature validation
• And more...
• Conclusion
• Related links

Often the certificate path/revocation checking issues that certification authority (CA) admins encounter are caused by invalid CDP (CRL Distribution Point) or AIA (Authority Information Access) configuration. This article covers the Certificate Chaining Engine (CCE) and how it can be used for troubleshooting purposes.

Some time ago one guy asked me for a script that will do the following:

1. Extracts all archived keys from CA database;
2. decrypts these keys (by using key recovery agent certificate)
3. saves decrypted keys in a PFX (PKCS#12) format;
4. creates simple log files: one with serial numbers that were decrypted successfully and another were decryption process was unsuccessful.

This scenario is common when an organization decided to move to a new PKI with new CA database. However it is highly recommended to move archived private keys from old to a new CA server. This is because even if new PKI is used, there might be a lot of encrypted stuff (encrypted files or outlook mails). And if user looses his/her encryption private keys he/she still should have an access to encrypted content. As the result you should move archived keys to a new CA for key recovery purposes only.

Hello, me again here!

Today I have finished my new PowerShell PKI module. Even if my first release was one month ago, it was reasonable for me to evaluate it and finalize certain things. This is because several commands was published in a test mode.

During my own usage I've noticed that several commands don't provide consistency and required level of usability. For example, there is a command named Get-CertificateTemplate. This command returns registered in AD certificate templates. In a previous release there was only one way to filter them by display name. My thought was that administrators remember display names rather common names. Also there are similar Add/Remove-CATemplate commands. They are used to add/remove certificate template from CA issued template list. In order to add a new template the only option was to specify template common name. This is because default ICertAdmin2 interface uses common names for that. Now Templates property contains common objects and Add/Remove-CATemplate commands are improved to handle either display name, common name or an object returned by Get-CertificateTemplate. Here is an example:

Update 28.05.2012: it appears that the same issue occurs with Remote Desktop Protocol too. Here is a fix for RDP: An RDP connection that uses SSL authentication and CredSSP protocol fails in Windows 7, in Windows Server 2008 R2, in Windows Vista and in Windows Server 2008

This is very interesting story of one customer (not my) and Thawte. It is common that you purchase SSL certificate from some of trusted commercial certification authority (CA) for public access. This reduces administrative effort on custom root CA (for example, your company own internal CA) installation on unmanaged computers (your company user's home computers). Or in partner organization. Also your company may not have own CA services and the only way to provide secure access to your web sites is to use certificates from commercial CAs.