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
orroot-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 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 betrue
andPathlength
should be0
.Key Usage
must includeCertSign
Server certificate requirements:
Subject Alternative Name
must contain aDNS Name
property with the domain name of the server.Key Usage
should includeDigitalSignature
,KeyAgreement
,KeyEncipherment
andNonRepudiation
Enhanced Key Usage
must includeServer 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 panelClick 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 StoreClick 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
Select the binding of type
https
and clickEdit...
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
Right-click on
Certificates
and selectClick
Next
Browse for your certificate
Click
Next
,Next
andFinish
Microsoft Windows 7 or Server 2008 R2 or earlier¶
Run mmc.exe
Select menu
On the left select
Certificates
Click button
Add >
in the middleSelect
Computer account
Click
Next
andFinish
Click
OK
Expand
Right-click on
Certificates
and selectClick
Next
Browse for your certificate
Click
Next
,Next
andFinish
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
dialogGo to the
Details
tabScroll 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 aboveappid
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
Right-click on your certificate and select
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
On the left select
Certificates
Click button
Add >
in the middleSelect
Computer account
Click
Next
andFinish
Click
OK
Expand
Right-click on your certificate and select
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
Right-click on
Certificates
and selectClick
Next
Browse for your root CA certificate without private key (typically a
.cer
or.crt
file)Click
Next
,Next
andFinish
Microsoft Windows 7 or Server 2008 R2 or earlier¶
Run mmc.exe
Select menu
On the left select
Certificates
Click button
Add >
in the middleSelect
Computer account
Click
Next
andFinish
Click
OK
Expand
Right-click on
Certificates
and selectClick
Next
Browse for your root CA certificate without private key (typically a
.cer
or.crt
file)Click
Next
,Next
andFinish
Firefox Browser¶
In menu select
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
andOK
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
Right-click on the certificate you want to export and select
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
andOK
Microsoft Windows 7 or Server 2008 R2 or earlier¶
Run mmc.exe
Select menu
On the left select
Certificates
Click button
Add >
in the middleSelect
Computer account
Click
Next
andFinish
Click
OK
Expand
Right-click on the certificate you want to export and select
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
andOK
Firefox Browser¶
In menu select
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
andOK
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
Right-click on your certificate and select
Edit the
Friendly name
Click
OK
Microsoft Windows 7 or Server 2008 R2 or earlier¶
Run mmc.exe
Select menu
On the left select
Certificates
Click button
Add >
in the middleSelect
Computer account
Click
Next
andFinish
Click
OK
Expand
Right-click on your certificate and select
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];
}](../../_images/graphviz-fde7cf1d94d8a19c4e893719ef9b9e14c10fc538.png)
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.
![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];
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 -> leftEndCert [style=invis];
rootCaPrivKey -> rootCaCertSig [label="self-sign",constraint=false];
rootCaCertPubKey -> rootCaCertSig [label="verify",constraint=false];
rootCaPrivKey -> endCertSig [label="sign"];
rootCaCertPubKey -> endCertSig [label="verify"];
endCertPrivKey -> tls [label="use"];
endCertPubKey -> tls [label="use"];
rightRootCaCert-> rightEndCert [style=invis];
}](../../_images/graphviz-cdf77e451aa081c0834fa165376858b893c2afbb.png)
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"];
}](../../_images/graphviz-bd1898bc763243997265b2c181762d52126ff760.png)
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.