Securing your website with SSL/TLS encryption is crucial in today’s digital landscape. HTTPS not only ensures data privacy and integrity but also builds trust among your users. If you’re running an Apache web server on Linux, configuring SSL/HTTPS is a fundamental step towards safeguarding your online presence.

In this comprehensive guide, we’ll walk you through the process of setting up SSL/HTTPS for your Apache server on a Linux-based system.

STEP 1: Install OpenSSL

If you are installing Apache from your distribution’s package manager, OpenSSL may be installed automatically as a dependency. However, if you need to install OpenSSL separately or want to ensure you have the latest version, you can do so without affecting your existing Apache configuration.

For Debian/Ubuntu-based systems

Here is how to install OpenSSL on Debian-based systems like Ubuntu:

sudo apt update
sudo apt install openssl

For CentOS/RHEL-based systems

If you’re running CentOS or RHEL-based Linux systems, you can use the following commands to install OpenSSL

sudo yum install openssl

OpenSSL provides the cryptographic functions that mod_ssl relies on for secure communication. It’s common for both Apache and other applications to use OpenSSL as their cryptographic library.

Step 2: Enable Apache SSL Module

The Apache SSL module, often referred to as mod_ssl, is an Apache module that provides support for the SSL (Secure Sockets Layer) and TLS (Transport Layer Security) protocols. It enables Apache to serve web pages over HTTPS (HTTP Secure), which is the secure version of HTTP.

The Apache SSL module (mod_ssl) is not always enabled by default when you install the Apache web server. The default configuration may include other modules for basic HTTP support, but SSL/TLS support is often provided as a separate module.

To enable mod_ssl, you typically need to use the appropriate command to enable the module, which may vary depending on your Linux distribution. For example:

• On Debian/Ubuntu-based systems:

  sudo a2enmod ssl

• On CentOS/RHEL-based systems:

  sudo yum install mod_ssl

After enabling the module, you may need to restart the Apache service for the changes to take effect:

sudo systemctl restart apache2   # For systemd-based systems

or

sudo service apache2 restart     # For non-systemd systems

Step 3: Generate SSL/TLS Certificates

In this guide, we’re going to generate free self-signed certificates for testing purposes using the OpenSSL protocol. Run the following command on your terminal:

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/apache-selfsigned.key -out /etc/ssl/certs/apache-selfsigned.crt

During the process, you’ll be prompted to provide information about your organization. Here is a sample output after running the above command:

$ sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/apache-selfsigned.key -out /etc/ssl/certs/apache-selfsigned.crt
Generating a RSA private key
............+++++
.............................................................................................................................................................................................................................+++++
writing new private key to '/etc/ssl/private/apache-selfsigned.key'
-----
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]:US
State or Province Name (full name) [Some-State]:New York
Locality Name (eg, city) []:New York City
Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Organization
Organizational Unit Name (eg, section) []:IT Department
Common Name (e.g. server FQDN or YOUR name) []:example.com
Email Address []:admin@example.com

Generating SSL for Multiple Domain aliases (OPTIONAL)

When creating a self-signed certificate with OpenSSL, you typically include only a single Common Name (CN) in the certificate. If you want to include multiple domain aliases in the Subject Alternative Name (SAN) extension of the certificate, you can modify the OpenSSL command accordingly.

Here’s an example of how to create a self-signed certificate with multiple domain aliases using the -subj option to specify the subject and the SAN extension:

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
  -keyout /etc/ssl/private/apache-selfsigned.key \
  -out /etc/ssl/certs/apache-selfsigned.crt \
  -subj "/C=US/ST=New York/L=New York City/O=My Organization/OU=IT Department/CN=example.com" \
  -addext "subjectAltName=DNS:example.com,DNS:www.example.com,DNS:alias1.example.com,DNS:alias2.example.com" 

In this example:

• The -subj option in OpenSSL to generate a self-signed SSL/TLS certificate. It represents the Distinguished Name (DN) fields for the certificate’s subject, including the country (C), state or province (ST), locality or city (L), organization (O), organizational unit (OU), and common name (CN). In this specific example, the certificate is configured with a subject for an organization based in the United States, specifically in New York City, within the IT Department of the specified organization, and the common name is set to “example.com.” This information is embedded in the certificate as part of its identification details.

-subj "/C=US/ST=New York/L=New York City/O=My Organization/OU=IT Department/CN=example.com"

• The -addext option in OpenSSL, is used to specify Subject Alternative Names (SAN) for a certificate, extending its capabilities beyond the primary common name (CN). In this example, the Subject Alternative Name extension is being added with multiple DNS entries, including “example.com,” “www.example.com,” and additional aliases like “alias1.example.com” and “alias2.example.com.” SAN extensions are particularly useful for securing multiple domain names or subdomains with a single SSL/TLS certificate. This allows the certificate to be valid for various domain aliases, providing flexibility in securing diverse web applications under a unified certificate.

-addext "subjectAltName=DNS:example.com,DNS:www.example.com,DNS:alias1.example.com,DNS:alias2.example.com" 

Once the certificates are generated, secure the private key:

sudo chmod 600 /etc/ssl/private/apache-selfsigned.key

Step 4: Configure Apache for SSL

Now, it’s time to configure Apache to use SSL. Create a new configuration file or edit the default SSL configuration.

sudo nano /etc/apache2/sites-available/default-ssl.conf

Add the following lines to the configuration file:

<VirtualHost *:80>
  ServerName example.com
  ServerAlias www.example.com
  DocumentRoot /var/www/html/example.com
</VirtualHost>

You will have to replace example.com with your own domain name you want to use.

Finally, you have to add the SSL directives, below the ServerAlias directive:

SSLEngine on
SSLCertificateFile /etc/ssl/certs/apache-selfsigned.crt
SSLCertificateKeyFile /etc/ssl/private/apache-selfsigned.key

The default directory path of SSL in Linux is /etc/ssl. This directory contains the following subdirectories:

• certs: This subdirectory contains the digital certificates used by SSL/TLS services.
• private: This subdirectory contains the private keys used by SSL/TLS services.
• crl: This subdirectory contains certificate revocation lists (CRLs). A CRL is a list of digital certificates that have been revoked by a CA.
• dhparam: This subdirectory contains Diffie-Hellman parameters. These parameters are used to generate ephemeral keys for SSL/TLS sessions.

Now, the complete SSL Virtual host file setup should look like below:

<VirtualHost _default_:443>
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html

    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/apache-selfsigned.crt
    SSLCertificateKeyFile /etc/ssl/private/apache-selfsigned.key

    # ... (other SSL-related configurations)

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

This configuration will tell Apache to listen on port 443 for connections to the domain example.com and its alias www.example.com. It will also enable SSL/TLS and specify the paths to the digital certificate and private key files.

Create HTTPS Redirection

To redirect all versions of your domain to HTTPS, you can use Apache’s mod_rewrite module. You can add a rewrite rule to your Apache configuration that redirects all HTTP traffic to the HTTPS version of your site.

Open your VirtualHost file, default-ssl.conf:

sudo nano /etc/apache2/sites-available/default-ssl.conf

In your Virtual Host file, you will need to add the directory block with the RewriteEngine directive:

<Directory /var/www/html>
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted

        # Redirect HTTP to HTTPS
        RewriteEngine On
        RewriteCond %{HTTPS} off
        RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,NE,R=301]
    </Directory>

Now, the full configuration in the Virtual Host file will look as seen below:

<VirtualHost _default_:443>
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html

    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/apache-selfsigned.crt
    SSLCertificateKeyFile /etc/ssl/private/apache-selfsigned.key

    # ... (other SSL-related configurations)

    <Directory /var/www/html>
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted

        # Redirect HTTP to HTTPS
        RewriteEngine On
        RewriteCond %{HTTPS} off
        RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,NE,R=301]
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Here’s what the added section does:

• The <Directory> block allows the use of the RewriteEngine and other directives within the specified directory.
• The RewriteEngine On line activates the mod_rewrite engine.
• RewriteCond %{HTTPS} off checks if the connection is not using HTTPS.
• RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,NE,R=301] redirects to the same URL using HTTPS. The [L,NE,R=301] flags indicate that it’s the last rule, no escaping should be performed in the substitution, and it’s a permanent (301) redirect.

Make sure to replace /var/www/html with the actual path to your document root.

Step 5: Enable the Virtual Host configuration file

The following commands are used to enable the SSL/TLS module and default SSL/TLS virtual host, respectively, in Apache on Linux.

sudo a2enmod ssl
sudo a2ensite default-ssl.conf

The sudo a2enmod command enables a module in Apache. The ssl module is responsible for handling SSL/TLS connections.

The a2ensite command enables a virtual host in Apache. The default-ssl.conf file contains the configuration for the default SSL/TLS virtual host. This virtual host will be used to serve HTTPS traffic to all websites and web applications hosted on the Apache server.

Once you have made the necessary changes to your Apache configuration file, you need to restart Apache for the changes to take effect.

• On Ubuntu and Debian, you can use the following command:

sudo systemctl restart apache2

• On CentOS and RHEL, you can use the following command:

sudo systemctl restart httpd

Once Apache has restarted, your website or web application will be accessible over HTTPS.

Step 6: Update Firewall Settings (Optional)

If you’re using a firewall (like UFW), allow HTTPS traffic:

sudo ufw allow https

Step 7: Test Your SSL Configuration

Open your web browser and visit your domain using https://. You should see a secure connection with a padlock icon. Additionally, you can use online SSL testing tools like SSL Labs to check your SSL configuration for potential vulnerabilities.

Congratulations! You’ve successfully configured SSL/HTTPS for your Apache server on Linux. Your website is now encrypted, ensuring secure communication between your server and your visitors’ browsers. Remember to keep your SSL certificates up-to-date and periodically check your server’s security settings to maintain a safe online environment for your users.

Do SSL Certificates generated by OpenSSL expire?

OpenSSL itself doesn’t have an “expiry period” in the same way SSL/TLS certificates do. OpenSSL is a cryptographic library that provides tools and libraries to implement the SSL/TLS protocols, among other cryptographic functions. The expiration period is associated with SSL/TLS certificates, not with the OpenSSL library.

SSL/TLS certificates, including those generated using OpenSSL, have a specified validity period, typically defined during the certificate creation. The validity period is set by the Certificate Authority (CA) or the entity that issues the certificate. The common validity period is one year, but it can vary depending on the CA’s policies or the specific requirements of the certificate requester.

When you generate a self-signed certificate using OpenSSL, you can specify the validity period with the -days option. For example:

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout private.key -out certificate.crt

In this example, the -days 365 option sets the certificate validity period to 365 days (1 year). You can adjust the number of days based on your security policy and requirements.

On the other hand, for certificates obtained from a CA like Let’s Encrypt, the default validity period is often 90 days. Automated renewal processes, such as those provided by Certbot, are commonly used to renew certificates before they expire, ensuring continuous secure communication.