Public key infrastructure is a system of cryptographic keys, digital certificates, and certificate authorities that is used to verify the authenticity of digital information and ensure secure communication over networks.
A PKI system uses a public key and a private key. While the public key is freely available and used to encrypt data or verify digital signatures, the private key is kept secret and used for decryption or creating digital signatures.
A PKI system is usually made up of the following components:
- Certificate Authority (CA): A CA is a trusted third party that is responsible for issuing digital certificates.
- Digital Certificate: A digital certificate is used to validate the identity of individuals, organizations, or devices. Digital certificates make use of the X.509 standard. A digital certificate usually contains the following:
- Public Key: The public key is made available to anyone who wishes to encrypt messages for the certificate holder or verify their digital signatures.
- Issuer: Information about the CA who issues the certificate.
- Subject: Information about the certificate holder’s identity, such as the organization name, email address, and other relevant identifying details of the individual or entity being certified. This allows third parties to confirm the identity of the certificate holder.
- Validity Period: Information about when the certificate should be considered valid; It typically has an expiration date, after which it needs to be renewed to continue to be trusted.
- Signature: This is the digital signature of the CA that issues the certificate.
- Serial number: this is a unique number that distinguishes the certificate from other certificates.
- Extensions: Newer versions of the X.509 certificates contain optional extension fields.
- Certificate Signing Request (CSR): A CSR is a file containing the public key and other identifying information (such as its domain name, organization details, and contact information) of the entity applying for a digital certificate from a Certificate Authority.
Getting a certificate from a real server
First, get the certificate
openssl s_client -showcerts -connect www.meta.com:443 </dev/null
An actual X.509 certificate contains binary data, making it difficult to print or view. Therefore, when stored in files, they are often encoded using base64.
The best way to view an X.509 certificate is to save the base64 PEM content into a .pem file and use OpenSSL to convert the content into text.
openssl x509 -in meta.pem -text -noout
The public key infrastructure (PKI) helps enforce the CIA triad.
- Confidentiality: using public keys ensures that only the intended recipient can decrypt and read the data.
- Integrity: Digital signatures created using private keys help ensure that data has not been tampered with during transmission.
- Authentication: PKI verifies the identities of individuals or entities in digital communications, reducing the risk of impersonation or fraud.
SeedLabs: PKI Lab
Becoming a Certificate Authority (CA)
A Certificate Authority (CA) is a trusted entity that issues digital certificates. The CA acts as a reliable third party that validates the identity of the certificate requester and issues the certificate after a thorough verification process. This process involves verifying the requester’s ownership of the domain (in the case of website certificates), confirming their legal existence (in the case of organization certificates), or verifying their identity (in the case of personal certificates).
CAs form a hierarchical structure, where some are considered root CAs, and they issue certificates to intermediate CAs. Intermediate CAs, in turn, issue certificates to end-users, such as websites or individuals.
The core functions of a CA consist of:
- Verifying the certificate requester
- Issuing digitally signed X.509 certificates
This lab section involves taking on the role of a root CA and using this CA to issue digital certificates to other entities using OpenSSL.
Unlike other certificates, which another CA usually signs, the root CA’s certificates are self-signed and usually pre-loaded into most operating systems, web browsers, and other software that rely on PKI. This is because a root CA’s certificates are unconditionally trusted.
We need to copy the default config file for OpenSSL to our working directory. It is this copy we would make changes to and use when running our commands.
cp /usr/lib/ssl/openssl.cnf `pwd`
We have to create the following files in the working directory:
- an empty file called index.txt
- a file called serial that contains a number format (e.g., 100000) in the file.
- a folder called newcerts
Other adjustments can be made to the config file as seen fit.
The following command generates a self-signed certificate for our CA (which we will call ModalCA):
openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -keyout modalCA.key -out modalCA.crt
Command Explanation
- req: Specifies that we want to use the certificate request (CSR) utility.
- -x509: Generates a self-signed certificate instead of a certificate request.
- -newkey rsa:4096: Creates a new private key using the RSA algorithm with a 4096-bit key length.
- -sha256: Uses the SHA-256 hashing algorithm to sign the certificate.
- -days 3650: Specifies the validity period of the certificate in days, in this case, 3650 days (approximately 10 years).
- -keyout modalCA.key: Specifies the file name of the private key to be generated (in this case, “modalCA.key”).
- -out modalCA.crt: Specifies the file name of the self-signed certificate to be generated (in this case, “modalCA.crt”). ___
The “modalCA.key” file contains the CA’s private key, while the “modalCA.crt” file contains the public-key certificate.
To view the decoded content of the X509 certificate and the RSA key, we use the following commands:
openssl x509 -in modalCA.crt -text -noout
openssl rsa -in modalCA.key -text -noout
where:
- -text: means decoding the content into plain text
- -noout: means not printing out the encoded version
From the output of the commands above, we can observe the following:
-
The digital certificate belongs to a CA because
CA:TRUEis set under the extensinons component. -
The digital certificate is a self-signed certificate
-
The digital certificate contains the modulus and the public exponent
-
The private key contains the following:
- a public exponent (e)
- a private exponent (d)
- a modulus (n)
- two secret numbers p and q, such that n = pq.
Generating a Certificate Request for Your Web Server
This lab section involves requesting an X509 certificate from our CA.
A company called ukadike32 wants to get a public key certificate from our CA for its webserver, www.ukadike32.com. The first step is 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.
Many websites have different URLs that point to the same web server. Due to the hostname matching policy enforced by browsers, the common name in a certificate must match the server’s hostname, or browsers will refuse to communicate with the server.
Using the Subject Alternative Name (SAN) extension, it is possible to specify several hostnames in the subjectAltName field of a certificate. The subjectAltName extension field must also include the hostname from the common name field; otherwise, the common name will not be accepted as a valid name.
Our CSR for www.ukadike32.com will include two alternative names.
openssl req -newkey rsa:2048 -sha256 -keyout ukadike32.key -out ukadike32.csr \
-addext "subjectAltName = DNS:www.ukadike32.com, \
DNS:www.ukadike32A.com, DNS:www.ukadike32B.com"
The “ukadike32.key” file contains ukadike32’s private key, while the “ukadike32.csr” file contains the CSR.
To view the decoded content of the X509 certificate and the RSA key, we use the following commands:
openssl req -in ukadike32.csr -text -noout
openssl rsa -in ukadike32.key -text -noout
Generating a Certificate for your server
This lab section involves issuing an X509 certificate from our CA for an entity.
The CSR file needs to contain the CA’s signature to become a certificate. The CA uses its digital certificate and private key to sign the CSR. This is done through the following command:
Lab Environment
In the below command, modalCA openssl.cnf is the configuration file we copied from /usr/lib/ssl/openssl.cnf and made changes to. For the purpose of this lab, we use the following:
- We use the policy_anything policy defined in the configuration file to bypass the restrictions placed by the default policy. This policy does not enforce any matching rule in the subject name of the CSR and the X509 certificate.
- set “copy_extensions = copy” in the config file. 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. ___
openssl ca -config modalCA_openssl.cnf -policy policy_anything \
-md sha256 -days 3650 \
-in ukadike32.csr -out ukadike32.crt -batch \
-cert modalCA.crt -keyfile modalCA.key
After signing the certificate, we can print out the decoded content of the certificate to check whether the alternative names are included.
openssl x509 -in ukadike32.crt -text -noout
Deploying Certificate in an Apache-Based HTTPS Website
This lab section explores how public-key certificates are used by websites to secure web browsing. The HTTPS website will be set up on an Apache server.
To create an HTTPS website, we have to tell the Apache server where to get the private key and certificates.
An Apache server has at least a VirtualHost file located in the /etc/apache2/sites-available directory. To serve www.ukadike32.com, we will have to create a VirtualHost file for the site. The VirtualHost file will be named ukadike32_apache_ssl.conf and will contain the following entry:
<VirtualHost *:443>
DocumentRoot /var/www/ukadike32
ServerName www.ukadike32.com
ServerAlias www.ukadike32A.com
ServerAlias www.ukadike32B.com
DirectoryIndex index.html
SSLEngine On
SSLCertificateFile /certs/ukadike32.crt
SSLCertificateKeyFile /certs/ukadike32.key
</VirtualHost>
We also need to enable Apache’s ssl module and then enable the ukadike32 site with the following commands:
a2enmod ssl
a2ensite ukadike32_apache_ssl
Finally, we can start the Apache server and provide the password to unlock ukadike32 site’s private key when prompted.
service apache2 start
If the service is already running, we can always restart it using:
service apache2 restart
or reload the configuration files using:
service apache2 reload
Once everything is set up properly, we can browse the https website. Before we do that, we have to include the site and its aliases in our host file.
On opening https://www.ukadike32.com/ we are greeted with a warning from the Firefox browser about a potential security risk. This basically tells us that the CA that issued the certificate for www.ukadike32.com is unknown to Firefox and is not to be trusted.
This can be fixed by importing the modalCA.crt certificate into Firefox. This will add ModalCA to the list of root CAs that Firefox trusts and is aware of. It can be done through the following steps:
- Go to
about:preferences#privacyand scroll till you find certificates - Click on view certificates to open the certificate manager window
- Go to the authorities tab and click import to add modalCA.crt to the list of CAs that Firefox trusts.
Now, when we revisit https://www.ukadike32.com/, the error is gone and the website opens correctly.
However, Firefox still gives the user a heads-up that the certificate issuer is not on its list of trusted CAs, meaning it did not ship with the software and was added manually.
Launching a Man-In-The-Middle Attack
An MITM attack involves someone acting as an exchange point between two parties while the parties think they are communicating directly with one another.
This lab section explores how PKI can defeat Man-In-The-Middle (MITM) attacks. We will select two popular websites for this lab:
- A banking site:
www.zenithbank.com - A social networking site:
www.twitter.com
Setting up the malicious website
In the previous task, we had already set up an HTTPS website and will use the same Apache server to impersonate www.zentihbank.com and www.twitter.com. The config file will be similar but with some adjustments.
In the real world, an attacker will not be able to get a valid certificate for www.zentihbank.com and www.twitter.com, so we will use the same certificate that we used for www.ukadike32.com.
To serve www.zenithbank.com and www.twitter.com, we will have to create a VirtualHost file for both sites in the /etc/apache2/sites-available directory. The VirtualHost file will be named zenith32_apache_ssl.conf and twitter32_apache_ssl.conf, respectively.
The zenith32_apache_ssl.conf file will contain:
<VirtualHost *:443>
DocumentRoot /var/www/zenith32
ServerName www.zenithbank.com
DirectoryIndex index.html
SSLEngine On
SSLCertificateFile /certs/ukadike32.crt
SSLCertificateKeyFile /certs/ukadike32.key
</VirtualHost>
The twitter32_apache_ssl.conf file will contain:
<VirtualHost *:443>
DocumentRoot /var/www/twitter32
ServerName www.twitter.com
DirectoryIndex index.html
SSLEngine On
SSLCertificateFile /certs/ukadike32.crt
SSLCertificateKeyFile /certs/ukadike32.key
</VirtualHost>
We also need to enable Apache’s SSL module and then enable the ukadike32 site with the following commands:
a2enmod ssl
a2ensite zenith32_apache_ssl
a2ensite twitter32_apache_ssl
Finally, we can restart the Apache server and provide the password to unlock ukadike32 site’s private key when prompted.
service apache2 restart
The goal is that when a user tries to visit www.zentihbank.com or www.twitter.com the user will land on our server, which hosts a fake website for www.zentihbank.com and www.twitter.com. This task will simulate a DNS-attack approach by editing the victim’s machine /etc/hosts file to emulate the result of a DNS cache poisoning attack.
The victim’s machine /etc/hosts file will contain the following:
10.9.0.80 www.zenithbank.com
10.9.0.80 www.twitter.com
Once everything is set up properly, we can browse the https websites.
First of all, we visit https://www.twitter.com. We are greeted with a warning from the Firefox browser about a potential security risk. This basically tells us that the certificate the website is using was not issued for it but rather for another website. Thus an impersonation could be in progress.
Next, we visit https://www.zenithbank.com. We are also greeted with a warning from the Firefox browser about a potential security risk. This basically tells us that the certificate the website is using was not issued for it but rather for another website. Thus an impersonation could be in progress.
Launching a Man-In-The-Middle Attack with a Compromised CA
This lab section explores what happens if a root CA is compromised and its private key is stolen. The implication of this is that the attacker can generate any arbitrary certificate using the CA’s private key.
We will assume that the attacker was able to get hold of ModalCA’s private key (modalCA.key). All the attacker needs to do is generate a certificate for the fake websites and use ModalCA’s private key to sign the fake certificate.
Generating a Certificate Signing Request for the fake websites
The attacker will create two CSRs, one for each website he wants to imitate.
openssl req -newkey rsa:2048 -sha256 -keyout twitter32.key -out twitter32.csr
openssl req -newkey rsa:2048 -sha256 -keyout zenith32.key -out zenith32.csr
Generating a Certificate for www.twitter.com
Since the attacker has modalCA’s private keys, he goes on to create a fake certificate that is signed by ModalCA. The attacker will need ModalCA’s public certificate. He can easily obtain it from any repository.
openssl ca -policy policy_anything \
-md sha256 -days 3650 \
-in twitter32.csr -out twitter32.crt -batch \
-cert modalCA.crt -keyfile modalCA.key
Generating a Certificate for www.zenithbank.com
Since the attacker has modalCA’s private keys, he goes on to create a fake certificate that is signed by ModalCA. The attacker will need ModalCA’s public certificate. He can easily obtain it from any repository.
openssl ca -policy policy_anything \
-md sha256 -days 3650 \
-in zenith32.csr -out zenith32.crt -batch \
-cert modalCA.crt -keyfile modalCA.key
Applying the fake certificates to the malicious websites
The zenith32_apache_ssl.conf file will be modified:
<VirtualHost *:443>
DocumentRoot /var/www/zenith32
ServerName www.zenithbank.com
DirectoryIndex index.html
SSLEngine On
SSLCertificateFile /certs/zenith32.crt
SSLCertificateKeyFile /certs/zenith32.key
</VirtualHost>
The twitter32_apache_ssl.conf file will be modified:
<VirtualHost *:443>
DocumentRoot /var/www/twitter32
ServerName www.twitter.com
DirectoryIndex index.html
SSLEngine On
SSLCertificateFile /certs/twitter32.crt
SSLCertificateKeyFile /certs/twitter32.key
</VirtualHost>
Finally, we can restart the Apache server and provide the password to unlock the twitter32 and zenith32 sites’ private keys when prompted.
service apache2 restart
Visiting the websites
Once everything is set up properly, we can browse the https websites.
First of all, we visit https://www.twitter.com. We are no longer greeted with a warning from the Firefox browser about a potential security risk.
Next, we visit https://www.zenithbank.com. We are also no longer greeted with a warning from the Firefox browser about a potential security risk.
Notes
- It is extremely difficult to compromise a CA and steal its private keys.
- Even if the private keys are stolen, a passphrase used to encrypt it ensures that attackers cannot make use of it immediately
- The stronger the passphrase, the more unlikely an attacker would crack the passphrase.
Thanks for reading.