Recently I decided to perform little changes on my OCSP Responder. I'm using offline CA (root) and have configured to include OCSP URL to all issued certificates. But some time I haven't OCSP configuration for  my root CA. And today I have completed all changes and now Root CA issues OCSP signing certs for appropriate OCSP configuration.

You can find required info about the subject on TechNet: Online Responder Installation, Configuration, and Troubleshooting Guide or in AskDS blog: Implementing an OCSP responder: Part IV - Configuring OCSP for use with Standalone CAs. However both links contains incorrect settings, therefore I'll post correct steps.

Update 18.08.2010: added workaround at the bottom of the post.

Many Windows customers have received an error message in Application log when they try to update third-party root list. Prior to issue description I want to explain about the subject. Third-party root list is the list of third-party (non-Microsoft) root certification authorities (hereinafter CA) that participate in Microsoft Root Certificate Program. All these CAs are trusted by Windows and applications. About Program participants you can read the following article: Windows root certificate program members. You can add your own CAs to a trusted root list, but you cannot remove predefined CAs from computer. Therefore if new program member appears or retires, Microsoft issues update that will add or remove corresponding certificate to (from) Trusted Root CAs certificate container. Internally update contains a Certificate Trust List (CTL). Let's see the error message:

Update 23.08.2010: added workaround to resolve the issue.

Today one customer claimed that AppLocker rules are not worked for his environment. He just created simple path rule and it didn't work. I have investigated this issue and I'm able to confirm that AppLocker don't apply path rules to a folder that contains non-english letters. Here is an example how to reproduce this issue. Assuming you have default Windows 7 Ultimate/Enterprise installation with C:\Windows as a system root folder.

If you're looking for Enrollment Web Pages (hereinafter EWP) installation (or removal) without GUI — you're in correct place. At first I need to answer, why it necessary to script EWP installation. This may be very useful for CA administrator assistants, for example. In general, CA administrator will have to write a long step-by-step guide to install certain role. But using scripts, CA administrator may tell: "Take the script, run it with the XYZ parameters and get PROFIT" or something like this. It is common to script all (as possible) routine operations in the case of disaster recovery and so on, because it takes less time and easy to document. Feel free to think if CA role can be installed from the script — this is possible. In next post I'll show PowerShell code that will do that. But now we'll talk about web enrollment.

As a start stage we need to find appropriate API and here it is: ICertSrvSetup. This CryptoAPI COM interface is the base interface for CA and/or EWP role installation. The following code will instantiate COM object:

Hello again! Continuing Certificate Enrollment Service (CES) and Certificate Enrollment Policy (CEP) service subject I would like to post another PowerShell script that will install and remove CEP service. Like CES, CEP CryptoAPI COM interface is not documented yet. However you can manually find this interface in your registry:

these keys are located in HKEY_CLASSES_ROOT hive. Actually there are a lot of interesting things that are not documented on MSDN. I don't know why, so don't ask me why, I'm not Microsoft guy. The code is quite similar as posted in the previous post, so I don't think that I need to additionally explain something else. Yes, I know, I'm bad PowerShell MVP, because my posts are quite complex and not all PowerShell users can understand it. Instead I provide (ate least I try) finished solutions for end-users. They just run my scripts and get the fun (or PROFIT!!!). Let's go: