Posts on this page:
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:
Sometimes I don't understand Microsoft. They a lot of useful things, but thing implementation is quite poor. For example in Windows Server 2008 R2 we have an option to install certificate enrollment service (hereinafter CES) that will allow to securely enroll certificates outside of domain network perimeter. Also CES allows to enroll certificates from non-domain clients. Here is excellent whitepaper about the subject: Certificate Enrollment Web Services in Windows Server 2008 R2. You can setup only one CES instance via Server Manager snap-in. What if we have multiple CA servers and we need to configure CES to work with them? For example, one CA is configured to issue user certificates only and another CA is configured to issue computer certificates only. Also we need to issue these certificates to external clients. In that case we need to setup at least two Windows Server 2008 R2 servers, assign them public IP address and install required CES instance on each CES server. This is pretty ugly. Hopefully there is a trick to install additional CES instances on the same server via CryptoAPI COM interface: CERTOCM.CertificateEnrollmentServerSetup. Currently this interface is not documented on MSDN, therefore I cannot provide interface explanation links. However I wrote PowerShell script that will add additional CES instance and remove specified or all CES instances from local computer. I have commented some code parts for understanding, but the code generally is self-explanatory.
In my previous posts: New-OpsMgrRequest and Install-OpsMgrCertificate I posted two nice scripts. However there is a little bug that operating system version is not recognized correctly. Also these scripts have limited Windows versions support — only Windows Vista and higher. Now I have updated both scripts by fixing several bugs and added Windows XP/Windows Server 2003 (including R2) support. The following scripts demonstrates as well as CertEnroll and XEnroll CryptoAPI interfaces and how you can deal with them in Windows PowerShell. Here is an updated code:
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.