Many of you use IIS web servers in corporate network for various purposes, for example, to host internal/external web site, ADCS web services, OCSP, WSUS and this list is very long. It is common to manage them all from a centralized place, for example, from web server administrator’s computer. In other words, IIS servers are not managed directly from console.

The problem

By default IIS do not allow remote administration, you have to enable it by starting (and, likely, setting start type to Automatic) Web Management Service (WMSVC). Ok, you started the service on a web server and attempt to connect to the server from remote IIS management console:

Hello S-1-1-0, Crypto Guy is on a failboat board again.

Sometimes it is useful to export a certificate template to a file for future use. For example:

• for custom certificate template backup;
• if you have multiple AD forests, you can transfer configured certificate templates between forests;
• share custom certificate template with partners;
• share certificate template when you are making a online learning session;
• etc..

Till Windows Server 2008 R2 release there was no supported way to export (or serialize) certificate template and move it out of band between two forests. With Windows Server 2008 R2 there was the only publically described way to transfer templates between two forests: AD CS: Cross-forest Certificate Enrollment with Windows Server 2008 R2. This whitepaper includes a PKISync.ps1 script (the script was written by a man who first time faced PowerShell, he-he) which copies certificate templates along other AD data between two forests. The downside of this approach is that it requires a two-way trust between forests and performs data transfer online.

Hello folks, today I want to present you my another product in PKI integration with Windows PowerShell. I worked hard on server-side extensions: PowerShell PKI Module, which is (so far) the biggest project I have developed.

Now I got a time to work on client side extensions. Some prototypes are already published in this blog. The first complete tool (which is a part of client-side extensions) is self-signed certificate creation for testing purposes. The reason why I developed this tool is that makecert.exe (from Windows SDK) is now deprecated. The blog post provides a replacement for makecert — certreq.exe tool. Although, certreq is very cool, there are few things to note:

1. certreq uses external INF file which may be a bit complicated.
2. if there is a mistake in the INF file, certreq raises exception message box. It is a pain when the message box is raised in PowerShell remoting session. You never will see it and unable to close it!

This post summarizes the blog post series about certificate enrollment API (CertEnroll) and their usage in Windows PowerShell. The series covers all common enrollment API usage scenarios.

• Introducing to certificate enrollment APIs — Intro

This post provides basic technical information about certificate requests, what they are, their structures and basic concepts.

• Introducing to certificate enrollment APIs (part 2) — creating offline requests

In this post I'm talking about creating offline certificate requests with delayed submission (when client has no direct connection to CA server).

• Introducing to certificate enrollment APIs (part 3) — certificate request submission and response installation

This post covers various ways how to submit request to Windows CA (both, Standalone and Enterprise), resolve issuance if the request is pending and how to install issued certificate to original client and associate it with generated private key.

• Introducing to certificate enrollment APIs (part 4) — domain certificate enrollment

This post describes the techniques how to enroll for a certificate for domain members by using certificate templates and Enterprise CA.

• Introducing to certificate enrollment APIs (part 5) — Enroll On Behalf Of

In this post I discuss about advanced enrollment called Enroll On Behalf Of another user. This method is usually used with smart card deployment.

• Introducing to certificate enrollment APIs (part 6) — Security considerations and other stuff

This post provides some security information about request management and approval and exposes a useful techniques to create preconfigured self-signed certificates.

In addition, here are few real-life tasks that utilize CertEnroll in PowerShell:

• Self-signed certificate creation with PowerShell

This post covers how CertEnroll can be used to generate self-signed certificates for testing purposes.

• Configure IIS Web Administration to use centralized SSL certificate

This post shows techniques to configure remote IIS management with delegated (instead of default and insecure self-signed certificate) certificate from enterprise CA.

HTH

Other posts in the series:

• Introducing to certificate enrollment APIs — summary

Security considerations

Many of you already heared about a recommendation to place all requests where subject is supplied in the request in pending state for future revision and request approval by the CA manager. Many of PKI administrators consider this as a waste measure and do not follow this recommendation. Several of PKI administrators are aware about the security risk that the requester can put any subject in the request and they require manual approval of the certificate request. Though, they just check for Subject field and/or SAN extension in the request and approve the request if the subject looks like valid.

However there is less-known (but not less dangerous) risk that the requester has included wrong or inappropriate extensions. For example, with default Web Server template it is possible to issue a certificate for OCSP Response Signing. If the administrator is not too smart, a PKI can be compromised due to inappropriate certificate issuance. If you run Get-ExtensionList command from my PowerShell PKI module you will see two interesting properties: EnabledExtensionList and OfflineExtensionList: