Update 09.03.2011: removed SAN attribute flag as it is not necessary.

Many of windows administrators requires to setup SSL on their web servers and mostly they wish to use certificates with the Subject Alternative Name extension that allows to map a single certificate to a multiple web sites. For example, you want to use a single certificate for https://www.domaon.com and https://owa.domain.com. In that case you need to have multiple subjects in the certificate. However X.509 certificates don't support multiple subject fields. To resolve this issue, Subject Alternate Name extension is used. You can add multiple (even wildcard) subjects to a certificate.

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: