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.

Hi, PowerShell CryptoGuy is here again.

I'm intensively working on the PowerShell PKI Module development and functionality expansion and I want to talk about recent issue. In next version Get-CertificateTemplate will expose template settings which you can look in Certificate Templates MMC snap-in UI. This includes certificate validity, renewal periods, key generation options, issuance requirements, extensions and so on. In other words, everything else that may have sense for PKI administrators.

While almost everything was very easy to implement, I was struggled with pKIExpirationPeriod and pKIOverlapPeriod attributes in Active Directory. The problem is that documentation states that the value is FILETIME structure. And this structure values starts with 1601 year. FILETIME structure can be transformed to a single long (as type) integer rather than as 2 unsigned integers. I've done the same trick previously in this article: How to convert ms-PKI-Roaming-TimeStamp attribute. However this trick won't work in this case. Some investigations. The following value we can see for default Web Server template in ADSIEdit.msc: