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.

Time by time this happens. Even highly trusted commercial certification authorities issue fraudulent certificates to malicious users. In 31 January 2001 (more than 10 years ago) VeriSign issued two fraudulent certificates to Microsoft on behalf of unknown men. This is very strange for a company who sell digital certificates starting with $100+ and cannot perform requestor identification as documented in their CPSs.

Ok this was ten years ago. But about 2 weeks ago Comodo CAs was compromised ( http://blogs.comodo.com/it-security/data-security/the-recent-ra-compromise/ ). If VeriSign issued only two fraudulent certificates, Comodo — 9!!!!1111oneone. And to what names: login.live.com, login.yahoo.com, www.google.com, mail.google.com, login.skype.com and so on. All of them are SSL certificates. And not usual SSL certificates, but Extended Validation (EV) certificates!

Hello again! Sorry for issues accessing my blog, there was some problems with hosting provider. Now all is fixed (I believe it).

Probably you don't know (but is known for my Russian's blog readers) but I spent a lot of time to automate certain common PKI tasks with Windows PowerShell, the best automation tool. I've started this project about 2 years ago. Since that time I've deeply dived to PKI with some good experience in PowerShell (I already was PS MVP). And this blog contains several PKI automation examples that are included in my new project (and will be included in future). The most reasonable thing why I had started this project was certutil. Even if this is very powerful tool, but not optimized for scripting and automation scenarios. This is because it is necessary to parse complex command's output. Also certutil lacks in command help. Command switches are not user-friendly and mostly don't provide extended help information and usage examples. The biggest PowerShell advantage is pipeline. This allows you to collect certain data, modify it as necessary and pass to another command with a single line. For example, you have implemented OCSP responder for your Enterprise CAs and need to configure them to include OCSP URL to issued certificates AIA extension. There are 2 choices: