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.

Windows PKI team always knows how to make our live harder :). Yesterday Shay Levy pointed me to one interesting thread: http://www.powergui.org/thread.jspa?messageID=47514

Basic intro: this attribute is used by Credential Roaming Service. By default if user uses roaming profile, credentials (and personal certificates) don’t roam! This means that user can use the same profile on other computers, but will not able to use certificates (i.e. decrypt files, mails, sign documents and so on). Though if certificate autoenrollment is enabled, user will enroll new certificates. But they will remain on that computer only. The one possible way to work around this issue is to use smart cards. But this is quite expensive solution. With Credential Roaming Service all certificates will roam with user. However this is not pretty secure solution, because domain administrators will have an access to user private keys. However at certain point domain users must trust administrators, so this solution is enough for many scenarios with roaming profiles.