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.

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.