Recipe: Export SSL Certificate to PFX

Link: blog.fitterwork.org?id=Export-SSL-Cert-to-PFX                  

PROBLEM & CONTEXT:
SSL Certificates are issued by Certificate Authorities (CA) like GoDaddy as .CRT and .P7B files, but installation on Microsoft Servers requires a PFX file. People often find it difficult to export their SSL Certificates as PFX files because the option is disabled (greyed-out) on the tools they are using. This will happen when your CA renews your certificate and you attempt to use a different computer to export the PFX file.

SOLUTION:

Make sure when you request a certificate from your CA that it allows export. This means submitting a certificate request with EXPORTABLE = TRUE that has been encrypted using a private key held in your PC’s cryptographic store. After the CA issues the certificate you need to download the .CRT and .P7B files and then import them into your cryptographic store using the same private key. Once you’ve done so, you will be able to export the SSL certificate as a PFX file with a password of your own choosing (as required by Azure, etc).

When your CA has renewed your certificate and you want to use a different cryptographic store on a different (new) computer to import the .CRT and .P7B, you will first need to get the CA to rekey the certificate using a certificate request that has been encrypted with the private key from your new computer. Once the CA has rekeyed the certificate you can download it onto your new computer and then export it as a PFX file.  

IMPLEMENTATION:

You should allow about 30 minutes for completing the task. You will need:

·         PC running Windows 10 (operating systems later than Windows NT 4.0 should work, but were not tested in this recipe)

·         Account with a CA like GoDaddy

Follow the steps on the following video, summarised as:

1. Activate IIS on your Windows Computer using Control Panel | Programs and Features
2. Open IIS from Control Panel, Admin Tools
3. Use IIS to create a certificate request file (CSR)
4. Login to your CA account and go to the page that allows the creation (or Re-Keying) of your certificate.
5. Paste the CSR details into the form and wait for your CA to issue the certificate
6. Download the certificate files (.CRT, .P7B) to your computer
7. Use IIS to complete the certificate request by importing the .CRT file
8. Use Windows File Explorer to import the intermediate certificates (P7B)
9. Use IIS to export the certificate as .PFX and keep the password safe

Installing a SLL Certificate on Azure

Installation on Azure is done through your WebApp’s SSL Certificate page which prompts you for the PFX file to upload and then asks for the password. You then need to add a SSL binding by giving the hostname (www.fitterwork.org), selecting the uploaded certificate and then selecting the SSL Type (SNI SSL). You might also need to make changes to your Visual Studio Solution to set an appropriate SSL port number, etc

Checking your Certificate

The FireFox browser provides a simple way to check the SSL certificate once installed on the computer hosting your website. You just need to open your website and then click on the information icon at the left side of the URL as shown below:

Figure 1: Viewing a website’s SSL Certificate using Firefox

WARNINGS:

·         Use the same PC for generating a certificate request (CSR) as well as importing and exporting the certificate files (.CRT, P7B and PFX respectively). This ensures the same private key is used throughout.

·         After asking your CA to rekey your SSL certificate don’t wait too long before downloading and installing it on your website server because the old SSL certificate will be revoked soon after rekeying. For example GoDaddy will revoke the old SSL certificate after 72 hours.

·         Do not disclose details of your certificate request (CSR) or the password used to export the PFX file. However, don’t worry about the private key used to encrypt the CSR and the certificate files as it is securely held in your PC’s cryptographic store and is never exposed in plain text.

DISCUSSION:

In order to understand this recipe rather than just following its steps you first need to understand the role of private keys in encrypting certificate requests (CSR) as well as the certificate files themselves. This is part of the larger Public Key Infrastructure (PKI) that allows the creation, management, distribution, storage and administration of digital certificates and public-key encryption upon which so many e-services rely.

A private key is no more than a series of bits randomly produced by a key generator program and stored securely in an encrypted directory on your PC. This encrypted directory provides you with your own personal cryptographic store and can be found in a subdirectory of your user profile. Most of the problems people encounter with exporting SSL certificates arise because they created a CSR using one private key and then attempted to perform some action on the certificate using another private key. This is what is happening when you use one PC to create the CSR and then try to import/export the certificate on another PC. Unfortunately, sometimes you need to use a different PC for administering your SSL. For example, you might not still have the same PC used to buy and install the certificate a year later when it’s time to renew. In such a case you need to ask your CA (GoDaddy) to reissue the certificate using the private key from your new PC as shown in the video.

In the implementation section we used the Windows 10 Internet Information Services (IIS) tool to generate this CSR file, but you can get a better idea of what’s going on by using the command line Certreq.exe tool to encrypt the following text file called myrequest.txt:

[NewRequest]
 Subject = "CN=www.fitterwork.org"  
 Exportable = TRUE
 KeyLength = 2048              ; Required minimum is 2048
 KeySpec = 1
 KeyUsage = 0xA0
 MachineKeySet = FALSE
 ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
 ProviderType = 12
 HashAlgorithm = SHA256
[EnhancedKeyUsageExtension]
 OID=1.3.6.1.5.5.7.3.1         ; Server Authentication

Listing 1: Certificate Request before Public/private key encryption

Running the following command creates an encrypted CSR file from the above plain text so you can request a certificate from your CA:

·         certreq -new myrequest.txt myrequest.csr

Note that in the plain text file the field ‘Exportable’ is set to true. This means that you will be able to export the certificate as a PFX file once the relevant .CRT file has been imported into your PC’s cryptographic store. IIS doesn’t actually give you the option to set this field as false when you generate a CSR so all resultant certificates generated by the CA are exportable.

Tools for Administering SSL Certificates

Besides IIS and CertReq there are a number of other tools you can use to administer certificates held in your PC’s cryptographic store including:

·         Window File Explorer – selecting a certificate file and right clicking allows you to import it into your PC’s cryptographic store, as demonstrated in the video.

·         Internet Explorer - settings | internet options allows access to the Certificates dialog from where you can import and export certificates; see Figure 2. Open the Certificates dialog from the ‘Content’ tab of the ‘Internet Options’ dialog box.

·         Certificate Snap-in for Microsoft’s Management Console (MMC) – run MMC from the command line and then select the Certificate snap-in from the ‘Add or Remove Snap-ins’ dialog accessed from the MMC’s File menu.

·         OpenSSL - open source allows the private key to be exposed in clear text so facilitating its transfer between computers, but at the cost of increasing the possibility of it being compromised.

Figure 2: Internet Explorer’s Certificates dialog allows import and export of SSL Certificates

How SSL certificates secure website communication

In order to understand how SSL certificates work you need to know something about data communication over the internet and the OSI seven layer model.

Secure Sockets Layer (SSL) works with the transmission control protocol (TCP) to allow secure authentication and encryption/decryption of data at the transport layer. Therefore the higher session, presentation and application layers can be assured that data coming over the lower network layer, via your router, has been faithfully and securely transmitted from your website server. In theory this prevents other actors operating in the network, like hackers, from viewing or altering higher level data (such as hypertext transfer protocol, HTTP) being transferred between your server and a given client’s session on their browser.

Although SSL has been officially superseded by transport layer security (TSL) the certificates needed to secure the transport layer are still called SSL certificates and work happily with both SSL and TSL . These certificates are fundamental to securing the transport layer because they provide the keys necessary for the SSL (or TSL) encryption that must be established between the server and its client. This encryption is achieved by a combination of public/private key and symmetrical key techniques which operate according to an agreed handshake protocol.

The handshake protocol involves the client first requesting a secure communications session and server then responding by returning its SSL certificate. The public part of the server’s key is contained in the certificate and is used by the client to confirm that the certificate was issued by a trusted third-party like GoDaddy, that’s to say an organisation with a root certificate issued to trusted CAs and setup on the client during the installation of the browser. However, there are only a few CAs so often your SSL certificate provider is simply an organisation trusted by the CA to issue certificates. Therefore the client also needs to confirm that your certificate vendor is trusted by the CA, hence the need to validate any intermediate certificates. In order to speed-up the process, clients typically keep copies of validated intermediate certificates in their cryptographic store so subsequent encounters involve just a quick local lookup.

Once the client (browser) has validated your SSL certificate it will use its public key to encrypt a unique symmetrical key it has generated for the session and send it back to the server. The server will then decrypt the session key using the private part of its SSL certificate key and send back an acknowledgement encrypted with this session key; an acknowledgement that the client will then decrypt using the same session key. In this way an encrypted and trusted communication link for the session is established between the client (browser) and the server (website). The mechanics of public and private key encryption are beyond the scope of this discussion. You should just accept that it works, or research further.

Fortunately, the process of validating a website’s SSL certificate and establishing an encrypted channel for the session happens very quickly and is completely transparent to the end-user. The only thing a client might notice is that their browser has prefixed ‘https’ in-front of your website’s URL and also displayed a green padlock to confirm that the session is secure and trusted.

It should now be evident as to why the private key stored in your PC’s cryptographic store is so important. It is part of the private/public key pair is used to encrypt the SSL certificate request (CSR) sent to your certificate provider, as well as forming the public key for the certificate returned to you, and also being part of the same private/public key pair installed on your website server. Anyone gaining access to your private key can gain access to the supposedly secure communication between your website and its clients. Therefore you need to keep your private key safe.

Summary

Microsoft help you protect your private key by keeping it encrypted on your PC and encouraging you to pass it around only in encrypted form both when requesting a SSL certificate ( CSR) and when subsequently installing it, with the certificate, on your webserver. The only downside is that if you lose the PC that stores your private key you’ll need to create a new key, use it to rekey your SSL certificate and then reinstall on your webserver a PFX file containing both your new key and rekeyed certificate. However, armed with this recipe, regenerating the PFX file should now be a relatively simple and better understood process.

ACKNOWLEDGEMENTS

·         Kaushal Kumar Panday, Microsoft Support Escalation Engineer (Blog: http://blogs.msdn.com/kaushal)

·         Ishita Roy, Microsoft  Developer Support Engineer

 HISTORY:

·         March 2018: Created

Discuss: Recipes vs. Patterns

Link: blog.fitterwork.org?id=Recipes-vs-Patterns

Abstract:

Recipes are a great way of handling complexity. You don’t need to know how they work, you just need to know how to wire them up; it’s a black-box solution. Software patterns also help you handle complexity, but they do this by generalising a solution to a particular class of problem. This means that you do need to understand how it works as you must implement your own code; it’s an open-box solution. Implementing software patterns takes time, effort and some experience. In contrast software recipes can often by dropped into your code without too much thought. This might explain why recipes are so pervasive in modern software. The problem with recipes is that their quality and format is variable presenting a real challenge for anyone trying to develop reliable software. We might improve the situation by adopting a similar approach to their documentation as used for software patterns. This is what we’re hoping to achieve in the FitterWork cookbook.

About Recipes

What’s a recipe? Don Lancaster’s TTL Cookbook[1] contains a collection of projects each describing how to build an electronic device from chips like the 74C73 or the 74C00. These are recipes in the sense that they give you a list of ingredients as well as the steps needed to make them into something useful. Software recipes borrow from this idea, but typically help you implement a feature for a computer system. Therefore if you want to provide your website with input validation for a form you can just Google to find a suitable recipe and then follow its instructions to implement it.

Recipes are a great way of handling complexity. When building Don Lancaster’s electronic stopwatch you don’t need to know anything about how CMOS logic chips work, instead you just follow his recipe. Similarly, when validating an input field you just the appropriate Tag Helper to the HTML in your form and then add a suitable data annotation to your model. You don’t need to know anything about how these components work. Instead you just need to know who to wire them up; that’s what the recipe gives you.

About Patterns

Software patterns provide another way of handling complexity. They do so by generalising the solution to a particular class of problem. For example, the ‘Observer’ pattern provides a way of allowing a change in one part of the code to be communicated to many other parts of the code. Once you’ve learnt how the observer pattern works you can implement a solution using standard code constructs. However, introducing such patterns into your code has another key benefit. It makes your code easier to understand, for rather than describing the system at its code level you can describe it much more succinctly in terms of its higher level patterns.

The idea of documenting reusable software patterns was popularized in 1994 by the book ‘Design Patterns’[2], but it was inspired by the work of Christopher Alexander who originally documented common patterns for architecture his book ‘A Pattern Language’[3]. These   patterns generalise complexity by presenting the essence of the idea in a form that invites adaptation. For example, he describes how adding slit windows into a building can draw people towards a beautiful view. Alexander documents each of his patterns with a name, a statement of the problem and its context before he presents a solution together with implementation details. In this way the patterns can be easily understood without the need for the reader to have any background as an architect.

The authors of Design Patterns followed Alexander’s approach when documenting their patterns, but unfortunately didn’t manage to achieve the same degree of accessibility. Consequently Design Patterns isn’t a book for a novice. You can’t just drop a stock solution into your code base. Instead you’ll probably need to look at several implementations and then use parts of each for your own solution. This takes time, effort and a degree of experience. For these reasons software patterns are typically found in the work of expert developers (or computer science students looking for extra credits). It is also rare for software patterns to occupy more than a small percentage of the total code base. Certainly, the early promise of building entire systems by assembling a collection of suitable patterns is yet to become common-place.

Using recipes to build reliable code

In contrast to software patterns, recipes are pervasive in modern code. Indeed we now operate in the era of the mash-up in which much software is little more than code from multiple sources cut and pasted according to various forms of recipes. Let’s take a step back and recall the world late last century. Programs in those days were a mixture of your own team’s code and third-party code; typically libraries with an application programmers interface (API). Vendors like Rogue Wave took responsibility for maintaining the library, documenting the API and providing samples to demonstrate its use. Therefore the recipes (samples) came from one authoritative source; the library vendor. Furthermore in order to sell more of their product the library vendors competed to provide useful recipes as well as good API documentation.

Working in the Mash-up World

Contrast how we worked in the past with the present. Open-source projects staffed by part-time volunteers are typically interested in developing code not recipes or good documentation. This work is left to the community who use their library and for this reason it’s difficult to find high quality sources of information, even from the library’s own forums. Typically, searches for information generate hundreds of hits which may resolve to dozens of recipes of varying quality and format. Therefore you select your black-box solution using a combination of gut-feeling about the skill of its author, the credibility of the site and the effort needed for its implementation. Sometimes the solution works, sometimes it doesn’t, and sometimes the solution seems to work but hides a serious flaw. Clearly this last situation is the most worrying if you are trying to develop reliable software. It can be argued that with open-source you can always look at the library source code. However, that negates one of the key advantages of using a library API; it’s a black-box and others take responsibility for what happens inside. In order to handle the complexity of modern software development we just don’t have the time to start delving into the guts of libraries. Instead we need good API documentation and reliable recipes.

Better Working with Recipes

The best cooking recipes are passed from generation to generation. They are tried, tested and also improved. Poor recipes, like bad furniture, simply don’t survive. However, waiting for software recipes to mature in this way isn’t an option. Therefore we need to find alternative ways to create reliable and well documented recipes.      

Community websites like Stackoverflow (https://stackoverflow.com/) provide a good starting point for software recipes. You might post a question like ‘how can I validate user input in ASP.NET?’ then wait for responses, hopefully including fragments of the code you need. If one of responses solves your problem then you should mark it with a tick so others subsequently searching for the same solution can know it works. People also comment on each other’s solutions so allowing iterative improvement. Adopting this simple approach has allowed Stackoverflow to build-up a vast collection of coding recipes in a wide range of topics. However, the flexible format of the responses means that sometimes important information is missing, like the version of ASP.NET that the solution was tested upon. It also means that improvements in the recipe are often missed as they appear in responses far removed from the original question.

A better way of working with recipes might involve following Christopher Alexander’s approach of giving them a name, a statement of the problem and its context before presenting a solution together with implementation details. We might then follow with a discussion section and a means of voting to improve the given solution. It would also be important to give the solution some provenance in terms of a reference to its source such as the Blog of a well-known authority, or a solution posted elsewhere. I intend to test these ideas in the cookbook section of FitterWork in the hope of encouraging debate and thereby helping others to provide better recipes elsewhere.

Summary:

Software patterns and recipes are both ways of handling the complexity which is inherent in modern software. Patterns are more focused on learning and understanding. They teach you good ways to code by showing you how expert programmers go about solving common problems. Using this knowledge you can then start designing your own solution. In contrast recipes are more like black-boxes. They provide a solution that you can just drop into your code without knowing much about how it works.

The big advantage of using a software pattern is that you will end-up understanding exactly how the code works, but this takes time and effort. The big advantage of using a software recipe is that you solve your problem without much effort, but this comes with the risk that it might not be entirely suitable for your application.  

Given that so much contemporary software relies on recipes, we need to find better ways of identifying the ones we can use to build reliable code. The FitterWork cookbook will explore ways of making better recipes by documenting them in a similar way to software patterns. In  this way it is hoped that people can more easily decide whether a particular recipe is a suitable solution for their specific problem. We can’t avoid recipes, so let’s make the best of them.

References:

1.      Lancaster DE. CMOS Cookbook. 1st edition. Indianapolis: Sams Publishing; 1977. 412 p.

2.      Gamma E, Helm R, Johnson R, Vlissides J, Booch G. Design Patterns: Elements of Reusable Object-Oriented Software. 1 edition. Reading, Mass: Addison-Wesley Professional; 1994. 395 p.

3.      Alexander C, Ishikawa S, Silverstein M, Jacobson M, Fiksdahl-King I, Angel S. A Pattern Language: Towns, Buildings, Construction. New York: Oxford University Press; 1977. 1171 p.

4.      Freeman E, Bates B, Sierra K, Robson E. Head First Design Patterns: A Brain-Friendly Guide. 1st edition. Sebastopol, CA: O’Reilly Media; 2004. 694 p.