How to set up HTTPS for a web server in Kali Linux

Contents

1. Web server with HTTPS in Kali Linux

2. How to set up an HTTPS test environment in Kali Linux

2.1 How to enable the SSL module for Apache

2.2 Setting up hostname to IP address resolution

2.3 Creating a Certificate Authority (CA)

2.4 Creating a self-signed (self-issued) website certificate. How to create valid certificates for IP and IPv6

2.5 Saving certificates to the operating system for use by the web server

2.6 Configuring Apache to work with SSL certificates

3. How to add a Certificate Authority to trusted ones

3.1 How to add a CA to trusted ones for web browsers

3.2 How to add CA to trusted for console utilities

4. HTTPS for subdomains and IP addresses

5. How to set up HTTPS in Apache on a non-standard port

6. How to set up virtual hosts with different names on HTTPS in Apache

Conclusion

1. Web server with HTTPS in Kali Linux

Kali Linux comes with a pre-installed web server that can be used as a test environment or for pentesting tasks (for example, as a web server from which a payload will be requested to a vulnerable computer).

Some issues of starting and working with an HTTP server in Kali Linux have already been discussed on the pages of Miloserdov.Org, for example:

But when I needed to set up a test environment to work with HTTPS (including on different ports – for testing traffic analyzers and other things), a gap was discovered. This instruction is intended to fill it.

In this tutorial we will cover:

1) How to add Apache virtual host with HTTPS support in Kali Linux

2) How to create self-signed certificates valid for a domain, subdomains.

3) How to create self-signed certificates for IP and IPv6 addresses

4) What are the limitations of self-signed certificates and how to add a self-signed certificate to trusted ones in Kali Linux

5) How to configure HTTPS to work in Apache on non-standard ports in Kali Linux

In my opinion, this is quite interesting – let's get started!

2. How to set up an HTTPS test environment in Kali Linux

The algorithm of actions is as follows:

  1. Enable the Apache SSL module
  2. Generate a self-issued SSL certificate
  3. Create an Apache virtual host and configure it to work with an SSL certificate for HTTPS
  4. Optionally, adding the certificate of the local Certification Authority (CA) to trusted ones – so that applications begin to trust the locally signed certificate.

We will need the openssl package – most likely, it is already on your system, but in case you have an extra minimal build, you can install this package with the following command: 

sudo apt install openssl

We will also need the Apache web server – by default in Kali Linux it is already installed (although it is not added to autostart).

That is, everything you need is already in Kali Linux – you just need to run a few commands to generate keys and configure the web server.

To check if the server is working, start the service: 

sudo systemctl start apache2.service

Open the address http://localhost/ in a web browser – you should see the default Apache page in Debian.

2.1 How to enable the SSL module for Apache

Let's start by enabling the SSL module for Apache. This is done with the command: 

sudo a2enmod ssl

For the changes to take effect, restart the apache2 service: 

sudo systemctl restart apache2.service

The ss command will show that port 443 is already being listened to by the apache2 process: 

sudo ss -tulpn

But, in fact, nothing is working yet. You can verify this by opening https://localhost/ or running curl with the -k switch (the long version of this option is --insecure): 

curl 'https://localhost/' -k

We started with this step to make sure that the SSL module is successfully enabled and all the conditions necessary for its operation are met.

2.2 Setting up hostname to IP address resolution

For real domain names, their IP address is found out by programs by making requests to the DNS server. We will not (now) set up a full-fledged DNS, we will just add an entry to the /etc/hosts file.

I will use hackware.local as a domain name (address of the local website). You can choose any other name – from one or more words separated by a dot. To point this name to the web server, add the /etc/hosts file 

sudo gedit /etc/hosts

the following line (replace hackware.local with your chosen domain name): 

127.0.0.1	hackware.local

You can then connect to the web server in your web browser using the domain name http://hackware.local (but only via HTTP for now).

In fact, you can skip setting up the /etc/hosts file and still use the hostname, because if you choose a name like: 

ANYTHING.localhost

For example: 

hackware.localhost

Then the operating system (this works on both Linux and Windows) will forward requests to this host to localhost.

You can click the following link and if you have Apache running, it will open your local web server: http://hackware.localhost/

2.3 Creating a Certificate Authority (CA)

First, we will create the Certificate Authority (CA) keys. This only needs to be done once. Despite the grandiose name “Certificate Authority”, we will create a key and a certificate (a pair of private and public keys) with two commands – that's all.

These keys can be created anywhere, for example, I created a folder myCA in which they will be stored: 

mkdir myCA
cd myCA

Now create the private key of the Certificate Authority and the self-signed certificate with the following commands: 

openssl genpkey -algorithm RSA -out rootCA.key
openssl req -x509 -new -noenc -key rootCA.key -sha256 -days 1024 -out rootCA.crt

During the second command, you will be asked for various information – it doesn't matter what you enter, it doesn't affect anything for our testing purposes. You can simply press Enter on all the requests.

The rootCA.crt file is a certificate containing a public key. This file is not secret and we will need it to add our Certification Authority (CA) to trusted ones, so that the operating system trusts signed certificates.

The rootCA.key file should be kept secret – with its help you can create certificates that will be perceived by your operating system as signed by a trusted Certification Authority.

2.4 Creating a self-signed (self-issued) website certificate. How to create valid certificates for IP and IPv6

A small digression about the term “Self-Signed Certificate”. There is confusion with the use of this term. There is a common misconception on the Internet that a self-signed certificate is one that you created yourself (even if it is signed by your micro CA).

The terms “self-signed” and “self-issued” are occasionally used interchangeably and “self-signed certificate” is sometimes even incorrectly used to indicate a certificate issued by a private (not publicly trusted) CA.

RFC 5280 defines self-signed certificates as “self-issued certificates where the digital signature may be verified by the public key bound into the certificate” whereas a self-issued certificate is a certificate “in which the issuer and subject are the same entity”. While in the strict sense the RFC makes this definition only for CA certificates, there is no reason to also adopt that definition for end-entity certificates (last two paragraphs from here: https://en.wikipedia.org/wiki/Self-signed_certificate).

In general, our site's certificate will be self-issued. In the OpenSSL documentation terminology (e.g. here man openssl-x509), this certificate will be signed by our “micro CA”.

However, we have already dealt with a self-signed certificate – the rootCA.crt file created in the previous section is a self-signed certificate in the strict sense of the word. And the request to create a certificate will also be self-signed. But ultimately, our certificate will be signed by our “micro CA”, which we have already created, i.e. it will not be self-signed.

Since the expression “self-signed certificate” is quite well-established and is used more often than the more appropriate “self-issued certificate”, I will also sometimes say “self-signed certificate”, although in the strict cryptographic sense this is incorrect.

And one more digression: if you are curious about the relationship between “certificate” and “public key”, they are not exactly the same thing. A certificate (or rather a “Public Key Certificate”) contains a public key and additional information. A public key certificate verifies that a public key belongs to a certain entity, such as a user. A public key certificate contains the name of the entity, the public key, the name of the certification authority, the policy for using the private key corresponding to the certified public key, and other parameters, certified by the signature of the certification authority.

See also: https://en.wikipedia.org/wiki/Public_key_certificate

That is, a certificate can perform the functions of a public key and at the same time it contains confirmation that this public key was received from the subject indicated in the certificate as its owner. But we have digressed from the topic – let's get back to our web server.

With the following commands we will create a private key and a website certificate. The private key is generated directly. As for the certificate, a certificate signing request will be created first. (For real websites, this is the request that is sent to one of the trusted Certification Authorities). And based on this request, a certificate signed by our micro CA will ultimately be created.

In these commands you can change the key names (for example, replace hackware.local with your domain name) – since the key (file) names do not affect anything – you can use any: 

openssl genpkey -algorithm RSA -out hackware.local.key
openssl req -new -key hackware.local.key -out hackware.local.csr

After executing the second command, you will again be asked for various information – as before, almost all of them can be left blank, with the exception of one field: 

Common Name (e.g. server FQDN or YOUR name) []:

In this field, specify your local domain, for example: 

hackware.local

Also think up and remember a password to enter in the next field (you can skip it): 

A challenge password []:

Create a file extraoptions.ext with the following contents (instead of hackware.local, specify your domain): 

subjectAltName = DNS:*.hackware.local, DNS:hackware.local

Please note that the domain is specified twice – with and without an asterisk. This is done so that the certificate works for both the main domain and all its subdomains.

In fact, you can also specify IP addresses (including IPv6) – if you do this, the certificate will also be valid for these IP addresses. An example of an extraoptions.ext file with IP addresses: 

subjectAltName = DNS:*.hackware.local, DNS:hackware.local, IP:192.168.1.37, IP:2001:fb1:139:df02:bcb6:3aa7:c515:55af

To find out the IP addresses of your Linux computer, use the following command: 

ip a

Note: if you have not configured a static IP address, your IP addresses will most likely change after rebooting your computer.

The last command is to sign the certificate: 

openssl x509 -req -in hackware.local.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out hackware.local.crt -days 500 -sha256 -extfile extraoptions.ext

As a result, three new files were created: 

hackware.local.crt
hackware.local.csr
hackware.local.key

The hackware.local.csr file (this is a certificate signing request) is no longer needed and you can delete it.

2.5 Saving certificates to the operating system for use by the web server

Copy (or move) the created private key and certificate: 

sudo cp hackware.local.key /etc/ssl/private/
sudo cp hackware.local.crt /etc/ssl/certs/

2.6 Configuring Apache to work with SSL certificates

In the /etc/apache2/sites-available/ directory, create a file with the .conf extension, for example: 

sudo gedit /etc/apache2/sites-available/hackware-ssl.conf

And copy the following contents into it: 

<VirtualHost *:443>
	DocumentRoot "/var/www/html/"
	ServerName hackware.local
	ServerAdmin whatever@gmail.com
	LogLevel error
	# LogLevel info ssl:warn # You may like this instead of the previous one
	ErrorLog "/var/log/apache2/hackware.local-ssl-error_log"
	CustomLog "/var/log/apache2/hackware.local-ssl-access_log" combined
	SSLEngine on
	SSLCertificateFile "/etc/ssl/certs/hackware.local.crt"
	SSLCertificateKeyFile "/etc/ssl/private/hackware.local.key"

	<Directory /> 
		Options +Indexes +FollowSymLinks +ExecCGI
		AllowOverride All
	</Directory>
	
	<FilesMatch "\.(?:cgi|shtml|phtml|php)$">
		SSLOptions +StdEnvVars
	</FilesMatch>

	<Directory /usr/lib/cgi-bin>
		SSLOptions +StdEnvVars
	</Directory>
</VirtualHost>

In this configuration, pay special attention to the settings of the following directives:

  • ServerName – the chosen domain name for the local site
  • SSLCertificateFile and SSLCertificateKeyFile – paths to the certificate and private key. If you chose other names for your keys, then change them here.

Save and close the file.

Now enable the new virtual host (note that the name of the configuration file may be different – this is the same file that you created in the /etc/apache2/sites-available/ directory a little earlier): 

sudo a2ensite hackware-ssl.conf

And reload the apache2 service settings: 

sudo systemctl reload apache2

To check that the new virtual host was really added, you can run the following command: 

apachectl -t -D DUMP_VHOSTS

Now you can use the HTTPS protocol to connect to the web server: https://hackware.local/

But not everything is so good – the web browser does not trust the self-issued certificate. To fix this, you need to add the Certification Authority created above in this instruction to the list of trusted ones.

3. How to add a Certificate Authority to trusted ones

Now, you are probably wondering how to make a web browser trust self-issued SSL certificates?

The problem with our certificate is that it is not signed by a trusted source.

It is important to understand the difference between a self-issued certificate and a certificate signed by an trusted CA. Technically, these certificates are the same thing (trusted CA-signed ones may have additional information, but this does not change the essence, since locally signed ones can also specify additional data).

You can create a certificate for any site (for example, for google.com), but programs will not trust it, since it is not signed by a trusted CA – this is how SSL and HTTPS work.

To make sure that any web browser trusts your certificate, you can choose one of two options:

1) buy a certificate signed by a trusted CA

2) get a free 3-month trial certificate signed by a trusted CA, and then renew it every 3 months

If you choose any of these options, you will need to prove ownership of the domain for which you are receiving the certificate. That is, these options are intended for website owners. Since we created and signed our certificate locally, and even the domain name is not real (with a fictitious top-level domain), these options are not suitable for our situation.

However, for testing purposes, we can approach it from the other side and add our own Certification Authority to the trusted ones. This step will automatically lead to all certificates signed by it being recognized as trusted (secure).

It is clear that locally signed certificates will be recognized as trusted only on those computers that have accepted our CA certificate (most likely, only your computer).

The operating system has a central repository of certificates of trusted Certification Authorities, and we can add our micro CA there. The catch is that many applications (including web browsers) do not use this central repository.

Next, we will show how to make a local CA trusted for web browsers and console utilities.

3.1 How to add a CA to trusted ones for web browsers

To make web browsers trust all certificates created using a local Certification Authority, you need to do the following.

1) Create a file CAtoCert9.sh and save the following content to it: 

#!/bin/bash
 
certfile="/home/mial/myCA/rootCA.crt"
certname="HackWare CA"
 
for certDB in $(find ~/ -name "cert9.db")
do
    certdir=$(dirname ${certDB});
    certutil -A -n "${certname}" -t "TCu,Cu,Tu" -i ${certfile} -d sql:${certdir}
done

In this file, change the certfile value to the path to your certificate file and the certname value to the name of your certificate (you can choose any – you will need this name if you want to delete the certificate), save and close the file.

2) Then run it like this: 

bash CAtoCert9.sh

Note that we have trusted the CA certificate, not the site certificate.

If you want to remove your CA from the trusted list, create a file CAfromCert9.sh and copy the following into it: 

#!/bin/bash

certname="HackWare CA"

for certDB in $(find ~/ -name "cert9.db")
do
	certdir=$(dirname ${certDB});    
	certutil -D -d sql:${certdir} -n "${certname}"
done

In this file, change the certname value to the name of your certificate, save and close the file.

Then run it as follows: 

bash CAfromCert9.sh

Let's check the local web server page via HTTPS in different web browsers. In Firefox, the connection is marked as secure:

In Chromium, the connection is also marked as secure:

3.2 How to add CA to trusted for console utilities

If you have added certificates to trusted in web browsers, you may have noticed that console utilities such as wget and curl do not use these settings. For wget and curl, you need to add the Certificate Authority to trusted in Linux as follows.

Note: Please note that in the commands below, you need to use the Certificate Authority (CA) certificate, not the site certificate.

To add your root CA to trusted CAs in Debian, Kali Linux, Linux Mint, Ubuntu and their derivatives:

1. Check if the /usr/local/share/ca-certificates directory exists: 

ls -l /usr/local/share/ca-certificates

If it does not exist, create it: 

sudo mkdir /usr/local/share/ca-certificates

2. Copy your certificate with a command like this (replace rootCA.crt with the path and name of your CA certificate): 

sudo cp rootCA.crt /usr/local/share/ca-certificates/

3. Run the following command to update the system-wide list: 

sudo update-ca-certificates

Example output: 

Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
 
Adding debian:rootCA.pem
done.
done.

Let's check if our CA certificate is among the trusted ones: 

awk -v cmd='openssl x509 -noout -subject' ' /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt | grep -i HackWare

Certificate successfully found:

If you want to remove the certificate installed this way, run the following commands: 

sudo rm /usr/local/share/ca-certificates/rootCA.crt
sudo update-ca-certificates -f

4. HTTPS for subdomains and IP addresses

If you have already added IP addresses to the extraoptions.ext file, as I did in the example above, now even connections by IP addresses can use HTTPS and are marked as secure: https://192.168.1.37/.

In Firefox:

In Chromium:

The IPv6 address also works via HTTPS protocol and has a secure connection status: https://[2001:fb1:139:df02:bcb6:3aa7:c515:55af]/

In Firefox:

In Chromium:

See also:

It remains to check the subdomain. We need to add one more entry to the /etc/hosts file: 

sudo gedit /etc/hosts

For example, I will add the forum.hackware.local subdomain there: 

127.0.0.1	forum.hackware.local

Let's check: https://forum.hackware.local/

Everything is already working, even though we did not create a virtual host for the subdomain on the web server. In such cases, when the web server does not have a host that meets the conditions, the default host settings are used. But, if desired, the web server can be configured so that if the requested host is not found, the user will be shown an error.

We already know how to configure Apache virtual hosts for HTTPS, and for the subdomain we do not even need new certificates. So let's do it.

So, let's create a new virtual host folder: 

sudo mkdir /var/www/forum

Let's create a web page there 

sudo gedit /var/www/forum/index.html

For example, with the following content: 

<!DOCTYPE html>
<html lang="en-US">
<head>
	<title>Forum</title>
</head>
<body>
	<p>This is a forum, if it says so.</p>
</body>
</html>

Let's create a virtual host settings file: 

sudo gedit /etc/apache2/sites-available/forum-ssl.conf

With the following content: 

<VirtualHost *:443>
	DocumentRoot "/var/www/forum"
	ServerName forum.hackware.local
	ServerAdmin whatever@gmail.com
	LogLevel error
	# LogLevel info ssl:warn # You may like this instead of the previous one
	ErrorLog "/var/log/apache2/hackware.local-ssl-error_log"
	CustomLog "/var/log/apache2/hackware.local-ssl-access_log" combined
	SSLEngine on
	SSLCertificateFile "/etc/ssl/certs/hackware.local.crt"
	SSLCertificateKeyFile "/etc/ssl/private/hackware.local.key"

	<Directory /> 
		Options +Indexes +FollowSymLinks +ExecCGI
		AllowOverride All
	</Directory>
	
	<FilesMatch "\.(?:cgi|shtml|phtml|php)$">
		SSLOptions +StdEnvVars
	</FilesMatch>

	<Directory /usr/lib/cgi-bin>
		SSLOptions +StdEnvVars
	</Directory>
</VirtualHost>

Pay attention to the DocumentRoot and ServerName directives. The DocumentRoot directive points to the directory (folder) where the files of this host are located. And the ServerName directive contains the name of this host – the same value that the user enters in the site's address bar.

If desired, you can change the paths to the log files and other settings.

Activate the new configuration file and reload the web server settings: 

sudo a2ensite forum-ssl.conf
sudo systemctl reload apache2

Let's check: https://forum.hackware.local/

Yes, the subdomain works via the HTTPS protocol and displays files from its folder on the web server.

5. How to set up HTTPS in Apache on a non-standard port

Now that connections to the local web server have become encrypted and secure, you can play around with setting up Apache virtual hosts — for example, we can set up HTTPS not on port 443 (this is the default port for HTTPS traffic), but on any other port that is not occupied in your operating system.

For your tests, you can choose any port. In my example, I chose port 50443.

In the /etc/apache2/sites-available/ directory, create a file with the .conf extension, for example: 

sudo gedit /etc/apache2/sites-available/hackware-ssl50443.conf

And copy the following content into it: 

<VirtualHost *:50443>
	DocumentRoot "/var/www/html/"
	ServerName hackware.local
	ServerAdmin whatever@gmail.com
	LogLevel error
	# LogLevel info ssl:warn # You may like this instead of the previous one
	ErrorLog "/var/log/apache2/hackware.local-ssl-error_log"
	CustomLog "/var/log/apache2/hackware.local-ssl-access_log" combined
	SSLEngine on
	SSLCertificateFile "/etc/ssl/certs/hackware.local.crt"
	SSLCertificateKeyFile "/etc/ssl/private/hackware.local.key"

	<Directory /> 
		Options +Indexes +FollowSymLinks +ExecCGI
		AllowOverride All
	</Directory>
	
	<FilesMatch "\.(?:cgi|shtml|phtml|php)$">
		SSLOptions +StdEnvVars
	</FilesMatch>

	<Directory /usr/lib/cgi-bin>
		SSLOptions +StdEnvVars
	</Directory>
</VirtualHost>

Pay attention to the first line – VirtualHost *:50443 – as you might guess, the port of this virtual host is specified here. All other settings are left unchanged for now. Since we are using the same host name, the previously generated certificates will work for us and we will use them.

The port that we specified in the virtual host settings is a characteristic of the host: when a request is received by the web server on this port, the web server will apply the settings of the corresponding host. By the way, the web server selects the appropriate virtual host based on three parameters: 1) the host name; 2) the listening port; 3) the listening IP address. But the web server does not start listening to the ports specified in the virtual host settings automatically – this must be configured additionally. So, let's configure the ports that the Apache web server listens to. To do this, open the file /etc/apache2/ports.conf: 

sudo gedit /etc/apache2/ports.conf

There you will see something like this: 

<IfModule ssl_module>
	Listen 443
</IfModule>

<IfModule mod_gnutls.c>
	Listen 443
</IfModule>

Note: if you are wondering what mod_gnutls (Apache GnuTLS module) is, it is an alternative to ssl_module. The main difference is that ssl_module uses OpenSSL to provide HTTPS, while mod_gnutls uses GnuTLS for this purpose. At the moment, the functionality is similar at a basic level, and more advanced cases are beyond the scope of this article. In this tutorial, we will use ssl_module.

So, we add a new “Listen” directive to the “IfModule ssl_module” section, it looks like this: 

<IfModule ssl_module>
	Listen 443
	Listen 50443
</IfModule>

<IfModule mod_gnutls.c>
	Listen 443
</IfModule>

Note that new ports are added by new “Listen” directives. You cannot specify multiple ports separated by commas with one “Listen” directive.

Note: in addition to the port, you can also specify an IP in “Listen”, but we will not do this setting in this instruction.

Save and close the file, restart the web server. 

sudo a2ensite hackware-ssl50443
sudo systemctl reload apache2

Now we can use HTTPS on a non-standard port: https://hackware.local:50443

6. How to set up virtual hosts with different names on HTTPS in Apache

We have our own micro Certification Authority – let's use it to the fullest!

I already said that after adding the Certificate Authority to trusted web browsers, any certificates issued by this CA are considered reliable. But what happens if we issue a certificate, for example, for google.com? Let's check.

Add another entry to the /etc/hosts file: 

sudo gedit /etc/hosts

Now we create a Google killer: 

127.0.0.1	google.com

Let's start with generating a certificate. We already have a Certification Authority, so we skip this step. We proceed straight from generating a private key and a request to sign a certificate: 

openssl genpkey -algorithm RSA -out google.com.key
openssl req -new -key google.com.key -out google.com.csr

When the request appears 

Common Name (e.g. server FQDN or YOUR name) []:

Then we specify there: 

google.com

Create a file extraoptions_google.com.ext with the following contents: 

subjectAltName = DNS:*.google.com, DNS:google.com

The last command signs the certificate: 

openssl x509 -req -in google.com.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out google.com.crt -days 500 -sha256 -extfile extraoptions_google.com.ext

Copy created private key and certificate: 

sudo cp google.com.key /etc/ssl/private/
sudo cp google.com.crt /etc/ssl/certs/

Let's create a directory for our import-substituted Google files: 

sudo mkdir /var/www/google.com

And at least one file 

sudo gedit /var/www/google.com/index.html

With approximately the following content: 

<!DOCTYPE html>
<html lang="en-US">
<head>
	<title>Google.com</title>
</head>
<body>
	<p>Any port in a storm.</p>
</body>
</html>

In the directory /etc/apache2/sites-available/ create a file with the .conf extension, for example: 

sudo gedit /etc/apache2/sites-available/google-ssl.conf

And copy the following content into it: 

<VirtualHost *:443>
	DocumentRoot "/var/www/google.com"
	ServerName google.com
	ServerAdmin whatever@gmail.com
	LogLevel error
	# LogLevel info ssl:warn # You may like this instead of the previous one
	ErrorLog "/var/log/apache2/google.com-ssl-error_log"
	CustomLog "/var/log/apache2/google.com-ssl-access_log" combined
	SSLEngine on
	SSLCertificateFile "/etc/ssl/certs/google.com.crt"
	SSLCertificateKeyFile "/etc/ssl/private/google.com.key"

	<Directory /> 
		Options +Indexes +FollowSymLinks +ExecCGI
		AllowOverride All
	</Directory>
	
	<FilesMatch "\.(?:cgi|shtml|phtml|php)$">
		SSLOptions +StdEnvVars
	</FilesMatch>

	<Directory /usr/lib/cgi-bin>
		SSLOptions +StdEnvVars
	</Directory>
</VirtualHost>

Pay attention to the following directives:

  • DocumentRoot — root folder of the site)
  • ServerName — name of the virtual host (corresponds to the domain that the user enters in the web browser line)
  • SSLCertificateFile – path to the site certificate
  • SSLCertificateKeyFile – path to the site's private key

Activate the new virtual host and reload the web server settings: 

sudo a2ensite google-ssl.conf
sudo systemctl reload apache2

Let's check: https://google.com

Now we have our own Google, which has no analogues in the world, which works on the HTTPS protocol and web browsers mark the connection to this site as secure.

Conclusion

So, we learned how to configure Apache virtual hosts that work on the HTTPS protocol.

We also learned a little about the Certification Authority and the certificates themselves. I think it is clear that you should not install questionable certificates on your system (that is, you do not need to add Certification Authorities to trusted ones if you doubt them).

A trusted Certification Authority can create certificates for any sites and applications on your computer will believe that all these certificates are genuine and their issuance was initiated by the owner of the website for which they were created (although this may be false).

Installing so-called “security certificates” from questionable sources has nothing to do with security. If a dubious Certificate Authority is added to your system, this allows the owner of the Certificate Authority to perform a man-in-the-middle attack (fully eavesdrop on traffic that you consider encrypted), but web browsers will still consider this connection encrypted and secure. Moreover, the presence or absence of HTTP Strict Transport Security (HSTS) on the website will not affect anything in this case.

Related articles:

Recommended for you:

November 1, 2024 , , , , , , , , , , , Work Environment No Comments »

Leave a Reply

Your email address will not be published. Required fields are marked *