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.

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.