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:

Update 15.03.2011: previous code sometime crashed due of StringBuilder buffer overflow. The code is updated to correctly size buffer.

I just wrote a little script that retrieves all CSPs (cryptographic service provider) that are registered on the system. It could be very useful when you are dealing with offline certificate requests via certreq.exe utility and other purposes. This script demonstrates some p/invoke techniques in Windows PowerShell. Code routine I got from corresponding CryptoAPI function MSDN pages: CryptEnumProviders and CryptEnumProviderTypes. Even though examples are in C++ it is not difficult to translate it to your .NET language (C#, PowerShell, etc). Here is a code:

Time by time I read questions about CDP and AIA extensions on Root CA and in Root CA certificate.

• CDP — CRL Distribution Point is an extension that contains links to the CRL of the issuer of the certificate which is being verified.
• AIA — Authority Information Access is an extension that contains links to the certificate of the issuer of the certificate which is being verified.

Check these articles for better understanding of certificate chaining engine:

• Certificate Chaining Engine — how it works
• Designing CRL Distribution Points and Authority Information Access locations

Let's see how these are used by certificate chaining engine (CCE). At first application must build a certificate chain. When CCE is processing a certificate it uses AIA extension to retrieve certificate issuer's certificate. Once it is retrieved, CCE set issuer's certificate as current and checks for *current* certificate issuer's certificate. This is normal and expected behavior for non-self-signed certificates. Once a certificate is presented in the self-signed form, there is no issuer. Certificate is issued to itself. As the result if AIA extension exist in the self-signed certificate it will point to itself and will cause loops. To address this issue, it is recommended to *NOT INCLUDE* AIA extension in the self-signed certificate (also referred to Root certificate).

Sometimes users accidentally delete their certificates from personal store. After that users are not able to perform certificate-based tasks, i.e. decrypt files or mail, sign data and authenticate. Some organizations implement Key Archival for certificate and private key recovery. But some organizations do not. Even if key archival is enabled, it is not always required. In our case, user just deleted certificate from personal store. Let’s look to a private key storage background.