Creating a certificate chain of self-signed certificates for development / testing / private environments

As anybody who's ever tried to develop secure services with SSL knows, it's expensive to buy trusted certificates from a certification authority. This is especially true if you're an independent developer who doesn't have a lot of resources. Therefore, we need to be able to generate self-signed certificates in order to develop and test our code before we actually go buy a Trusted Certificate for production. This tutorial will show you how to create a chain of trust and start generating certificates from a self-signing authority. The information here is based off of Microsoft's documentation on MSDN about the matter.

1. Create a signing authority certificate:

• makecert -n "CN=My Signing Authority" -r -sv MySigningCert.pvk MySigningCert.cer

You'll be prompted for passwords for securing the private key. Ensure that you remember them, you'll need them to create the merged file.


2. Merge the private key file and public key file into an encrypted key (this isn't mentioned in the MSDN article linked above, but you can find the documentation here):

• pvk2pfx /pvk MySigningCert.pvk /spc MySigningCert.cer /pfx MySigningCert.pfx /pi mycertpassword /po mycertpassword /f

This step isn't necessary for signing site certificates, but does make things more convenient for storing the certificate and installing it on different machines. Be careful: you should never leave keys laying around file systems on machines, they should always either: a) be stored in an encrypted store like that provided by Windows, or b) be stored on separate storage media that can be physically locked away with access only available to trusted personnel.


3. Start creating site certificates with your signing certificate:

• makecert -iv MySigningCert.pvk -n "CN=www.mywebsite.com" -ic MySigningCert.cer -sv sitekey.pvk sitekey.cer -pe

Now, as above, I recommend that you merge the .pvk and .cer into a .pfx for easy transport and storage.

Journey to robust web services: kick starting use of credentials and certificates for message security, phase I

As any sensible developer of a large scale system knows, security is paramount. Therefore, encryption of sensitive data is an absolute must, encryption of all data is recommended, depending on the field in which you're working. Encryption with WCF is baked in, and is relatively straight forward to setup, though there are a number of important details to which attention must be paid. The steps are somewhat different depending on whether you're using IIS or a self-hosted service (e.g. in a Windows Service).

If you're using a Windows Service, you'll need to perform the following steps to get started:

1. Generate a self-signed certificate (which can be done in the Windows Control Panel)
2. Configure the port to which you're binding the service with the certificate you've just generated, according to this MSDN article. 
3. [to be continued]

If you're using IIS, getting started in a development environment is somewhat simpler.

1. Generate a self signed certificate with IIS. In most cases, IIS will have a developer certificate already installed that you can use.
2. Retrieve the thumbprint of the certificate. You'll need this in order for your application to be able to find it at runtime. WARNING: Don't just copy the thumbprint out of the certificate properties window in IIS, because there are non-printing characters in the text control that will cause you problems when you try to paste the thumbprint into your Web.config file. Write them out by hand.
3. There are two methods you can take for making the certificate available to your WCF service:
1. Follow the guide here if you want to make the certificate available to your application by code.
2. Use the information on this page to create a element underneath a configuration/system.serviceModel/behaviors/behavior/serviceCredentials element.

Finding the public key and public key token of an assembly for use with InternalsVisibleTo

It seems like one of the most common problems out there when it comes to testing and dealing with strongly-named assemblies is getting the public key and the public key token of a CLR assembly when you want to create test projects for that assembly. The quick and easy way: 1. Ensure that 'sn.exe' is in your path. If it's not, it's usually in the Windows SDK directory, typically in a folder like : C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\sn.exe 2. Open up a command window, and navigate to the directory containing the snk you're signing your assemblies with. 3. sn -p my.snk Public.snk 4. sn -tp Public.snk ...and voila, the program will print out the public key and public key token to the screen for you. The reminder I found this at was here. After you've found the public key, you'll want to paste a line similar to the following in the AssemblyInfo.cs file of the project whose internals you wish to expose:

[assembly: InternalsVisibleTo("MyCompany.ProjectName.Tests,
PublicKey=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX")]