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.

Hello crypto world! One my colleague asked me about how to get certificate purposes property. Here is a little intro.

Certificate purposes are (mainly) limited by Enhanced Key Usages extension:

That is true. In certain cases it is reasonable to limit certificate purposes to a subset of purposes that are allowed in EKU extension. For example, in many and many CAs are allowed for any purpose (All Application Policies) and you can limit it's purposes to a limited set:

Today I will discuss about how to register custom object identifier on a local computer. Why you need this? .NET Oid class which can resolve many common object identifiers to their friendly names and vice versa. However, not all OIDs are registered there. For example, RDS (Remote Desktop Services, former Terminal Services) team introduces special OID for RDP-SSL enhanced key usage with OID=1.3.6.1.4.1.311.54.1.2:

If you have Active Directory domain and at least one Enterprise CA, you can define this OID in Active Directory (by editing certificate template). But what if you don't have Active Directory or internal Enterprise CA? Then PowerShell and CryptoAPI is the answer here!

In previous post we talked about digital signatures and how we can verify them in PowerShell (RSA signatures). I promised to continue this diving with unmanaged stuff.

As we already discussed, CryptoAPI has unmanaged structure CERT_SIGNED_CONTENT_INFO which represents a signed info, including actual data to be signed, algorithm identifier and signature value. In order to deal with this structure we need to use some encoders and decoders. In the decoding process a ASN.1-encoded raw byte array is converted to a structure and in encoding process, a structure is converted to a ASN.1-encoded byte array. CryptoAPI contains 2 (actually 4) functions for ASN.1 encoding/decoding: