Certificates Guide¶

Warning

Certificates are security critical and require expert handling. Please carefully read this document and consult with your system administrator or IT department.

This guide describes the process to create, install and configure HTTPS server certificates for web services running in IIS Web Server on Microsoft Windows.

About Certificates¶

The Transport Layer Security (TLS) protocol employed by the encrypted communication protocol HTTPS uses X.509 public key certificates to authenticate servers.

In order for a server to accept HTTPS connections, a server certificate has to be created for and installed on each server. During TLS handshake the server sends its certificate to the client. The client typically validates the server certificate using a set of trusted CA certificates.

For more details, see section Terminology.

Generated certificate files¶

Setting up or maintaining web services using our helper tools to Create a set of root and server certificates yourself typically involves the following files:

root-with-private-key.pfx
- This file contains the root CA certificate and its private key.
- This file was used to sign the server certificate.
- This file can be used to sign further server certificates e.g. for separate machines, or later for certificate renewal.
Warning

This file contains secrets and poses a security threat! (See Security) It should therefore be password-protected and/or moved to offline storage (e.g. a USB stick) after use, or deleted if not needed anymore to sign further certificates.
root-without-private-key.cer or root-without-private-key.crt
- This file contains the root CA certificate but not its private key.
- This file can be installed as trusted root CA certificate on clients, see Root CA Certificate Installation on Clients. This allows the client to validate all server certificates signed by this root CA certificate.
- This file contains no secrets and poses no security risk.
server-with-private-key.pfx
- This file contains the server certificate and its private key.
- This file was signed by the root CA certificate.
- This file can be installed in IIS (or another web server) to enable encrypted communication with HTTPS, see Server Certificate Installation in IIS.

For details about .pfx, .cer and .crt files, see Certificate File Formats.

Security¶

An unprotected root CA certificate with private key (whether in a file or in the certificate store) poses a security threat because it could be misused to sign fraudulent server certificates for arbitrary domains. These fraudulent server certificates then would appear legitimate to all clients that have installed the root CA certificate as trusted root. (see Root CA Certificate Installation on Clients)

We mitigate the security risk by adding name constraints to the root CA certificate. Name constraints restrict signing of server certificates to certain domain names.

To protect a root CA certificate with private key, please do:

password-protect it
and/or move it to offline storage (e.g. a USB stick) after use
or delete it if not needed anymore to sign further certificates

Certificate Creation¶

There are many different ways to create certificates.

Get certificate from commercial certificate authority¶

Commercial certificate authorities (CA) sell server certificates for public web servers that are bound to a specific internet domain such as example.com. There are different validation standards that determine how a CA authenticates you as the legitimate owner of that internet domain. With the simplest (and cheapest) one called Domain Validation the CA checks that you are in control of that internet domain.

Let’s Encrypt (letsencrypt.org) is a certificate authority (CA) that provides certificates in an automated process for free.

Advantage:

Operating systems and some web browsers come with a predetermined set of trusted CA certificates of many commercial certificate authorities. Server certificates bought from a commercial CA can automatically be validated by a client, without having to deal with any CA certificates.

Disadvantage:

Such server certificates typically cannot be procured for servers in a private network (intranet) which are not assigned to a public internet domain.

Get certificate from your IT department¶

Some large organizations operate their own certificate authority (CA) that issues certificates for servers in their private network (intranet). In this case ask your IT department to provide you with a server certificate.

Advantage:

With their centralized management and configuration of operating systems they typically also install and trust their own root CA certificate. Server certificates issued by them can then automatically be validated by a client.

Create a set of root and server certificates yourself¶

You can yourself create a root CA certificate and one or multiple server certificates which are signed by that CA certificate. There are different tools that allow you to do this, for example:

Root CA certificate requirements:

Basic Constraints: CA flag must be true and Pathlength should be 0.
Key Usage must include CertSign

Server certificate requirements:

Subject Alternative Name must contain a DNS Name property with the domain name of the server.
Key Usage should include DigitalSignature, KeyAgreement, KeyEncipherment and NonRepudiation
Enhanced Key Usage must include Server Authentication

Advantage:

You can create server certificates for servers in your private network.

Disadvantage:

You need to register the root CA certificate in your clients in order to properly validate your server certificate.
In a controlled environment of a large organization you may not be allowed to modify the set of trusted root CA certificates.

Warning

Registering/trusting a self-created root CA certificate may pose a security risk! (See Security)

Certificate Installation¶

Server Certificate Installation in IIS¶

To install a server certificate (and its corresponding private key) on a server do the following:

Start IIS Manager
Select your machine (the root node) in the tree on the left
Double-click the Server Certificates icon in the middle panel
Click Import... in the right panel
Choose the server certificate file (extension *.pfx)
Provide the password if your certificate file is password protected
Select the Personal Certificate Store
Click OK

To use the installed server certificate when adding a website in IIS:

In the Add Website dialog:
Select Binding type https
Select your certificate under SSL certificate

To change a server certificate of an existing website in IIS:

Right-click on the website and select Edit Bindings…
Select the binding of type https and click Edit...
Select your certificate under SSL certificate
Click OK
Restart your website

Manual Server Certificate Installation¶

For other servers which don’t use IIS but the underlying HTTP protocol stack (HTTP.sys), you might have to install a server certificate manually.

To install the certificate into the certificate store:

Microsoft Windows 8 or Server 2012 or later¶

Run certlm.msc
Expand Certificates (Local Computer) ‣ Personal ‣ Certificates
Right-click on Certificates and select All Tasks ‣ Import…
Click Next
Browse for your certificate
Click Next, Next and Finish

Microsoft Windows 7 or Server 2008 R2 or earlier¶

Run mmc.exe
Select menu File ‣ Add/Remove Snap-in…
On the left select Certificates
Click button Add > in the middle
Select Computer account
Click Next and Finish
Click OK
Expand Certificates (Local Computer) ‣ Personal ‣ Certificates
Right-click on Certificates and select All Tasks ‣ Import…
Click Next
Browse for your certificate
Click Next, Next and Finish

Manual Server Certificate Binding¶

For other servers which don’t use IIS but the underlying HTTP protocol stack (HTTP.sys), you might have to bind a server certificate manually to a port.

To get the SHA1 hash (or thumbprint) of your certificate:

Double-click the imported certificate in the certificate store to open the Certificate dialog
Go to the Details tab
Scroll down and select the field Thumbprint
Copy the hex-string in the text field below

To see if a certificate is bound to port 12345 (and all IP addresses), run:

netsh.exe http show sslcert ipport=0.0.0.0:12345

To unbind another certificate from port 12345 (and all IP addresses), run as administrator:

netsh.exe http delete sslcert ipport=0.0.0.0:12345

To bind your certificate to port 12345 (and all IP addresses), run as administrator:

netsh.exe http add sslcert ipport=0.0.0.0:12345 certhash=004414b68c0b4e23271f17e9c948480f60ac13c4 appid={00112233-4455-6677-8899-AABBCCDDEEFF}

certhash is the certificate hash/thumbprint you copied above
appid is an arbitrary GUID to identify the owning application

Furthermore you typically need to reserve the URL for non-administrator Windows user accounts. Run as administrator:

netsh.exe http add urlacl url=https://domainname:port/ user=DOMAIN\user

Private Key Permissions of a Certificate¶

For other servers which don’t use IIS, you might have to grant users permission to access the private key of a certificate.

Microsoft Windows 8 or Server 2012 or later¶

Run certlm.msc
Expand Certificates (Local Computer) ‣ Personal ‣ Certificates
Right-click on your certificate and select All Tasks ‣ Manage Private Keys…
Edit the permissions of an existing user group, or add an additional user group
Click OK

Microsoft Windows 7 or Server 2008 R2 or earlier¶

Run mmc.exe
Select menu File ‣ Add/Remove Snap-in…
On the left select Certificates
Click button Add > in the middle
Select Computer account
Click Next and Finish
Click OK
Expand Certificates (Local Computer) ‣ Personal ‣ Certificates
Right-click on your certificate and select All Tasks ‣ Manage Private Keys…
Edit the permissions of an existing user group, or add an additional user group
Click OK

Root CA Certificate Installation on Clients¶

If you bought your server certificate from a commercial certificate authority, you can skip this step.

If you created your own root CA certificate, you need to register it in your clients so they can validate your server certificate.

The root CA certificate must be registered in the certificate store of the operating system to work with Lucid applications and most browsers like Microsoft Internet Explorer, Microsoft Edge and Google Chrome. The Firefox browser uses its own certificate store where the CA certificate must be registered separately.

Warning

Registering/trusting a self-created root CA certificate may pose a security risk! (See Security)

Microsoft Windows 8 or Server 2012 or later¶

Run certlm.msc
Expand Certificates (Local Computer) ‣ Trusted Root Certification Authorities ‣ Certificates
Right-click on Certificates and select All Tasks ‣ Import…
Click Next
Browse for your root CA certificate without private key (typically a .cer or .crt file)
Click Next, Next and Finish

Microsoft Windows 7 or Server 2008 R2 or earlier¶

Run mmc.exe
Select menu File ‣ Add/Remove Snap-in…
On the left select Certificates
Click button Add > in the middle
Select Computer account
Click Next and Finish
Click OK
Expand Certificates (Local Computer) ‣ Trusted Root Certification Authorities ‣ Certificates
Right-click on Certificates and select All Tasks ‣ Import…
Click Next
Browse for your root CA certificate without private key (typically a .cer or .crt file)
Click Next, Next and Finish

Firefox Browser¶

In menu select Options ‣ Privacy & Security ‣ Certificates
Click button View Certificates...
Switch to tab Authorities
Click button Import...
Browse for your root CA certificate without private key (typically a .cer or .crt file)
Check Trust this CA to identify websites.
Click OK and OK

Root CA Certificate Export to File¶

If you want to register a root CA certificate on another client but do no longer have the certificate file available, you can export a root CA certificate to a file again.

Microsoft Windows 8 or Server 2012 or later¶

Run certlm.msc
Expand Certificates (Local Computer) ‣ Trusted Root Certification Authorities ‣ Certificates
Right-click on the certificate you want to export and select All Tasks ‣ Export…
Click Next
Select format DER encoded binary X.509 (.CER)
Click Next
Choose a filename, e.g. root-without-private-key.cer
Click Next, Finish and OK

Microsoft Windows 7 or Server 2008 R2 or earlier¶

Run mmc.exe
Select menu File ‣ Add/Remove Snap-in…
On the left select Certificates
Click button Add > in the middle
Select Computer account
Click Next and Finish
Click OK
Expand Certificates (Local Computer) ‣ Trusted Root Certification Authorities ‣ Certificates
Right-click on the certificate you want to export and select All Tasks ‣ Export…
Click Next
Select format DER encoded binary X.509 (.CER)
Click Next
Choose a filename, e.g. root-without-private-key.cer
Click Next, Finish and OK

Firefox Browser¶

In menu select Options ‣ Privacy & Security ‣ Certificates
Click button View Certificates...
Switch to tab Authorities
Select the certificate you want to export
Click button Export...
Select file type X.509 Certificate (DER)
Choose a filename, e.g. root-without-private-key.cer
Click Save and OK

Edit the friendly name of a certificate¶

If you manually configured your IIS website, the Hostname field in the website binding dialog might be disabled. To enable it, make sure the friendly name of your certificate starts with an asterisk * character.

Follow these steps to edit the friendly name of your certificate:

Microsoft Windows 8 or Server 2012 or later¶

Run certlm.msc
Expand Certificates (Local Computer) ‣ Personal ‣ Certificates
Right-click on your certificate and select Properties
Edit the Friendly name
Click OK

Microsoft Windows 7 or Server 2008 R2 or earlier¶

Run mmc.exe
Select menu File ‣ Add/Remove Snap-in…
On the left select Certificates
Click button Add > in the middle
Select Computer account
Click Next and Finish
Click OK
Expand Certificates (Local Computer) ‣ Personal ‣ Certificates
Right-click on your certificate and select Properties
Edit the Friendly name
Click OK

Terminology¶

X.509 is an ITU-T standard for public key infrastructure with public key certificates and certification path validation.

RFC 5280 specifies a standard for using X.509 v3 certificates in the internet.

The public key certificate (usually just called certificate) is an electronic document used to prove the ownership of a public key. It includes information about the public key, its owner and a digital signature of the issuer which has verified the certificate’s contents are correct.

The subject of a certificate is the owner of the public key in the certificate.
The issuer of a certificate has signed the certificate with his private key.
The signature of a certificate can be verified with the public key of the issuer which is again part of a certificate.

Certificates that are linked like this build a certificate verification chain or path.

Self-signed or not¶

Certificates are categorized by how they are signed and verified:

Self-signed certificates are signed by their own private key, and verified by their own public key
Not self-signed certificates are signed by another private key, and verified by another public key

The top of a chain (often called root) is always a self-signed certificate, all other certificates further down in a chain are never self-signed.

CA vs. End Entity¶

Certificates also are categorized by their subject and purpose:

End entity (or end user) certificates, used e.g. for encrypted HTTPS communication
Certificate Authority (CA) certificates, used to sign other certificates

The bottom of a chain is always an end entity certificate, all other certificates further up in a chain are CA certificates.

CA certificates that are self-signed are called root CA certificates.

CA certificates that are not self-signed are called intermediate CA certificates.

digraph G {
size = "7!";
margin = 0;

leftRootCaCert [label="Self-Signed",shape=box,style=filled,colorscheme=set24,color=2];
subgraph clusterRootCaCert {
label = "Root CA Certificate";
style = filled;
color = lightgrey;
rootCaCertPubKey [label="Public Key",style=filled,fillcolor=white];
rootCaCertSig [label="Signature",shape=doubleoctagon,style=filled,fillcolor=white];
}
rootCaPrivKey [label="Private Key"];
rightRootCaCert [label="CA",shape=box,style=filled,colorscheme=set24,color=1];

leftInterCaCert [label="Not Self-Signed",shape=box,style=filled,colorscheme=set24,color=4];
subgraph clusterInterCaCert {
label = "Intermediate CA Certificate";
style = filled;
color = lightgrey;
interCaCertPubKey [label="Public Key",style=filled,fillcolor=white];
interCaCertSig [label="Signature",shape=doubleoctagon,style=filled,fillcolor=white];
}
interCaPrivKey [label="Private Key"];
rightInterCaCert [label="CA",shape=box,style=filled,colorscheme=set24,color=1];

leftEndCert [label="Not Self-Signed",shape=box,style=filled,colorscheme=set24,color=4];
subgraph clusterEndCert {
label = "Server Certificate";
style = filled;
color = lightgrey;
endCertPubKey [label="Public Key",style=filled,fillcolor=white];
endCertSig [label="Signature",shape=doubleoctagon,style=filled,fillcolor=white];
}
endCertPrivKey [label="Private Key"];
rightEndCert [label="End Entity",shape=box,style=filled,colorscheme=set24,color=3];

tls [label="TLS Protocol",shape=box,style=dotted];

leftRootCaCert -> leftInterCaCert [style=invis];
leftInterCaCert-> leftEndCert [style=dashed,arrowhead=none];

rootCaPrivKey -> rootCaCertSig [label="self-sign",constraint=false];
rootCaCertPubKey -> rootCaCertSig [label="verify",constraint=false];
rootCaPrivKey -> interCaCertSig [label="sign"];
rootCaCertPubKey -> interCaCertSig [label="verify"];
interCaPrivKey -> endCertSig [label="sign"];
interCaCertPubKey -> endCertSig [label="verify"];
endCertPrivKey -> tls [label="use"];
endCertPubKey -> tls [label="use"];

rightRootCaCert -> rightInterCaCert [style=dashed,arrowhead=none];
rightInterCaCert-> rightEndCert [style=invis];
}

This is an example of a chain with 3 certificates: The top one is a self-signed root CA certificate, the middle one is an intermediate CA certificate and the bottom one is an end entity server certificate.

This scenario is common practice for server certificates bought from commercial certificate authorities.

This is an example of a chain with 2 certificates: The top one is a self-signed root CA certificate and the bottom one is an end entity server certificate.

This is the recommended scenario if you create certificates yourself.

Special Case: Self-signed End Entity¶

For testing purposes and very simple isolated applications, it is often useful to collapse the chain into a single self-signed end entity certificate:

digraph G {
size = "7!";
margin = 0;

leftCert [label="Self-Signed",shape=box,style=filled,colorscheme=set24,color=2];
subgraph clusterCert {
label = "Self-signed Server Certificate";
style = filled;
color = lightgrey;
certPubKey [label="Public Key",style=filled,fillcolor=white];
certSig [label="Signature",shape=doubleoctagon,style=filled,fillcolor=white];
}
certPrivKey [label="Private Key"];
rightCert [label="End Entity",shape=box,style=filled,colorscheme=set24,color=3];

tls [label="TLS Protocol",shape=box,style=dotted];

certPrivKey -> certSig [label="self-sign",constraint=false];
certPubKey -> certSig [label="verify",constraint=false];
certPrivKey -> tls [label="use"];
certPubKey -> tls [label="use"];
}

Certificate File Formats¶

There are several filename extensions in relation to certificates. For our purposes on Windows the following are relevant:

.pvk files contain a private key (proprietary file format)
.cer or .crt files contain a certificate (DER file format)
.pfx files typically contain a certificate and its associated private key. They may be password protected. (PKCS#12 file format)

Other files like .pem, .der, .p7b, .p7c, .p12 can be converted with certificate tools.