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:

Hi S-1-1-0! Today I've released a new version of my PowerShell PKI module.

New commands

Unlike previous versions, this version do not introduce any new commands.

Existing code changes

Instead, I take a time to make the module more consistent. As a part of this work I revisited all help topics. Now all help content is more accurate and consistent. Also I've added additional examples (where I considered this as important) and clarified existing parts.

After discussions with Windows PKI team, I was forced to change the things in Add-ExtensionList and Remove-ExtensionList. CAExtension and UserExtension parameters were renamed to EnabledExtension and OfflineExtension respectively. Parameter descriptions can be found in built-in and online help topics. ExtensionList object properties are renamed accordingly to make them consistent with parameters.

A little note about features in Windows Server 2012 AD CS. Only three major improvements are available:

• All Windows Server 2012 SKUs supports all AD CS features.

From version to version, Microsoft introduces new features in AD CS, however not all are available in all SKUs. For example, in Windows Server 2008 an Online Responder service was added, but was available on Enterprise and Datacenter SKUs. The same thing as with Cross-forest certificate enrollment in Windows Server 2008 R2. Only Enterprise and Datacenter SKUs supported these features. From now, Windows Server 2012 Standard Edition will support *all* features in AD CS. This means that the following roles are available to any who has Windows Server 2012: