Working with X509 certificates can be very frustrating for WCF developers.

This is the first of two posts. In this post I will explain just enough of the background for X509 certificates so that I can explain in the next post how to create and use certificates during .NET development with WCF.   The second post is here.

I do not know any good books for a developer that explains how to use certificates. Even the excellent books on WCF just give you the certificates you need to get the sample code to work. They do not really explain to you why you are installing different certificates into different stores, or how to generate the certificates you need to get your software to work. Very often the examples run on one machine with the client and service sharing the same store. This is not a realistic scenario.

Obviously I cannot explain all about certificates in one blog post. I just wish to share some knowledge. Hopefully it will spare you some grief.

Here is the problem I want to solve.

Suppose you have a set of web services that is accessed by either an ASP.NET or rich client. The service requires the client application to use an X509 certificate to access the service. This could be to encrypt the data, to identify the client, to sign the data to avoid repudiation, or for a number of other reasons. How do you install the certificates on the client and service machines?

Certificate technology is based on asymmetric encryption. 

In the encryption scenario, the client would use the public key of the service to encrypt the traffic.  The service would use its private key to decrypt the message.  In the identification scenario the service would use the public key of the client to identify a message signed with the client's private key.

One of the key issues is how you can be sure that the public key is associated with a given identity. Perhaps somebody substituted their key for the one you should be using.  Perhaps somebody is hijacking calls to the service, or you made a mistake in the address of the service.  A classic example of these types of vulnerabilities  is the "man in the middle attack".  Another key issue is that the private key cannot be read or modified by unauthorized parties.

Public Key Infrastructure (PKI) is the name for a technology that uses a certificate authority (CA) to bind the public key to an identity. This identity is unique to the certificate authority. X509 is a standard for implementing a PKI.  An X509 certificate represents an association between an identity and a public key.

An X509 certificate is issued by a given Certificate Authority to represent its guarantee that a public key is associated with a particular identity. Depending on how much you trust the CA, and the amount of identity verification the CA did, would determine how much trust you have in the certificate. For example VeriSign issues different types of certificates depending on how much verification was done. Sometimes organizations will be their own certificate authorities and issues certificates because they want the maximum amount of control.

This relationship between a CA and its issued certificates is represented in the "chain of trust". Each X509 certificate is signed with the private key of the CA. In order to verify the chain of trust you need the CA's public key.  If you are your own CA authority you can distribute the X509 certificate representing this "root certificate".  Some browsers and operating systems install root certificates as part of their setup. So the manufacturer of the browser or operating system is part of the chain of trust.

The X509 standard also includes a certificate revocation list (CRL) which is a mechanism for checking whether a certificate has been revoked by the CA.  The standard does not specify how often this checking is done. By default, Internet Explorer and Firefox do not check for certificate revocation. Certificates also contain an expiration date.

Another approach to trust is called "peer to peer" trust, or "web of trust".  Given the difficulties of peer trust it is not practical for most Internet applications. It can, however, make development scenarios simpler. Your development environment, however,  should mimic your deployment environment.  Hence I do not recommend using peer to peer trust unless that is practical for your deployed solution.

There are various protocols for transmitting certificates.  We will be interested in two of them.

The Canonical Encoding Rules (CER) protocol will be used to digitally transmit the public key of a given identity. The PKCS12 protocol will be used to transmit the public and private keys. The private key will be password protected.

The next post will describe the mechanisms for creating and installing certificates in a .NET development environment.