International University Fundamental Concepts of Data Security

School of Computer Science and Engineering Course ID: IT140IU

Laboratory Session 6
Public-Key Infrastructure (PKI)

0.1 Overview
Public key cryptography is the foundation of today’s secure communication, but it is subject
to man-in-themiddle attacks when one side of communication sends its public key to the other
side. The fundamental problem is that there is no easy way to verify the ownership of a
public key, i.e., given a public key and its claimed owner information, how do we ensure that
the public key is indeed owned by the claimed owner? The Public Key Infrastructure (PKI) is
a practical solution to this problem.

The learning objective of this lab is for students to gain the first-hand experience on PKI.
SEED labs have a series of labs focusing on the public-key cryptography, and this one focuses
on PKI. By doing the tasks in this lab, students should be able to gain a better understanding
of how PKI works, how PKI is used to protect the Web, and how Man-in-the-middle attacks
can be defeated by PKI. Moreover, students will be able to understand the root of the trust in
the public-key infrastructure, and what problems will arise if the root trust is broken. This lab
covers the following topics:

– Public-key encryption, Public-Key Infrastructure (PKI)

– Certificate Authority (CA), X.509 certificate, and root CA

– Apache, HTTP, and HTTPS

– Man-in-the-middle attacks

0.2 Lab Setup

In this lab, we will generate public-key certificates, and then use them to secure web servers.
The certificate generation tasks will be conducted on the VM, but we will use a container to
host the web server.

0.2.1 Container Setup and Commands

Following these steps to get your server up and running:

1. Create the directory for the lab and download Labsetup.zip

seed@VM:fcods$ mkdir pki

seed@VM:fcods$ cd pki/

seed@VM:.../pki$ wget
https://seedsecuritylabs.org/Labs_20.04/Files/Crypto_PKI/Labsetup.zip

1
 --no-check-certificate

seed@VM:firewall$ unzip Labsetup.zip

seed@VM:firewall$ cd Labsetup/

2. Start the containers (machines)

seed@VM:~/.../Labsetup$ dcbuild

seed@VM:~/.../Labsetup$ dcup

3. Open a new terminal and check for all the running containers (machines).

seed@VM:~$ dockps
1b79b1455c52 www-10.9.0.80

In this lab, we only have one running container with the id of 1b79b1455c52, and container
name is www-10.9.0.80.

4. To get a shell (commandline terminal) on a container (machine), run

// Access container with the id 219ef9f01f0e

seed@VM:~$ docksh 1b79b1455c52 <--- Use container your id here
root@1b79b1455c52:/# <--- INSIDE THE CONTAINER
root@1b79b1455c52:/# exit <--- Exit the container
seed@VM:~$

0.2.2 DNS setup

In this document, we use www.bank32.com as an example to show how to set up an HTTPS
web server with this name. Students need to use a different name for their lab. Unless the
name is specified by the instructors, students should include their last name and the current
year in the server name. For example, if Quang Le does this lab in 2023, the server name should
be www.quang2023.com. You do not need to own this domain; you just need to map this name
to the container’s IP address by adding the following entries to /etc/hosts (the first entry is
required, otherwise, the example in this lab description will not work):

10.9.0.80 www.bank32.com
10.9.0.80 www.quang2023.com

To modify the /etc/hosts file, you can use either Vim or nano with root’s privilege:

seed@VM:~/.../pki$ sudo vi /etc/hosts

or

seed@VM:~/.../pki$ sudo nano /etc/hosts

2
0.3 Lab Tasks
0.3.1 Task 1: Becoming a Certificate Authority (CA)
A Certificate Authority (CA) is a trusted entity that issues digital certificates. The digital
certificate certifies the ownership of a public key by the named subject of the certificate. A
number of commercial CAs are treated as root CAs; VeriSign is the largest CA at the time of
writing. Users who want to get digital certificates issued by the commercial CAs need to pay
those CAs.

In this lab, we need to create digital certificates, but we are not going to pay any commercial
CA. We will become a root CA ourselves, and then use this CA to issue certificate for others
(e.g. servers). In this task, we will make ourselves a root CA, and generate a certificate for this
CA. Unlike other certificates, the root CA’s certificates are self-signed. Root CA’s certifi-
cates are usually pre-loaded into most operating systems, web browsers, and other software
that rely on PKI. Root CA’s certificates are unconditionally trusted.

The Configuration File openssl.conf

In order to use OpenSSL to create certificates, you have to have a configuration file. The
configuration file usually has an extension .cnf. It is used by three OpenSSL commands: ca,
req and x509.

ca The ca command is a minimal certificate authority (CA) application. It

can be used to sign certificate requests in a variety of forms and generate
certificate revocation lists (CRLs). It also maintains a text database of
issued certificates and their status.

req The req command primarily creates and processes certificate requests in
PKCS#10 format. It can additionally create self-signed certificates,
for use as root CAs, for example.
x509 The x509 command is a multi-purpose certificate utility. It can be used
to display certificate information, convert certificates to various forms,
sign certificate requests like a "mini CA", or edit certificate trust
settings.

The manual page of openssl.conf can be found from online resources. By default, OpenSSL
use the configuration file from /usr/lib/ssl/openssl.cnf. Since we need to make changes
to this file, we will copy it into our current directory, and instruct OpenSSL to use this copy
instead.

seed@VM:~/.../pki$ cp /usr/lib/ssl/openssl.cnf ./myCA_openssl.cnf

The [CA default] section of the configuration file shows the default setting that we need to
prepare. We need to create several sub-directories. Please uncomment the unique subject
line to allow creation of certifications with the same subject (remove the "#"), because it is
very likely that we will do that in the lab.

3
 myCA openssl.cnf
. . .
####################################################################
[ CA_default ] <--- THIS SECTION
dir = ./demoCA # Where everything is kept
certs = $dir/certs # Where the issued certs are kept
crl_dir = $dir/crl # Where the issued crl are kept
database = $dir/index.txt # database index file. <--- index.txt
#unique_subject = no # Set to 'no' to allow creation of <--- remove #
# several certs with same subject.
new_certs_dir = $dir/newcerts # default place for new certs.

certificate = $dir/cacert.pem # The CA certificate

serial = $dir/serial # The current serial number <--- serial
crlnumber = $dir/crlnumber # the current crl number
# must be commented out to leave a V1 CRL
crl = $dir/crl.pem # The current CRL
private_key = $dir/private/cakey.pem# The private key

x509_extensions = usr_cert # The extensions to add to the cert

. . .

For the index.txt file, simply create an empty file.

$ mkdir ./demoCA
$ mkdir ./demoCA/newcerts
$ touch ./demoCA/index.txt
$ echo "1000" > ./demoCA/serial

For the serial file, put a single number in string format (e.g. 1000) in the file.

seed@VM:~/.../pki$ echo "1000" > serial

Once you have set up the configuration file openssl.cnf, you can create and issue certificates.

Certificate Authority (CA)

As we described before, we need to generate a self-signed certificate for our CA. This
means that this CA is totally trusted, and its certificate will serve as the root certificate. You
can run the following command to generate the self-signed certificate for the CA:

openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 \

-keyout ca.key -out ca.crt

You will be prompted for a password. Do not lose this password, because you will have to type
the passphrase each time you want to use this CA to sign certificates for others. You will also
be asked to fill in the subject information, such as the Country Name, Common Name, etc.
For example,

4
Generating a RSA private key
.............++++
.....++++
writing new private key to 'ca.key'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:VN
State or Province Name (full name) [Some-State]:Saigon
Locality Name (eg, city) []:Saigon
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Intertnet Survivors Pty Ltd
Organizational Unit Name (eg, section) []:Information Technology
Common Name (e.g. server FQDN or YOUR name) []:insur.com.vn.
Email Address []:[email protected]

The output of the command are stored in two files: ca.key and ca.crt. The file ca.key
contains the CA’s private key, while ca.crt contains the public-key certificate.

You can also specify the subject information and password in the command line, so you will
not be prompted for any additional information. In the following command, we use -subj to
set the subject information and we use -passout pass:dees to set the password to dees.
openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 \
-keyout ca.key -out ca.crt \
-subj "/CN=insur.com.vn/O=Internet Survivors/C=VN" \
-passout pass:dees

We can use the following commands to look at the decoded content of the X509 certificate and
the RSA key (-text means decoding the content into plain text; -noout means not printing
out the encoded version):
openssl x509 -in ca.crt -text -noout
openssl rsa -in ca.key -text -noout

Please run the above commands. From the output, please identify the followings:
1. What part of the certificate indicates this is a CA’s certificate?
2. What part of the certificate indicates this is a self-signed certificate?
3. In the RSA algorithm, we have a public exponent e, a private exponent d, a modulus n,
and two secret numbers p and q, such that n = pq. Please identify the values for these
elements in your certificate and key files.
4. What is the different between using with and without -noout when output the decoded
content of the X509 certificate and RSA key?

5
0.3.2 Task 2: Generating a Certificate Request for Your Web Server
A company called bank32.com (replace this with the name of your own web server) wants to
get a publickey certificate from our CA. First it needs to generate a Certificate Signing
Request (CSR), which basically includes the company’s public key and identity information.
The CSR will be sent to the CA, who will verify the identity information in the request, and
then generate a certificate.

The command to generate a CSR is quite similar to the one we used in creating the self-signed
certificate for the CA. The only difference is the -x509 option. Without it, the command
generates a request; with it, the command generates a self-signed certificate. The following
command generate a CSR for www.bank32.com (you should use your own server name):

$ openssl req -newkey rsa:2048 -sha256 -keyout server.key \

-out server.csr -subj "/CN=www.bank32.com/O=Bank32 Inc./ \
C=US" -addext "subjectAltName = DNS:www.bank32.com, \
DNS:www.bank32A.com, DNS:www.bank32B.com" -passout pass:123456

Adding Alternative names.

Many websites have different URLs. For example, www.example.com, example.com, example.net,
and example.org are all pointing to the same web server. Due to the hostname matching policy
enforced by browsers, the common name in a certificate must match with the server’s hostname,
or browsers will refuse to communicate with the server.

To allow a certificate to have multiple names, the X.509 specification defines extensions to be
attached to a certificate. This extension is called Subject Alternative Name (SAN). Using the
SAN extension, it’s possible to specify several hostnames in the subjectAltName field of a
certificate.

To generate a certificate signing request with such a field, we can put all the necessary informa-
tion in a configuration file or at the command line. We will use the command-line approach in
this task (the configuration file approach is used in another SEED lab, the TLS lab). We can
add the following option to the "openssl req" command. It should be noted that the subjec-
tAltName extension field must also include the one from the common name field; otherwise,
the common name will not be accepted as a valid name.

-addext "subjectAltName = DNS:www.bank32.com, \

DNS:www.bank32A.com, \
DNS:www.bank32B.com"

Please add two alternative names to your certificate signing request. They will be needed in
the tasks later.

0.3.3 Task 3: Generating a Certificate for your server

The CSR file needs to have the CA’s signature to form a certificate. In the real world, the
CSR files are usually sent to a trusted CA for their signature. In this lab, we will use our own
trusted CA to generate certificates. The following command turns the certificate signing request
(server.csr) into an X509 certificate (server.crt), using the CA’s ca.crt and ca.key:

6
openssl ca -config myCA_openssl.cnf -policy policy_anything \
-md sha256 -days 3650 -in server.csr -out server.crt \
-batch -cert ca.crt -keyfile ca.key

myCA openssl.cnf is the configuration file we copied from /usr/lib/ssl/openssl.cnf (we

also made changes to this file in Task 1). We use the policy anything policy defined in the
configuration file. This is not the default policy; the default policy has more restriction, requir-
ing some of the subject information in the request to match those in the CA’s certificate. The
policy used in the command, as indicated by its name, does not enforce any matching rule.

Copy the extension field. For security reasons, the default setting in openssl.cnf does not
allow the "openssl ca" command to copy the extension field from the request to the final
certificate. To enable that, we can go to our copy of the configuration file, uncomment the
following line:

# Extension copying option: use with caution.

# copy_extensions = copy <--- remove #

After signing the certificate, please use the following command to print out the decoded content
of the certificate, and check whether the alternative names are included.

openssl x509 -in server.crt -text

0.3.4 Task 4: Deploying Certificate in an Apache-Based HTTPS

Website
In this task, we will see how public-key certificates are used by websites to secure web browsing.
We will set up an HTTPS website based Apache. The Apache server, which is already installed
in our container, supports the HTTPS protocol. To create a HTTPS website, we just need to
configure the Apache server, so it knows where to get the private key and certificates. Inside
our container, we have already set up an HTTPS site for bank32.com. Students can follow this
example to set up their own HTTPS site.

An Apache server can simultaneously host multiple websites. It needs to know the direc-
tory where a website’s files are stored. This is done via its VirtualHost file, located in the
/etc/apache2/sites-available directory.

/etc/apache2/sites-available This contains configuration files for sites

which are available but not necessarily enabled.

/etc/apache2/sites-enabled This directory contains site files which are

enabled.

In our container, we have a file called bank32 apache ssl.conf, which contains the following
entry:

7
<VirtualHost *:443>
DocumentRoot /var/www/bank32
ServerName www.bank32.com
ServerAlias www.bank32A.com
ServerAlias www.bank32B.com
ServerAlias www.bank32W.com
DirectoryIndex index.html
SSLEngine On
SSLCertificateFile /certs/bank32.crt 1
SSLCertificateKeyFile /certs/bank32.key 2
</VirtualHost>

<VirtualHost *:80>
DocumentRoot /var/www/bank32
ServerName www.bank32.com
DirectoryIndex index_red.html
</VirtualHost>

# Set the following global entry to suppress an annoying warning message

ServerName localhost

The above example sets up the HTTPS site https://www.bank32.com (port 443 is the de-
fault HTTPS port). The ServerName entry specifies the name of the website, while the
DocumentRoot entry specifies where the files for the website are stored. Using the ServerAlias
entries, we allow the website to have different names. You should also provide two alias entries.

We also need to tell Apache where the server certificate (Line 1 ) and private key (Line 2 )
are stored. In the Dockerfile, we have already included the commands to copy the certificate
and key to the /certs folder of the container.

In order to make the website work, we need to enable Apache’s ssl module and then enable
this site. They can be done using the following commands, which are already executed when
the container is built.

# a2enmod ssl // Enable the SSL module

# a2ensite bank32_apache_ssl // Enable the sites described in this file

Starting the Apache server. The Apache server is not automatically started in the
container, because of the need to type the password to unlock the private key. Let’s go to
the container and run the following command to start the server (we also list some related
commands):

// Start the server

# service apache2 start

// Stop the server

# service apache2 stop

8
 // Restart a server
# service apache2 restart

When Apache starts, it needs to load the private key for each HTTPS site. Our private key
is encrypted, so Apache will ask us to type the password for decryption. Inside the container,
the password used for bank32 is 123456. Once everything is set up properly, we can browse
the web site, and all the traffic between the browser and the server will be encrypted.

Please use the above example as a guidance to set up an HTTPS server for your website (choose
your own imaginary domain name). Please describe the steps that you have taken, the contents
that you add to Apache’s configuration file, and the screenshots of the final outcome showing
that you can successfully browse the HTTPS site.

Shared folder between the VM and container. In this task, we need to copy files from
the VM to the container. To avoid repeatedly recreating containers, we have created a shared
folder between the VM and container. When you use the Compose file inside the Labsetup
folder to create containers, the volumes sub-folder will be mounted to the container. Anything
you put inside this folder will be accessible from inside of the running container.
Browsing the website. Now, point the browser to your web server (note: you should put
https at the beginning of your URL, instead of using http). Please describe and explain your
observations. Most likely, you will not be able to succeed, this is because ... (the reasons are
omitted here; students should provide the explanation in their lab reports). Please fix the
problem and demonstrate that you can successfully visit the HTTPS website.

In the following, we provide instructions on how to load a certificate into Firefox. We intention-
ally do not explain why and what certificate should be loaded; students need to figure that out.
To manually add a certificate to the Firefox browser, type the following URL in the address
bar, and click the View Certificates button on the page (scroll to the bottom).

about:preferences#privacy

In the Authorities tab, you will see a list of certificates that are already accepted by Firefox.
From here, we can import our own certificates. After choosing the certificate file, please select
the following option: \Trust this CA to identify web sites". You will see that our cer-
tificate is now in Firefox’s list of accepted certificates.

0.4 Submission
Write your answers together with screenshots of your work in a single file by the name name id l7.pdf.
Submit that file to Blackboard.