An updated version of the script is published in this blog post: How to convert PEM to PFX in PowerShell (revisited)

Hello again. Continuing the previous post: How to join certificate and private key to a PKCS#12(PFX) file I'll talk a bit more about certutil.exe and openssl.exe private key formats and it differences. Let's start:

• OpenSSL is big-endian by a nature, Microsoft CryptoAPI — little-endian;
• OpenSSL uses ASN.1 structures, but Microsoft CryptoAPI — unmanaged C++-like structures.

Here is a structure type definition for PKCS#1 private key structure:

RSAPrivateKey ::= SEQUENCE {
	version Version,
	modulus INTEGER, -- n
	publicExponent INTEGER, -- e
	privateExponent INTEGER, -- d
	prime1 INTEGER, -- p
	prime2 INTEGER, -- q
	exponent1 INTEGER, -- d mod (p-1)
	exponent2 INTEGER, -- d mod (q-1)
	coefficient INTEGER, -- (inverse of q) mod p
	otherPrimeInfos OtherPrimeInfos OPTIONAL
}

In this article I would like to discuss about DateTime type encoding and decoding by using ASN.1 DER encoding rules. I have already posted similar explanations for other data types: ASN.1

As any other data type DateTime is encoded by using the following structure:

• Tag value. For DateTime must be 0x17
• Data length. For DateTime must be 0x0d (13).
• Actual encoded data.

For one of my project I was required to encode and decode CA certificate "CA Version" extension. The biggest problem is that there are no .NET or CryptoAPI interfaces that can do it.

CA Version abstract

CA Version extension is private Microsoft certificate extension and used in Windows PKI only. In addition, this extension exist only in CA certificate (where CA Type property of Basic Constraints extension is set to CA = True). End entity certificates never contains this extension. Main purpose of this certificate is to simplify CA server lifecycle. Sometimes CA certificate become expired and there are two choices to continue the work: build new CA from scratch or renew CA certificate (see related discussion about CA certificate renewal: Root CA certificate renewal). Though there are certain cases when CA requires to renew its own certificate prior to expiration. As the result CA server will maintain two signing certificates. Windows CA MUST publish CRLs for each valid signing key (not a certificate!). Since CA certificate can be renewed with existing key pair it is possible when CA server maintains multiple CA certificates and single CRL. Or CA server can maintain four CA certificates. Here is a great article that describes how CA Version extension works — Certification Authority Renewal.

Looking to my previous posts I've noticed that I haven't described the methods how certificate extensions are encoded. Cryptography in overall relies on encoded data. For example, digital certificate is a byte array that contains encoded certificate fields. All certificate content is encoded using Abstract Syntax Notation 1 Distinguished Encoding Rules (simply ASN.1 DER). If certificate is stored in Base64 string format, system just converts Base64 content to a byte array. There are several encoding rules for each data type. For example, object identifiers (OIDs) has their own encoding rules, DateTime — their own encoding rules and so on.

In this post I would like to demonstrate encoding rules for Object Identifier data type. Object Identifiers are used to encode Enhanced Key Usage, Application Policies, Certificate Policies and other certificate extensions. The following format is used:

• Tag value
• String length
• Data type
• Actual data string length
• Encoded data string