Other posts in the series:

• Introducing to certificate enrollment APIs — summary

Prologue

In previous posts we have discussed and explored certificate enrollment APIs (CertEnroll) to create offline request, submit it to Standalone or  Enterprise CA and install the response. In this post we will cover direct certificate enrollment by using Enterprise CA in the same forest as the client. While previous examples can be used for both domain and workgroup environments, this post assumes that the client is domain member and current forest contains at least one Enterprise CA.

Enrolling user certificate

Direct certificate enrollment is much easier than previous examples, but may be very tricky. We have to start with IX509Enrollment interface. While in previous example we started with IX509CertificateRequestPkcs10 interface, in this case this step can be skipped, because IX509Enrollment will automatically generate PKCS#10 request based on template settings. At first we instantiate IX509Enrollment object:

Other posts in the series:

• Introducing to certificate enrollment APIs — summary

Continuing our CertEnroll discussion (part1, part2) we will talk about request submission and issued certificate installation.

Certificate request submission to a Standalone CA

In the previous post we created an offline request and generated a key pair which remains on a local system. The next step is to submit the request to a CA server. Our request contains no template information and is supposed to be submitted to a Standalone CA or 3rd party CA. Depending on CA version and configuration, various methods can be used. In the case of Windows CA, you can use command-line utility 'certreq.exe' with '-submit' switch, Certification Authority MMC snap-in (certsrv.msc) or CryptoAPI COM interface. In this section we will explore ICertRequest2 and other related COM interfaces. ICertRequest2 interface contains Submit method which submits request to a specified CA server. CA server is specified by passing it's configuration string in the following format: CAHostName\CAName. For example: caserver\contoso-ca, where 'caserver' is CA server host name (NetBIOS or DNS name) and 'contoso-ca' is CA name.

Other posts in the series:

• Introducing to certificate enrollment APIs — summary

Hello S-1-1-0! In previous post we covered basic information about certificate requests, what they are and which information they store. Today we will get basic practice in working with CertEnroll interfaces in Windows PowerShell.

COM interface naming convention

COM objects are normally instantiated by using their ProgId which in most cases consist of two parts:

• Usage area (for example, X509Enrollment);
• Class name.

While usage area is used as is, class names differs to interface name. In MSDN documentation CertEnroll interfaces are prefixed with IX509 that denotes the area type — X.509 objects. For example, IX509PrivateKey. In order to create an instance of this interface in PowerShell, you will have to replace first "I" letter ("I" means Interface) with "C" letter and prepend entire name with X509Enrollment prefix. For example:

Other posts in the series:

• Introducing to certificate enrollment APIs — summary

Hello folks! Today I'm starting with a series of a topics where I will cover how to use certificate enrollment APIs with Windows PowerShell.

Target audience

Target audience for the series is (but not limited to): Systems Administrators, PKI administrators, geeks. While I'll try to keep things as simple as possible, there will be some low-level details (300+) which you can ignore if you don't understand them.

Abstract

Prior to Windows Server 2008 and Windows Vista, certificate enrollment APIs were exposed by XEnroll COM interfaces which were not very powerful and fairly complex to use. You even can compare certificate request wizards in Windows XP and in Windows Vista. Windows Vista and Windows Server 2008 introduced a brandy new certificate enrollment experience with a set of powerful and flexible COM interfaces — CertEnroll. CertEnroll interfaces are described here: Certificate Enrollment API. And we will discuss about these APIs.

A time ago, Windows PKI team posted an article about a tool that allows you to check web server SSL certificate: Verifying The SSL Certificate Expiration with a tool. Unfortunately, the download link is broken. I have this tool and uploaded it to my weblog: VerifySSLCertificate.

• ZIP archive SHA1 hash: C633A3DC3E8A3AA6BDD714EABB925429076A160A
• Executable SHA1 hash: A13CE031F5C1331785E87B62D1464C6260549EC0

The tool is very good, but what if you want to run the test against a bulk of servers? Any sort of automation and batching means some PowerShell stuff :). To provide administrators with such tool I wrote a PowerShell script, where you can test web server SSL certificate and it's status. You can export required fields to XML or CSV for future examination/audit. Let's go: