This is the second part in a three part series where I aim to shed some light on various options that are available to use within wsHttpBinding, WCF and SSL certificates. Part 1 of this post is available here
In this post we will go over the basics of setting up a SSL certificate which you can use during development. Please note that this post is not aimed to be the “holy grail” of SSL certificates and related topics. There is a wealth of information available on all that on MSDN and various other sources. My aim in this post is to de-clutter the available information, introduce the very basic concepts that you need to know to start using SSL and put you on the right path.
So that said, essentially there are two entities (on a very macro level) that you need to worry about while creating/consuming SSLs. These are
Root Certification Authority
This essentially is a certificate of sorts which gets put in the certificate store of your machine. When you install a CA in your computer, any certificates “signed” by that CA are trusted by your computer. So essentially the job of this guy is to tell your computer whether a certificate can be trusted or not when someone (website) presents a certificate to you. There are many root CAs on the web (think Verisign) which signs various certificates used by websites. Your computer would be set up with a list of the most prominent ones already which enables it to trust and establish secured channels with the login systems of various web sites such as Amazon, Google, Yahoo, MSN etc. If these sites presented a SSL certificate signed by “Nik’s Awesome CA” and your computer does not know about “Nik’s Awesome CA” then your browser is going to refuse communication and show you a warning like this
SSL Certificate Itself
Then there is the SSL certificate itself. It is signed by a CA which authenticates that the presenter of the certificate is who they claim to be. We will soon create our own CA and SSL Certificate and use it to secure the web services.
Please note that there is much more to SSL certificate and trust mechanisms (Certificate revocation lists for example) but I am not going to go into the details of those in this post. We will aim to cover it in a future post completely dedicated to SSL if needed.
So then!
Right! Will all those introductions out of the way let us get started and create all the stuff we need to put some SSL goodness on the WCF services we are writing. For all the below launch a Visual Studio Command Prompt Administrator mode.
Step 1
Start by creating a Root Certificate Authority. Following command would that for you
makecert -r -pe -n "CN=Niks Awesome Cracking CA" -a sha256 -sv NACCA.pvk NACCA.cer
This should create two files, the .cer one is the CA itself and the NACCA is the private keys. A more comprehensive insight into what we just did can be found at MSDN here
Step 2
Use the above created CA to create a SSL Certificate. The command would look something like
makecert -sk "Niks Awesome Certificate" -iv NACCA.pvk -n "CN={machinenamehere}" -ic NACCA.cer -sr localmachine -ss my -sky exchange -pe -a sha256
A full explanation of this command can be found at MSDN here Here are the important bits you need to understand
- -sk specifies the key container name for the certificate. This needs to be unique for each certificate you create.
- -iv specifies the private key file from which the temporary certificate will be created. You need to specify the root certificate private key file name that was created in the previous step and make sure that it is available in the current directory. This will be used for signing the certificate and for key generation.
- -n specifies the key subject name for the temporary certificate. The convention is to prefix the subject name with “CN = ” for “Common Name”.
- -ic specifies the file containing the root CA certificate file generated in the previous step.
- -sr specifies the store location where the certificate will be installed. The default location is currentuser. For certificate authentication, this is the default location that Microsoft Internet Explorer uses for when browsing Web sites that require a client certificate.
- -ss specifies the store name for the certificate. My is the personal store location of the certificate.
- -sky specifies the key type, which could be either signature or exchange. Using signature makes the certificate capable of signing and enables certificate authentication.
- -pe specifies that the private key is generated in the certificate and installed with it in the certificate store. When you double-click the certificate on the General tab, you should see the message “You have a private key that corresponds to this certificate” displayed at the bottom. This is a requirement for certificate authentication. If the certificate does not have the corresponding private key, it cannot be used for certificate authentication.
At this point in time you have created a root CA and used it to create a self signed SSL certificate. If you open up IIS this certificate should be visible in the IIS’s server certificate manager console. Alternatively you can use the MMC and the Certificate snap-in to work with this certificate.
In the next post I will talk about using this SSL certificate to put transport security on our WCF service.