Using client certificates in .NET part 3: installing the client certificate

Introduction

In the previous post we looked at two tools that help you create self-signed certificates: makecert.exe and pvk2pfx. Makecert performs the bulk of the certificate creation process and pvk2pfx is a packaging tool to build pfx files. Pfx files are easy to import into the certificate store. We also created a root certificate and derived a client certificated from that root. We therefore applied the idea of the chain of trust: if we trust the root then we also trust all its derived certificates.

In this post we’ll import the client certificate into the certificate store.

This process is very similar to importing the server side (SSL) certificate. We saw that process in this post.

certmgr and MMC snap in

The c:\windows\system32 folder includes two GUI tools for certificate management: certmgr.msc and mmc.exe. MMC.exe is a more general tool where you can import so-called snap-ins. Certificates have their own snap-in.

Run mmc.exe as an administrator. The following empty window will open:

Select Add/Remove Snap-in from the File menu. In the “Add or remove snap-ins” dialog click “Certificates”, then the “Add” button. This will open another dialog where you can specify the account for which you’d like to manage the certificates. The accounts are also called “certificate stores”.

Certificates can be dedicated to a specific user which will be stored in the user-level certificate store. Then we have Windows services which also can have certificates. These services can be viewed in the Services window which you can open by double-clicking “services.msc” in the c:\windows\system32 folder. Finally we have the computer-wide certificate store where the server-side SSL certificates are typically stored. That’s where e.g. IIS will locate its certificates as well.

Client certificates are associated with users. Therefore select the “My user account” option and click Finish. Then click the OK button in the Add/Remove Snap-In dialog. The user’s certificate store will open. You can expand the “Certificates – Current User” node:

You’ll see that the installed certificates which have a private key are organised into folders. E.g. if you open the Trusted Root Certification Authorities folder and select the Certificates subfolder you’ll see the list of CAs that Windows trust by default. You’ll see CAs like DigiCert, VeriSign and GlobalSign.

So where are the certificates we created before? They are not listed here yet as they haven’t been imported yet. They must be installed first.

First we have to import our CA certificate “RootCertificate”. Left-click the Certificates folder under Trusted Root Certification Authorities, select All Tasks, then Import. This opens the Certificate Import Wizard dialog:

Click Next. You’ll be able to browse to the root .cer file created in the previous post – RootCertificate.cer in my example:

Click Next a couple of times and then Finish in the dialog. If all goes well then you should see “The import was successful” in a small popup. RootCertificate.cer is indeed available among the trusted CA certificates:

We’ll also need to install the derived client certificate as well. However, we’ll also need the private key otherwise the certificate won’t be trusted. Do you remember which file contained both the public and the private key? Those who said “pfx” are right.

Expand the Personal folder in the GUI and left-click Certificates. Select All Tasks, Import and then press the Browse button like we did above. Browse to the folder where you created all the cer and pfx files in the previous post. Change the file type filter to Personal Information Exchange:

Click Next until the dialog closes. If all goes well then a popup should confirm that the import was successful. You’ll see that the intended purpose of the certificate is “Client authentication”:

If you double-click the certificate you’ll be able to read its properties in the Certificate window. You can see that the certificate was issued by RootCertificate which is our own local CA and that we have access to the private key:

Also, if you click the Certification Path tab then you’ll see that the certificate is indeed derived from RootCertificate:

Great, we’re making progress.

In the next post we’ll start looking into how to work with client certificates in code.

You can view the list of posts on Security and Cryptography here.