Some time ago I've posted a simple code example that will retrieve registered CSPs: Get registered CSPs on the system. The code was updated to provide detailed information about supported algorithms and protocols by particular CSP. Updated version of this code is shipped with my PowerShell PKI module as a Get-CryptographicServiceProvider cmdlet. The output is pretty informative:

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
}

Hello S-1-1-0, PowerShell Crypto Guy still here and today we will talk about the subject. Sometimes you have to use 3rd party applications/tools for certificate request generation. Some of them uses Windows certificate store to store request and a corresponding private keys, but others generates a request file and separate file with unencrypted private key. As a common example are makecert.exe and openssl.exe tools. These applications creates a request file (mostly with .CSR or .REQ file extension) and private key file (mostly with .KEY or .PVK file extension) for UNIX-like systems compatibility. Once certificate request is signed you get a standard X.509 certificate file.

Hello, PowerShell Crypto Guy is here again. A time ago I went through one article: http://www.solution-soft.com/whitepapers/Hyper-V/TimeMachine_Hyper-V_guide.htm which is pretty interesting. However it complains that a related TechNet article Configuring Certificates for Virtual Machine Connection won't work due of the following limitations:

• PowerShell or DOS cannot seem to create a Qword value.
• The VMMS service requires two critical certificates Extension Fields These are:
  Field= “Key Usage” Value = “Key Encipherment, Data Encipherment (30)”
  Field= “1.3.6.1.4.1.311.62.1.1.1 Value = “02 01 04"
  These fields are present in the local host certificates created locally by VMMS. As of the writing of this paper & working with Microsoft support we have been unable to create a certificate with these values using any other means.

Fortunately both statements are not correct:

Table of contents:

• Understanding certificate chains
• Exploring SSL certificates in action
• Building the Certificate Chain
  • Local certificate store method
  • PKCS#7 method
  • Authority Information Access method
  • Crypt32.dll and Microsoft Update
• Binding Certificates
  • Binding Certificates: Exact Match
  • Binding Certificates: Key match
  • Binding Certificates: Name match
• Signature validation
• And more...
• Conclusion
• Related links

Often the certificate path/revocation checking issues that certification authority (CA) admins encounter are caused by invalid CDP (CRL Distribution Point) or AIA (Authority Information Access) configuration. This article covers the Certificate Chaining Engine (CCE) and how it can be used for troubleshooting purposes.