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:

Hi folks!

A time ago I wrote a high-level description about the signatures in Digital signatures blog post. And today I want to demonstrate how this works in a real world.

In a real world there are too many signature types, including RSA signatures (plain), Authenticode, XML, Document-specific (MS Word, Adobe PDF, etc.). The simplest signature type is plain RSA signatures. This type of signatures is widely used in PKI (certificates, CRLs, signed BLOBs and so on). In ASN.1 modules (as well as in unmanaged structures), signed BLOB is written like this:

Hello S-1-1-0!

Today I'll describe some interesting features implemented in X509CRL2 class. This class is available within my PowerShell PKI module only (is not a part of .NET Framework).

Verify CRL signature

A time ago a came into an issue with CRL copy to remote web server.

My internal CA publish CRLs to a local drive and custom script copies it to all required distribution points (internal and external web servers). And one day certificate validation failed due to Revocation Offline error. I've checked that CRL is correctly formed, is time valid and so on. But certificate chaining engine still reported mentioned error. Detailed investigation showed that unexpected network-level error occurred during file copy over internet and CRL signature become invalid. Since CRL object contains only signature value without signer certificate, normally it is impossible to verify whether the CRL signature is valid. In order to verify signature, you must obtain signer certificate (issuing CA certificate) and use custom steps to verify the signature.