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.

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:

This article will explain and demonstrate the techniques that will add custom extensions to certificate requests.

A little abstract. As you know, when Hewlett-Packard iLO generate certificate request for SSL it include server *short* name to the Subject field. There is no way to change subject name format. While output request file is signed you cannot edit this request, because signature will become broken and CA (Certification Authority) will reject this request. Subject name short format is not quite useful, because many administrators prefer FQDN (Fully Qualified Domain Name), for example: iLO1.domain.com. I agree with this point that FQDN are more useful and can be used in various network configurations and in multi-domain/multi-forest environments.