_ Net manage digital certificate (Digital Certificate) Classes

Digital Certificate is a common content in computer security. On the network, the most common situation is probably the use of SSL secure connections. I will not introduce the digital certificate, RSA algorithm, DSA algorithm, message digest, mutual SSL, and other content. Anyone who needs it should be familiar with it. If you are not familiar with it, but want to learn more, here is a very simple tutorial:

Http://www.youdzone.com/signature.html

Here is a brief introduction to some small examples I have encountered.

Some certificate (sorry, I don't want to translate it into a "Certificate", the same below) are required in our project. They are of different uses, such as mutual SSL, used for digital signature. Windows provides a tool for managing all certificate in your system:

1. Start-> Run-> "MMC"

2. Choose File> Add/remove snap-in> Add> certificates> Computer Account on the tool interface.

In this way, we can see all the certificates installed in the localmachine certificate store. If you select my User Account in the last step, you will see the certificate store currentuser.

At the beginning, our certificate was all managed manually through this tool. However, when certificate grew more and more, and each certificate's permission settings were different, we found that manual management was prone to errors, in addition, the deploy web application is inconvenient (you need to manually add certificate to the server one by one), so I wrote a tool to automate the entire process.

. NET 2.0 provides many classes for the use and management of ceritificate and certificate store. For more information, see system. Security. cryptography. x509certificates. The two most common classes are:

X509store (for certificate store) and x509certificate2 (for X509 standard certificates)

Each certificate store has a sub store. For example, personal stores your personal certificate. (If you add a server certificate to your IIS server using selfssl, the certificate is stored in the personal sub store). For example, trusted root certification authorities are used to store all the root certificate you trust.

Now let's assume that we have a very simple task, that is, to create a sub store of myprojectcerts in the localmachine certificate store, and then put all the certificate used by our project there. net is very easy to do (if you use the traditional Win32 CAPI, it is enough to look at those APIs with 5 or 6 parameters ):

 

 X509Store store = new X509Store(args[1], StoreLocation.LocationMachine);store.Open(OpenFlags.ReadWrite);X509Certificate2 certificate = new X509Certificate2(PATH_TO_CERTIFICATE);store.Add(certificate);store.Close();

 

If your certificate has a private key (I skipped the content of certificate and its public key/Private Key), it must be password-protected, however, it is easy to add a parameter to the constructor:

 

 X509Certificate2 certificate = new X509Certificate2(PATH_TO_CERTIFICATE, PASSWORD);

 

The last part is to assign reasonable permissions to certificate. The most important part is that those accounts have the permission to get a private key of certificate. This is critical because the private key is the final evidence that you are the owner of the Certificate. With the private key, you can generate a signature, encrypt the message, and so on.

However, in this process, the original simple problem encountered some twists and turns.

First, we found that some of our functional functions work normally in the unit test environment of Visual Studio, but when these functions are called by functional modules of Web apps, the test will fail. Later, we realized that it was a permission issue. In unit test, the accounts that directly call those functions were system admin, while certificate was also system admin, therefore, the test program can smoothly obtain the private key to complete the work. However, when these functions are called by web apps, the account being executed becomes ASPnet, and ASPnet does not have the permission to obtain the private key!

So we use the winhttpcertcfg tool in the Windows Server 2003 Resource Kit to assign necessary permissions to ASPnet, but there are still problems.

Originally we manually added certificate to the MMC tool, and then assigned permissions with winhttpcertcfg. Everything works. However, when we use my tool to add certificate, winhttpcertcfg will not be able to set the permission normally. It means that I am not the certificate installer. Hell, I didn't just use my tool to add certifiicate to the certificate store, and then I will use winhttpcertcfg right away. How can I become an uninstaller in five seconds. I don't know why after searching for a long time. I even decompiled winhttpcertcfg to check that it called the CAPI (abbreviation of cryptography API.

Later I found a piece of article here just suddenly: http://blogs.msdn.com/ploeh/archive/2006/12/20/IntegrationTestingWithCertificates.aspx

By default, a certificate object is created: x509certificate2 certificate = new x509certificate2 (path_to_certificate); when the private key of certificate is not persist (sorry, I do not know how to translate it, but do you always know the persistance concept? To the certificate store, you must call the third constructor:

 X509Certificate2 certificate = new X509Certificate2(PATH_TO_CERTIFICATE, PASSWORD, X509KeyStorageFlags.PersistKeySet);

After this is done, what does guess do? Still not good, huh, huh. After further research, we found that, by default, the private key is from persist to the currentuser store, our Certificate is installed in the store localmachine (if you display both currentuser and localmachine in MMC, you will find a wonderful image relationship between them, the certificate you added to localmachine will automatically appear on the currentuser side. This phenomenon actually causes us trouble. I will not start it here ).

The correct answer is as follows:

 

 X509Certificate2 certificate = new X509Certificate2(PATH_TO_CERTIFICATE, PASSWORD, X509KeyStorageFlags.PersistKeySet | X509KeyStorageFlags.MachineKeySet);