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:

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:

SYMPTOMS

Consider the following scenario. You create certificate certificate by using either Exchange Management Console (EMC) or Exchange Management Shell (EMS) and save it to a file. When you attempt to submit certificate request to a Windows-based Certification Authority (CA) (also known as Microsoft Certificate Services), you may receive error message. If CA server runs on Windows Server 2003 (R2) or Windows Server 2008, you receive the following message:

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: