0% found this document useful (0 votes)
137 views11 pages

IT Security Lab - PKI

This document outlines the steps to set up a basic public key infrastructure using OpenSSL: 1. Create a root certificate authority (CA) by generating a self-signed certificate and private key. This allows acting as a trusted entity for issuing other certificates. 2. Generate a certificate signing request (CSR) for a web server, including alternative domain names. 3. Use the CA to sign the CSR, creating a server certificate validated by the CA. 4. Configure an Apache web server to use the new certificate, enabling HTTPS and verifying the connection works once the CA is trusted in the browser.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
137 views11 pages

IT Security Lab - PKI

This document outlines the steps to set up a basic public key infrastructure using OpenSSL: 1. Create a root certificate authority (CA) by generating a self-signed certificate and private key. This allows acting as a trusted entity for issuing other certificates. 2. Generate a certificate signing request (CSR) for a web server, including alternative domain names. 3. Use the CA to sign the CSR, creating a server certificate validated by the CA. 4. Configure an Apache web server to use the new certificate, enabling HTTPS and verifying the connection works once the CA is trusted in the browser.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 11

.

ADDIS ABABA INSTITUTE OF TECHNOLOGY

SCHOOL OF INFORMATION TECHNOLOGY AND


ENGINEERING

Department of Software Engineering

Fundamentals of IT Security
Assignment : Public Key Infrastructure

Group members:

1. Elias Melaku ATR/9508/11


2. Natnael Alemayehu ATR/4785/11

Section - 1

December, 2021
Task 1 Becoming a Certificate Authority(CA)

A CA is basically a trusted entity that issues digital certificates that


certifies the ownership of a public key by the named subject. So in this
lab we need to create certificates but since we can’t pay commercial
organizations, we will become the root CA. For this we need a
configuration file openssl.cnf, which is found in usr/lib/ssl/openssl.cnf
but since we need to make some changes for this specific lab that might
change the way it operates, we will make a copy of the openssl.cnf file
and then use and modify that. Some other necessary files and
directories are also created. For instance we need a file to store indexes
and a directory to store all the new certificates generated. The files and
folders from demoCA are shown below.
We then need to run a command to generate a self-signed certificate
and pass a password that will be used for authentication the next time
we ask for a certificate from this root CA. We have chosen to pass the
arguments and the password on the same line to make things easier.

The above command generates a private key, stored in ca.key, and the
public-key certificate is stored in ca.crt.
The above two images show portions of what has been written to ca.crt
and ca.key respectively.
Based on the output of the above two we can answer the following
questions:

● What part of the certificate indicates this is a CA’s certificate?

● What part of the certificate indicates this is a self-signed


certificate?

The above shows the issuer and the subject to be the same
proving self-signed.

● Identify n, p, q, e and d: prime1 and prime2 are p and q


respectively, publicExponent is d and privateExponent is e,
finally modulus is n. These are all variables from ca.key
Task 2: Generating a Certificate Request for our Web Browser

Using the CA we made above, we now want to get a public key certificate for our
website. For this to happen, we first need to generate a Certificate Signing
Request (CSR). This CSR will be sent to the CA, which will verify the information
sent in this request and generate a certificate if it is valid.

As we can see in the image, the command generates a pair of public


and private keys and generates a certificate based on the public key.
The contents of the public key can be seen above.

But sometimes we need to have alternative ways of letting the browser


know to take us to our website. So for this to work we need to add
alternative domains to the list. This can bee done using the -addext flag
of openssl req.

In the above image, we have added the flag and generated the key
along with the desired alternative domains which will be shown more in
the next task.
Task 3: Generating a Certificate for our server

The CSR file needs to have CA’s signature in order to be/form a certificate. So we
need to convert our CSR (server.csr) into a valid certificate by sending it to our CA
and using it’s ca.crt and ca.key. The following image shows how that is done.

In the command, myCA_openssl.cnf is the file we copied in the first section of the
lab into our own directory and made modifications to. To make it have less
restrictions we use the policy_anything policy. To copy extension field from the
request to the final certificate, one modification we need to do is to uncomment
one line from our copy of openssl.cnf (myCA_openssl.cnf) to allow us to make the
copy. We can then check the certificate and also notice here that the alternative
names we added earlier are here as well.
In the above image we can see that the certificate is generated and it also contains
the list of the alternative names that we gave it.

Task 4: Deploying the Certificate in an Apache-Based HTTPS website

Now that we have a certificate generated, we can proceed to test it out by


applying it on an apache based HTTPS website. From the our docker container we
have an apache server set up and we need to configure it to work properly with
our website by changing some of the configurations. Here, Document root is the
where the website’s files are stored, ServerName is the default name of the
website and the lower entries are the ServerAliases, other names that will lead us
to this site. We also provide the directory of the certificates that we just generated
for it. This is shown in the image below
We then enable the SSL module for the apache server and also enable the sites
that we gave it earlier inside the configuration file. Finally we can start the server
and check out if our certificate works.
The above two images show what happens when we try to access the site using
HTTP (this first one in red, showing that the connection is not secure) and then
using HTTPS (the second one where the connection is secure)

One problem that we ran into when trying to access the site using HTTPS however,
was that the browser doesn’t trust our CA and the certificate that it generates. So
we need to add this in our browser under trusted certificates for it to work
properly every time.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy