Practical Certificate Knowledge for .NET developers: Introduction

Introduction

This is the first in what I hope to be a series of posts that provide practical knowledge on public/private key cryptography. While this post does not contain any .NET specific information, this series is for .NET developers who have little to no background on practical asymmetric cryptography. 

Articles in this series:

Part One: Introduction

Part Two: Generating Your Own Certificates
Part Three: Setting Up SSL Locally
Part Four: Client Certs: IIS Setup

Part Five: HttpWebRequest Client Certificate Authentication

Asymmetric cryptography is a key security infrastructure component that I struggled to find comprehensive practical knowledge on.

These posts are to get you started, but are by no means comprehensive, and it's up to you to assure that anything you build using this information is actually secure based off how your application is architected. 

The #1 thing you need to remember while working with public key cryptography is that you should never share your private key with anyone without very good reason.

Note that any file that ends with .pfx or .pvk in windows contains your private key, so do not share these. However, .cer files generated by makecert.exe or exported from the windows certificate manager utility do not contain private keys. 

5,000 ft review of public key cryptography

Prior reading

If you haven't gotten yourself familiar with public key cryptography, check out the description here (simple) or here (detailed).

Why use public key cryptography?

Two of the common purposes for using public key cryptography are to verify the authenticity of someone, and to encrypt data with a public key that can only be decrypted by a private key.

Very commonly, you'll use public key cryptography every day when connecting to secure websites. When you attempt to connect to a site securely, the site sends back its public key certificate. The browser then does two things:

• First, the browser verifies authenticity of the site. The browser checks to ensure that the certificate is valid in a few ways: it checks to ensure it's not expired, that the issued to metadata field matches the URL typed into your browser bar, and that the certificate was issued by an authority you trust (more on that later), and checks the digital signature. 
• Second, the SSL handshake occurs, which allows all traffic to the site to be encrypted after the handshake completes.

This article gives an in depth look at an SSL handshake and how traffic is encrypted afterwards.

What actually is a certificate, practically?

In practical terms, a certificate is a file that contains information about the owner of the certificate, who issued the certificate, valid dates, a public key, and additional metadata. Most certs you'll work with are in X.509 format. Certs can be represented in different formats, but for now, thinking about them as a file in order to more easily visualize them is fine. For example, you might also have seen certificates represented as a base-64 encoded string of characters dropped into configuration files. I'll cover how to get this in next week's post.

Certificates can be generated by anyone, though certificates cannot be trusted on their own. When you hear that certificate is "signed", that means it has been digitally signed using a certificate's private key. This gives a parent/child relationship to certificates, where a certificate can have one parent (the cert that signed it with a private key), but many children (certs that a certificate has signed with its private key). Certificates that have no parents are called root certificates (or self-signed certificates, as they use their own private key to sign themselves), and are typically only used to sign other certificates. A certificate is considered trusted if its chain of trust is valid, which means if you trust a certificate that has signed a certificate, you trust both certificates. We'll explore the practical application of trust a little lower in this post and more in next week's post.

Certificate-related file extensions

Windows allows you to export or generate a certificate as a .cer file. One of the most confusing things about certificates is that many people refer to certificates in different ways. Sometimes a combination of public and private key are referred to as a certificate. Other times, it's just a public key certificate. 

Let me try to demystify this a bit.

In Windows, there is a certificate manager that we're going to explore shortly. Inside the certificate manager you'll see all the certificates Windows is aware of, and from there, you can export a certificate as a file. 

Here's where the confusion lies: when you export a certificate, you can choose whether to include the private key or not. However, note that when you choose to export a private key, you can only export as a .pfx file - Personal Information Exchange file (not a .cer file). Some people still call a .pfx file a certificate, though in truth, a certificate makes up only part of a .pfx file.

According to the Windows documentation, a .pfx can contain multiple certificates, their associated private keys, and all certificates in a certification path (also known as a trust chain). Note that the "DER-encoded binary X.509" and "Base64-encoded X.509" formats have a .cer extension, which cannot contain private keys. 

The bottom line is, when reading other sources, be aware that their "certificate" terminology might not align to mine. If anyone reading knows an agreed upon standard and tells me my terminology is incorrect, I'll gladly update these posts.

The Windows Certificate Help area. You can reach this by double clicking a certificate and clicking on 'learn more about certificates.'

So where do all these certificates and private keys live in windows, and how do I know which ones are trusted?

Windows ships with a set of public key certificates from trusted authorities pre-installed and are used to validate other public key certificates that you come across (for example, when browsing the web).

Certificates live in the certificate manager within the Microsoft Management Console. To access this, access a run prompt (Win+R) and type mmc, then press enter. You should see a screen like this:

Now click File->Add/Remove Snap In, select "Certificates", and click the "Add" button.

Next, you'll be prompted to select "My user account", "Service Account", or "Computer Account". Certificates in windows can be tied to any one of these - specific users, the entire computer, or to a service account. For now, click "My user account", and click Finish. You'll see "Certificates - Current User" appear under the Select snap-ins box. Click OK.

Now your management console should look more like this:

First, take a look inside the Trusted Root Certification Authorities->Certificates folder. You'll see quite a few certs in here. The majority of these were likely installed when Windows was installed. This folder contains certificates that your user account trusts, and therefore, any certs you come across that are child certificates of these will be trusted. Most websites you visit will have purchased a certificate from a trusted authority that was signed by a certificate in your Trusted Root Certification Authorities folder, and since you trust the certs in your TRCA folder, you trust the cert the website presents.

Your results may vary on the next example depending on what cert you receive from Facebook, but the process is the same.

For example, browse to https://www.facebook.com and look at the certificate (in Chrome, you can find this by clicking on the green lock icon to the left of the url, clicking on the connection tab, and clicking on certificate information).

You can see that Facebook's cert was issued by "DigiCert High Assurance CA-3". If you click on the certification path tab and view the root certificate (DigiCert) you'll see that the root certificate that Facebook's was derived from is the "DigiCert High Assurance EV root CA", which already exists in your Trusted Root Certificate Authorities folder. 

Step 1: Click on the green lock and click 'certificate information'

Step 2: The certificate sent from Facebook. 

Step 3: Click on 'certification path' on the Facebook cert, then double click on the 'DigiCert' root cert. Check your Trusted Root Certificate Authorities folder for the 'DigiCert High Assurance EV Root CA' cert.

Note that you can even explicitly import your own certificates to the Trusted Root Certification Authorities folder in order to trust them and all their child certs, and we'll look at generating our own certs and making them trusted in the next post. 

You may also be wondering what the rest of the folders are for. We'll cover the "Personal" folder when generating our own certificates in the next post, as this is the location you would put certificates that you have a private key for, but for the rest of them, check out this article. 

Where do certificates come from?

There are a few ways to get a certificate:

1. Purchase one from a trusted authority. This is what public websites will do so that their certificate is trusted by a user's operating system, since the trusted authority's root certificate is already installed in your windows trusted root certificate authorities section (other operating systems will likely trust these as well). 
2. Generate one yourself. You can generate one yourself, but nobody will trust it implicitly. If you want someone to trust it, you can have them import your root certificate into their trusted root certification authorities folder (or another folder within the certificate manager for more granular control - again, see this Microsoft article for more detail). We'll explore generating your own certificates in next week's post.
3. Receive one from someone else - someone else may generate their own certificate and give it to you. One common use case for this scenario is to use that certificate to encrypt data that only that person can decrypt. 

What's a 'client' certificate vs a 'server' certificate?

A 'client authentication' certificate and 'server authentication' certificate (sometimes referred to as an 'SSL' certificate) are both types of X.509 certificates with a special attribute called "Extended Key Usage" set. Extended Key Usage can set be server authentication (a constant value of 1.3.6.1.5.5.7.3.1) or client authentication (a constant value of 1.3.6.1.5.5.7.3.2). Note there are other types as well outside server and client used for different purposes. We will look at how you set the extended key usage attribute when generating a certificate in next week's post. Note that server certificates are commonly used to tie to a web server, allowing for HTTP over TLS (https), whereas client certificates are used by a client to authenticate with a server.

For enterprise integrations, client certificates can be used to validate the authenticity of service consumers using digital signatures. If you consume or create a service that utilizes certificates for authentication, note that you'll also be introducing a maintenance component to your integration - you'll need to periodically renew your certificates based on when they expire. This article has a good conceptual overview of how a digital signature works. Note that in some scenarios, a two-factor authentication may be used that requires both the use of a client certificate as well as username and password.

Trust Model Side Note

As a side note, you may want to check out the two ideas behind trust models (one called "Certificate Authority", which is commonly used where you get certs signed by trusted authorities, and the other called "web of trust"). They're both neat models to check out the pros and cons of depending on what kind of application you're building and how you choose to trust.

Next Time

In the next post I'll be covering the makecert.exe and pvk2pfx.exe utilities, which allow you to generate your own public key .cer files, private key .pvk files, and .pfx personal information exchange files described above. We'll also look at how to install these into the Windows certificate store.