"Publication - is the Auction Of the Mind of Man" Emily Dickinson
Tuesday, September 09, 2008

    To further simplify the example, let us assume that the we want to use the certificate to encrypt a message from the client to the service. It is easy to apply what we discuss here to other scenarios.

     

    As we discussed in the previous post, we need to generate two certificates, the root certificate that represents the Certificate Authority, and the certificate that represents the identity of the client or service. We will also create a Certificate Revocation List (CRL).

     

    We will use a tool called makeCert to generate our certificates. Makecert, which ships with the .NET platform,  allows you to build an X509 certificate that can be used for development and testing. It does three things:

    1. Generates a public and private key

    2. It associates the key pair with a name

    3. It binds the name with the public key.

     

    Many of the published examples use makecert to both create and install the certificate. We will do the installation in a separate step because this approach is closer to the use of real certificates.  Separating the certificates also allows the certificates to be installed on many machines instead of just one. This makes distributing certificates to developer machines much easier.

     

    First we will create the Root Certificate with the following command:

     

    makecert -sv RootCATest.pvk -r -n "CN=RootCATest" RootCATest.cer

     

    -n specifies the name for the root certificate authority. The convention is to prefix the name with "CN=" where CN stands for "Common Name"

    -r indicates that the certificate will be a root certificate because it is self-signed.

    -sv specifies the file that contains the private key. The private key will be used for signing certificates issued by this certificate authority. Makecert will ask you for a password to protect the private key in the file.

     

    The file RootCATest.cer will just have the public key. It is in the  Canonical Encoding Rules (CER) format. This is the file that will be installed on machines as the root of the trust chain.

     

    Next we will create a certificate revocation list.

     

    makecert -crl -n "CN=RootCATest" -r -sv RootCATest.pvk RootCATest.crl

     

    -crl indicates we are creating a revocation list

    -n is the name of the root certificate authority

    -r indicates that this is the CRL for the root certificate, it is self-signed

    -sv indicates the file that contains the private key

     

    RootCATest.crl is the name of the CRL file.

     

    At this point we could install the root certificate, but we will wait until we finish with the certificate we will use in our scenario.  Here we need two files. We will need a CER file for the client machine so that we can install the public key associated with the service. Then we will create a PKCS12  format file that will be used to install the public and private key in the service.

     

    The initial step is :

     

    makecert -ic RootCATest.cer -iv RootCATest.pvk -n "CN=TempCert" -sv  TempCert.pvk -pe -sky exchange TempCert.cer

     

    -n specifies the name for the certificate

    -sv specifies the file for the certificate. This must be unique for each certificate created. If you try to reuse a name, you will get an error message .

    -iv specifies the name of the container file for the private key of the root certificate created in the first step.

    -ic specifies the name of the root certificate file created in the first step

    -sky specifies what kind of key we are creating. Using the exchange option enables the certificate to be used for signing and encrypting the message.

    -pe specifies that the private key is exportable and is included with the certificate. For message security is this required because you need the corresponding private key. 

     

    The name of the CER file for the certificate is specified at the end of the command.

     

    Now we need to create the PKCS12 file. We will use a the Software Publisher Certificate Test Tool to create a Software Publisher's Certificate. You use this format to create the PKCS12 file using the pvkimprt tool.

     

    cert2spc TempCert.cer TempCert.spc

    pvkimprt -pfx TempCert.spc TempCert.pvk

     

    We now have four files:

     

    RootCATest.cer

    RootCATest.crl

    TempCert.cer

    TempCert.pvk

     

    The next step is to install these on the appropriate machines. I could not get certmgr to work properly to do an automated install.  The Winhttpcertcfg tool works for PKCS12 format files, but not CER format files. We will use the MMC snap-in for this.

     

     

    Run the mmc snapin tool (type mmc in the Run menu). First we will open the Certificates snap-in.  Choose: Add/Remove Snap-In.

     


     

    Then Add the Certficate Snap-In.

     


     

     

    When you add the snap-in, choose local computer account for the computer you want to install the certificate (usually the local one).


    We want to install the root certificate on both the client and service machines  in the Trusted Root Certificate Store. 

     

     

     

    Select that store, right mouse click and install both the RootCATest.cer and RootCATest.crl files.  On the client side you want to install only the public key in the TempCert.cer file.  On the service side only you want to install the PKCS12 format file (TempCert.pvk) which has the private key for the certificate. Install that in the Personal store. For private key installation you will have to provide the password for the PKCS12 file.

     

    On the service side, we need to give the identity of the running process (NETWORK SERVICE) the rights to read the private key. We use two tools FindPrivateKey and cacls to do this. Run the following command:

     

    for /F "delims=" %%i in ('FindPrivateKey.exe My LocalMachine -n "CN=TempITNCert" -a') do (cacls.exe "%%i" /E /G "NT AUTHORITY\NETWORK SERVICE":R)

     

    Remember to delete these certificates when you are finished with them.

 

 

 

 



9/9/2008 8:07:45 PM (Eastern Standard Time, UTC-05:00) | Comments [6] | Microsoft .NET | SOA | Software Development#
10/1/2008 1:49:43 PM (Eastern Standard Time, UTC-05:00)
-clr does not work with MakeCert on Windows XP SP2 with VS 2008. It is not documented in the Microsoft literature either.
10/1/2008 2:01:40 PM (Eastern Standard Time, UTC-05:00)
That should be the "-crl" switch does not work.
Eric
10/1/2008 8:17:11 PM (Eastern Standard Time, UTC-05:00)
I verfied that this does work with the version of makecert that ships with VS2005 on XP SP2. It certainly works with the version that ships with VS2008 on Windows 2008. I have no clue why the versions of makecert would be different.

In any case, having the certificate revocation list is not absolutely necessary. Even if you cannot create it with the version of makecert that ships with VS2008 for XP SP2, you certainly can install a revocation list on an XP machine that was created elsewhere.
7/16/2010 3:47:36 PM (Eastern Standard Time, UTC-05:00)
Thanks for sharing the information, I hope this will also work on my computer otherwise I'll have to call an expert to help me through. I never worked with this kind certificates before.
7/25/2011 8:12:45 AM (Eastern Standard Time, UTC-05:00)
I am willing to try it but I am a little afraid if I will do something wrong. I wonder if I create a certificate with Makecert how can I translate it on a different server, because I have two servers and I don't want to do the same process twice. I will install the revocation list on my SP2 and tomorrow will be implementation day.
11/17/2011 7:13:54 PM (Eastern Standard Time, UTC-05:00)
My certification list has only one element and don't want to add another one, and I can't add the private key to the list. I will try again tomorrow, maybe I will have more success. If we don't delete the certificates the OS won't try to overwrite them?
Comments are closed.
Search
Archive
Links
Categories
Admin Login
Sign In
Blogroll
Themes
Pick a theme: