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.