Recently I wrote a sample function which allows security administrators to dump trusted root certificates from Microsoft web site.

Microsoft maintains a number of predefined trusted root CAs which are members of Microsoft Root Certificate Program. Here are several useful links on TechNet wiki:

• Introduction to The Microsoft Root Certificate-Program
• Microsoft Root Certificate Program
• Windows Root Certificate Program Members
• Windows Root Certificate Program

In addition, update mechanism is described here: KB931125.

Generally speaking, Microsoft maintains a special certificate trust list (CTL) which is located here. This CTL contains hashes and extended properties for each member of the root certificate program. Also, each certificate is downloadable at:

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:

Other posts in the series:

• Introducing to certificate enrollment APIs — summary

Abstract

In previous posts we discussed and explored certificate enrollment APIs (CertEnroll) to perform various basic enrollment operations. In this section we will talk about advanced certificate enrollment called Enroll On Behalf Of (EOBO). This type of enrollment involves additional mechanism called registration authority (RA). This commonly is used during smart card deployments. For example, an employee prior to get a smart card is went through face-to-face interview with Enrollment Agent where he is instructed about smart card usage rules and is registered in accounting documents. After all formalities are completed, an enrollment agent creates a special certificate request where he put employee's user name (which is obtained from Active Directory) and signs it with his own special Enrollment Agent certificate. And only then the certificate request is submitted to a CA server.