Imagine you are doing some cool WCF programming with Certificate authentication, encryption etc. But you are in development and you need some test certificates to do your prototyping and then one day you go into production and need the real certificates. This article discusses both scenarios.
Creating and Installing Digital Certificates – in Production
Make sure you have thought it all out and have all the details before you start requesting and installing and using a certificate. Some of the things to think about:
1. Exact name of the server, including domain you want the certificate for should be known, e.g. http://www.sites.company.com/ is different from sites.company.com is different from http://www.company .com.
2. Decide which organisation you want the certificate for. Also make sure the ‘whois’ record contains your organisation as the owner of the domain you want certificate for; else you will need a domain authorization letter.
3. The kind of authentication you want:
a. Domain authentication: This refers to a type of certificate where the certificate issuing body doesn’t ask for too much details – just the fact ‘CompanyA’ owns ‘DomainA’ – e.g. the ‘whois’ record. These certificates are cheaper and are very very quick to obtain – all online, matter of an hour!
b. Full Organisation Authentication: As opposed to Domain only authentication, full organisation authentication goes a step further and in addition to confirming the fact ‘DomainA’ belongs to ‘CompanyA’, it also confirms ‘CompanyA’ is who it claims to be i.e. its ABN, ACN, other details confirming its identity.
4. Extended Validation: An EV certificate adds a Green colour to the address bar in addition to the padlock a standard certificate adds to a HTTPS request on the browser.
5. Certificate edition: SSL providers sometimes offer various editions of the certificates:
a. Basic: 48-bit certificates; suitable for older style browsers i.e. before IE5 era. All newer browsers should be able to support 128 bits.
b. Standard: forced 128-bit certificates, meaning the server forces the clients (the browsers) to send 128-bit requests.
c. Premium: Usually forced 128-bit certificates with Extended Validation.
6. Choose your CA: CA is the certification Authority; is it going to be Verisign (Big name and big dollars) or Digicert (good service, decent price) or something else.
7. SAN or Subject Alternative name: Subject Alternative Names let you protect multiple host names with a single SSL certificate. Subject Alternative Names allow you to specify a list of host names to be protected by a single SSL certificate. See below:
SAN also comes in 2 flavours:
a. Ability to secure ‘www.domainA.com’ and also ‘domainA.com with the same certificate.
b. The second flavour allows you to secure an extra sub-domain with the same certificate e.g. ‘www.domainA.com’ and ‘sites.domainA.com’.
B) Step by Step procedure to create a certificate:
1. Create a CSR [Certificate Signing Request]: A Certificate signing request refers to a digital request to a CA like VeriSign or Digicert which contains the company details, server/domain details of certificate being requested. Screenshots below show you how to create a CSR:
a. CSR Request data: Go to the Server Certificates under IIS, click on ‘Create Certificate Request’ and on ensuing pop-up (as below) fill in the details.
b. Select the Cryptographic algorithm, in this case Microsoft RSA. Also select the bit length of the certificate. 1024 bit and above is the standard these days, so you could leave the default selection (1024) or higher.
c. Finally, select the file destination and ‘Finish’ the wizard to create your CSR.
d. In case you are wondering, the CSR looks as below.
2. Then go to a CA or certificate issuer’s site like VeriSign or Digicert and buy the appropriate certificate you want. E.g. in the screenshot below for Digicert, simply follow the steps (as outlined in the right-hand side of the screen). Of particular interest is Step-4, where you copy paste the CSR as captured in the text file.
3. Finally, when you finish the payment process on the issuer’s site (and all goes well), you will get an email from the issuer with the certificate as an attachment.
C) Step-by-Step installation procedure: Go to the IIS manager, go the website the CSR was generated for and then go to Server Certificates and click on ‘Complete certificate Request’. On the ensuing pop-up, point to the .cer file received from certificate issuer and click on OK. This will install the certificate ready for use for this website.
D) Making your site HTTPS:
Click on your website in IIS manager, and on the right hand side in ‘Features View’ in IIS7, click on SSL settings and enable SSL by checking the ‘Require SSL’ and ‘Require 128 bit SSL’ to force clients to use 128 bits. In case you are using Virtual Directories, you can enable/disable SSL settings per virtual directory. That’s it, test the site with your browser, when page loads, double click on the pad lock and viola, you see your certificate which is now securing your site.
Creating and Installing Digital Certificates – in Development
Sometimes, if you are like me then most of the times, we work in development infrastructure trying to get that secure WCF service working with HTTPS.
A) Make Cert: In Visual Studio Tools, Make Cert allows you to generate certificates with private keys. You can also generate Root certificates and then generate your certificate using this Root certificate. Go into VS command prompt and issue this command:
Step 1: Create a Certificate to Act as Your Root Certificate Authority
makecert -n “CN=RootCATest” -r -sv RootCATest.pvk RootCATest.cer
1. In this command:
· -n specifies the subject name for the root CA. The convention is to prefix the subject name with “CN = ” for “Common Name”.
· -r specifies that the certificate will be self-signed.
· -sv specifies the file that contains the private key of the certificate.
· RootCATest.cer specifies the name of the file containing the public key of the certificate.
2. In the Create Private Key Password dialog box, enter a password, confirm the password, and then click OK. Optionally, you can click None without entering the password, but this is not recommended for security reasons.
3. In the Enter Private Key Password dialog box, enter the password again and then click OK.
4. This is the password needed to access the private key file RootCATest.pvk in order to generate the file RootCATest.cer containing the public key.
This step creates a certificate named RootCATest.cer and a private key file named RootCATest.pvk.
Step 2: Install Your Root Certificate Authority on the Server and Client Machines
In this step, you install the certificate in the Trusted Root Certification Authorities location on both the client and server machines. All certificates that are signed with this certificate will be trusted by the client and by the server.
Repeat the following steps on both the client and the server machines:
1. Copy the RootCATest.cer file to the client and server machines.
2. Click Start and then click Run.
3. In the command line, type MMC and then click OK.
4. In the Microsoft Management Console (MMC), on the File menu, click Add/Remove Snap-in.
5. In the Add Remove Snap-in dialog box, click Add.
6. In the Add Standalone Snap-in dialog box, select Certificates and then click Add.
7. In the Certificates snap-in dialog box, select the Computer account radio button because the certificate needs to be made available to all users, and then click Next.
8. In the Select Computer dialog box, leave the default Local computer: (the computer this console is running on) selected and then click Finish.
9. In the Add Standalone Snap-in dialog box, click Close.
10. In the Add/Remove Snap-in dialog box, click OK.
11. In the left pane, expand the Certificates (Local Computer) node, and then expand the Trusted Root Certification Authorities folder.
12. Under Trusted Root Certification Authorities, right-click the Certificates subfolder, select All Tasks, and then click Import.
13. On the Certificate Import Wizard welcome screen, click Next.
14. On the File to Import screen, click Browse.
15. Browse to the location of the signed Root Certificate Authority RootCATest.cer file copied in Step 1, select the file, and then click Open.
16. On the File to Import screen, click Next.
17. On the Certificate Store screen, accept the default choice and then click Next.
18. On the Completing the Certificate Import Wizard screen, click Finish.
Step 3: Create and Install Your Temporary Service Certificate
In this step, you create and install the temporary certificate on the server machine from the signed root CA created in the previous step.
1. Open a Visual Studio command prompt and browse to the location where you have the root CA certificate and private key file installed. The files will be named RootCATest.cer and RootCATest.pvk.
2. Run the following command for creating a certificate signed by the root CA certificate:
makecert -sk <> -iv RootCATest.pvk -n “CN=<>” -ic RootCATest.cer -sr localmachine -ss my -sky exchange -pe
In this command:
-sk specifies the key container name for the certificate. This name 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 and make sure that it is available in the current directory.
-n specifies the key subject name for the temporary certificate. If the name of the certificate does not match the DNS or NetBIOS name, later proxy generation will fail.
-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, but since the certificate needs to be available to all users, you should use the localmachine option.
-ss specifies the store name for the certificate. Specify My as the personal store location of the certificate.
-sky specifies the key type, which could be either signature or exchange. Using exchange makes the private key exportable, which is required for message security.
-pe specifies that the private key is exportable. This is useful if you want to export the key and use it in another machine for development or testing purposes.
In the Enter Private Key Password dialog box, enter the password for the root CA private key file specified in Step 2, and then click OK.
Note: Important: The subject name and key file name must match the name of the machine on which you are installing this certificate. If the name does not match, you will see a certificate security error when accessing the service.
Step 4: Configure Your Temporary Service Certificate in IIS to Support SSL
In this step, you configure the Web site in IIS to use the temporary certificate for Secure Sockets Layer (SSL) communication. This will enable SSL for the transport communication. These instructions pertain to IIS version 6.0. IIS 7.0 requires different steps.
Click Start and then click Run.
In the Run dialog box, type inetmgr and then click OK.
In the Internet Information Services (IIS) Manager dialog box, expand the (local computer) node, and then expand the Web Sites node.
Right-click Default Web Site and then click Properties.
In the Default Web Site Properties dialog box, click the Directory Security tab, and then in the Secure Communications section, click Server Certificate.
On the Web Server Certificate Wizard welcome screen, , click Next to continue.
On the Server Certificate screen, select the Assign an existing certificate radio button option, and then click Next. If you have a preexisting certificate that you can remove, first remove the certificate by using the Remove the current certificate option, and then proceed with Step 5.
On the Available Certificates screen, select the certificate you created and installed in the previous step, and then click Next.
Verify the information on the certificate summary screen, and then click Next.
Click Finish to complete the certificate installation.
In the Default Web Site Properties dialog box, click OK.
Temporary certificates should only be used for development and testing purposes. For real-world production environments, use a certificate provided by a CA such as Microsoft Windows Server 2003 Certificate Services or a third party.
Note: Remember these certificates are ok to use in .NET/ WCF world only, when talking to TIBCO/J2EE services, certificates are expected to have certain extensions like Key signature etc.
B) Using Built in Windows CA
So as to generate a certificate as close to as the real deal, use the built in CA in your windows XP/Vista. It will with a few clicks generate a certificate with your machine name as subject name, even attach your domain name, if it is part of the machine name.
Once you are IIS manager, click on “Create Self Signed Certificate”, it pops-up a dialog as below. Just fill in a friendly name and click on OK. This will generate a self signed certificate using your machine’s built in CA.
You can now check to see if this certificate was installed by going to management console as below:
1. Type mmc into startàrun and hit enter.
2. FileàAdd Remove Snap-in and on pop-up double click on your certificates.
3. Select Computer Account and click next, Local Computer and then click finish. Then click ok.
4. In the console tree, look at personal folder and you should be able to see the certificate you just created.
How to export your Public Certificates:
If you remember in beginning of previous article, I described the private/public key pairs and how server/SSL certificate carries both. Sometimes we need to export just the public certificate so that the public key can be sent to clients to communicate over SSL. The exported public certificates can be base-64 encoded, PKCS#7 format etc.
This can then be imported into client machines as below:
But remember in production world, when doing chain authentication; because every server has Thawte’s/Verisign’s/Digicert’s public certificate already in its browser, there is usually no need to exchange public certificate.
Good Luck and as always please leave some suggestions/comments.