Running head: Seed Labs PKI Lab 1

Seed Labs PKI Lab

Jesse Raya, Justin Cook, Marcus Holland
Dr. Mark Heckman
University of San Diego, CSOL-510
SEED LABS PKI LAB 2

Purpose

The purpose of this report is to depict the steps taken by our group to complete the Seed

Labs PKI lab. This lab was intended to serve as hands-on experience working with public-key

infrastructure. The topics covered in this lab include public-key encryption, public-key

infrastructure, certificate authority (CA) and root CA, X.509 certificates and self-signed

certificates, Apache, HTTP/HTTPS, and man-in-the-middle attacks.

Materials

The materials required to conduct this lab were a laptop running Windows 10, a web

browser, and an internet connection. All steps in the lab were conducted on a pre-build Seed

Labs VM running Ubuntu which ran on the Oracle VirtualBox hypervisor. The lab was obtained

from here: https://seedsecuritylabs.org/Labs_16.04/PDF/Crypto_PKI.pdf

Methods

1. Task 1: Becoming a Certificate Authority (CA)

A certificate authority (CA) is a trusted entity that issues digital certificates and certifies

the ownership of public keys. There are many commonly used CAs such as VeriSign, but

for the purpose of this lab, we will serve as our own CA. OpenSSL is the tool that we use

to create certificates and our VM came preloaded with an Openssl.conf file locate in

the /usr/lib/ssl directory.

Next, we created the directories and files as instructed in the lab instructions.
SEED LABS PKI LAB 3

Our next step in this task was to run the below command to generate the self-signed

certificate for the CA.

2. Task 2: Creating a Certificate for SEEDPKILab2020.com

After completing task 1 we became a root CA which makes us ready to sign digital

certificates for customers. To accomplish this we first had to generate an RSA

public/private key pair for our customer which was done with the below command.

It was noted that the contents of the server.key file is encrypted, and certain contents such

as the modulus or publicExponent can only be read if the file is decrypted.

SEED LABS PKI LAB 4

After the company receives its public/private key pair, the next step is to generate a

Certificate Signing Request (CSR). The CSR is then sent to the CA who generates a

certificate for the key after verifying the identity. We used SEEDPKILab2020.com as the

common name of the certificate request.

After generating the CSR we used the following command to turn the CSR (server.csr)

into an X509 certificate (server.crt) by using the CA’s ca.crt and ca.key.

During this step, we received some errors about the contents of the certificate not

matching, (country code and state). We simply removed the CSR and generated a new

one with matching information.

3. Task 3: Deploying Certificate in an HTTPS Web Server

Since SEEDPKILab2020.com is the name of our website we had to edit the /etc/hosts file

to map that hostname to the IP address of our localhost.

SEED LABS PKI LAB 5

To get the webserver working, we combined the secret key and certificate into one file

and then launched the webserver with the below command, specifying it to listen on port

1515.

Now that our web server has been configured and is handling requests, our next step was

to get Firefox to accept our CA certificate. Most certificates provided by trusted, public

CAs are automatically preloaded into the certificate repositories of most web browsers.

Since our certificate was generated by our own CA, we had to manually get Firefox to

accept the certificate. To do this in Firefox we navigated to Edit  Preference 

SEED LABS PKI LAB 6

Privacy & Security  View Certificates and imported our CA’s certificate.
SEED LABS PKI LAB 7

Once our CA’s certificate was added to Firefox’s list of accepted certificates, we reloaded

the webpage and were able to get to https://seedpkilab.com:1515 with no error/warning.

As an additional test, we modified the server.pem file by changing the signature

algorithm from sha256 to sha128 and surprisingly after restarting the webserver we were

still able to access the site with no issues.

As the last test, we changed the URL to https://localhost:1515 which points to the same

location. This time, we got a connection is not secure error like before. This is because

the certificate is signed to SEEDPKILab2020.com and not localhost.

SEED LABS PKI LAB 8

4. Task 4: Deploying Certificate in an Apache-based HTTPS Website

The HTTPS server setup using the Openssl s_server command is primarily for debugging

purposes, so for the next step, we set up a real Apache webserver. The Apache service is

already running on the VM, so for this task, we had to add a VirtualHost entry to the

default-ssl.conf file in the /etc/apache2/sites-available directory

Inside of the DocumentRoot folder, we created a simple HTML document with a single

header for our website.

Next, we ran the following commands to enable SSL and restart the Apache webserver.
SEED LABS PKI LAB 9

Now we were able to navigate to our website, https://seedpkilab2020.com

5. Task 5: Launching a Man-In-The-Middle Attack

The goal of this task is to show how PKI can defeat MITM attacks, and in this task, we

emulate a MITM attack. To accomplish this we first made an identical VirtualHost entry

but changed the ServerName to facebook.com

After this, we restarted the Apache service and entered the passphrase for the key.
SEED LABS PKI LAB 10

To get a user’s HTTPS request to land in our web server, we would need to attack the

routing so that the user’s request is redirected to our website. To accomplish this, we edit

the /etc/hosts file to point facebook.com to the IP address of our localhost.

Now, when we navigated to https://facebook.com we got a warning message that said

‘Your connection is not secure’ and we were taken to our local webserver.

6. Task 6: Launching a Man-In-The-Middle Attack with a Compromised CA

In the previous attack, the MITM attack was unsuccessful because the certificate file that

was specified in the VirtualHost entry was tied to a server name of seedpkilab2020.com.

In this task, a MITM attack will be launched against a compromised CA. To do so, our

group did the same steps as task 5 but we generated a new certificate that and generated a

CSR using the common name facebook.com.

SEED LABS PKI LAB 11

After generating the CSR we generated the certificate with the CA’s signature and

combined the secret key and certificate into one file

Now we updated the VirtualHost entry and restarted the Apache webserver.

After performing these steps, we were able to navigate to https://facebook.com without

error. Although these steps worked, the steps required were extensive and show how

much needs to be done to successfully perform a MITM attack.

Conclusion
SEED LABS PKI LAB 12

This lab was one of the most difficult of this entire course, and going through the lab’s

steps showed the power of PKI. During this lab, we became our own CA and were able to sign

certificates. Importing the certificate of our CA into a web browser allowed us to navigate to a

website over HTTPS using the certificate that we signed. The last steps of this lab showed how a

MITM attack could be conducted, but it was only successful if the CA was compromised. This is

because web browsers have a repository for trusted CA certificates, therefore a compromised CA

could be detrimental to internet users.