Creating Certificate Requests Using the Certificate Snap-in — Pitfalls and Ladders

There have been a number of changes to the security certificate world lately. Validity periods have shrunk from 5 years to 3 years and now to 2 years. SHA256 has taken over the world. Wildcard certificates have gone from risky to accepted and supported in many scenarios.  All this means we are all rekeying and deploying certificate’s a lot more. Just to make it more fun, there are more options involved. So, it is best to make the task as error free and quick as possible.

There are several ways to create a certificate request on a Microsoft platform. The most functional of these are the ‘certutil’ utility, and the Microsoft Management Console (MMC) Certificate Snap-In. I will focus on the MMC in this post. It runs on virtually any supported Microsoft platform.  For this example we will use Windows 10.  The common pitfalls (errors) in creating certificate requests are noted here along with ladders (solutions) if you already made them.  Let’s get started.

Open an MMC Console and choose File>Add/Remove Snap-in… Highlight ‘Certificates’ and select ‘Add’

You can choose either ‘My user account’ or ‘Computer account’. This just determines what store the certificate will wind up in. If the certificate is targeted for this computer, the computer store is probably better, otherwise use your personal store. Select ‘OK’.

Now right click on ‘Personal‘ and select All Tasks>Advanced Operations>Create Custom Request

You will start a wizard.

 Ignore this window and select ‘Next’.

Highlight ‘Proceed without enrollment policy’ and select ‘Next’.

Here is where we encounter the first common pitfall: The default in the Template pulldown is for a “CNG key”. Next Generation keys are not supported widely. If you use this template your certificate will likely not work in some situations. It is possible to correct this after the fact. That ladder out of this pit is outlined in “Changing a CNG Certificate key to Legacy”. To avoid this extra work, select ‘(No template) Legacy Key’ and then ‘Next’.

This screen appears next. 

Pulldown ‘Details’ and select ‘Properties’.  (you have to use the down arrow on the far right of ‘Details‘)

This brings up a Properties window with four tabs that we will use to define the request. Enter a ‘Friendly name’ – this is the name that will appear with the certificate when you see it in a selection window. Anything that helps you identify it is OK and it can be changed later. Let’s use “My Test Cert” and select ‘Apply’.

Now select the ‘Subject’ tab. This is a very rich interface but for most certificates we just need to select Type: – Common name’ and enter the certificate subject.

We will use “” and select ‘Add’.

Select ‘Apply’ and then the ‘Extensions’ tab.

Most things on this tab are for very specialized certificates. Under ‘Extended Key Usage’, we will just select ‘Client Authentication’ and ‘Server Authentication’.

Select ‘Apply’ and then the ‘Private Key’ tab.

Pull down ‘Key type’ and ‘Key options’.

Here is where we encounter the second common pitfall. Notice the defaults are for a 1024 bit key, the default ‘Key type’ is ‘Signature’, and ‘Make private key exportable’ is not checked. The current acceptable minimum for key length is 2048 bits. To function for SSL, TLS, etc. ‘Key type’ must be set to ‘Exchange’. If you generated a certificate with a 1024 bit key, there is no fix, just do it again. If you forgot to make the certificate exportable and you need to export it as a PFX and install it elsewhere, you also need to do it again.  If you have a certificate set to ‘Signature’, you can change it to ‘Exchange’.   The ladder out of this pit is described in “Changing a Certificate Key Type from Signature to Exchange“. Change these default settings and select ‘Apply’.

Now pull down ‘Cryptographic Service Provider’.

The default is the ‘Microsoft Strong Cryptographic Provider’. This will work and is the normal provider used in most certificates. I would suggest (note: “suggest”) unchecking this, scrolling down and selecting ‘Microsoft Enhancer RSA and EAS Cryptographic Provider’ instead.

NOTE: CHANGING THE SELECTION RESETS THE KEY LENGTH TO 1024. You need to change this back to 2048 and then select ‘Apply’.

Why make this selection? In the simplest terms, the Strong Provider does not support AES algorithms and does not play well with SHA256. The Enhanced RSA and EAS provider (and the Microsoft RSA SChannel Cryptographic Provider – last on the list) do. If you are really in to the differences the details can be found here:

Believe it or not it is possible to change the provider on existing certificate although the options are not anything to anything. It can be done using the same approach described in “Changing CNG Certificate to Legacy”.  Now we can select ‘Apply’ and then ‘OK’ to close this dialog.

Note: if the ‘Properties‘ window closes inadvertently you can reopen it by selecting ‘Properties’ again. Any settings you applied will still be there.  We can now fill in the file location and select ‘Finish’ to complete the request creation.

When you download the signed certificate, simply import that file into the same store using the same snap-in and you are done.

0 Responses to “Creating Certificate Requests Using the Certificate Snap-in — Pitfalls and Ladders”

  • No Comments

Leave a Reply