Embrace Secure Web Communication: Wildcard HTTPS with Let's Encrypt and Nginx

Revoking Certificates for Enhanced Security

To remove SSL certificates from a server, use the following command with the name of your domain (or host):

sudo certbot revoke --cert-path /etc/letsencrypt/live/domain_name/cert.pem

After you issue the command, you won't get any notification of changes in certificates. Still, you can rerun the command, and if it says that the certificate has already been revoked, this means that the process is completed successfully.

Strengthening Web Security Measures

When you obtain or renew your certificates, check the Nginx client for further HTTPS configuration.

Exclusively Using Secure Protocols

Not all security protocols are developed the same, with some being less secure than others. For example, SSLv2 and SSLv3 certificates lag behind on security levels compared to TLS certificates. The SSL certificates are considered to have innate imperfections regarding security protocols. Thus, there was a need to replace them with better protocols. In the case of SSL, it is TLSv1.1 and TLSv1.2.

However, even with TLS certificates, it's better to use the newer certificates, even though some browsers will still require older versions.

Activating HTTP Strict Transport Security (HSTS)

Strict Transport Security protects TLS certificates by ensuring secure communication with the websites using them. So even if there are issues with configuration or implementation, HSTS will ensure sufficient security of certificates, by making any links secure. It will also notify users of attacks by turning off the click-through warning feature built into certificates.

You can switch on the HTST using the following command:

add_header Strict-Transport-Security "max-age=31536000; includeSubdomains";

Enhancing Cipher Suites for Encryption

Cipher suites' job is to evaluate how secure the communication between a web server and visitor clients is.

Below, you'll find an example created for RSA and ECDSA keys:

ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256

Eventually, the client indicates the cipher suites it uses and gives the servers options to choose cipher suites. The client puts ciphers on the server in descending order, from the most secure to the least secure. You can use the following command to turn on this feature:

ssl_prefer_server_ciphers on;

Note that this works with SSL protocols, namely SSLv3 and newer.

Implementing the Diffie-Hellman Ephemeral Algorithm

The Diffie-Hellman algorithm is a protocol that exchanges the keys between two parties to create a mutual secret that cannot be spotted outside of the two-party communication. DH is basically a way of encryption that instructs the two parties to use a public key for encryption or decryption of their exchanged data. Simply put, the secret information is mixed with public information, so it would be impossible to discern the secret information. It is a helpful method to establish the shared key between a server and a client and use that key to encrypt the data shared between them.

Static DH differs from its ephemeral algorithm because the latter generates a temporary key for every interaction without repeating it. Thus, DHE promotes long-term security since a temporary key cannot be leaked, as the data protected by it.

You can use the DHE algorithm using the following command:

sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

The output can further be used in Nginx configuration, like so:

ssl_dhparam /etc/ssl/certs/dhparam.pem;

Automatically Redirecting Unencrypted Connections

A useful way to ensure secure web communication is redirecting unencrypted HTTP connections to encrypted HTTPS. You can do this with the following command:

server {
  listen 80;
  server_name domain_name;
  return 301 https://$server_name$request_uri; 
}

With it, you're creating just a segment of HTTP so that your web server can spot it and upgrade the HTTP connection to HTTPS. So, even if the link uses "http:" it will be converted to "https:".

Integrating All Security Measures into the Configuration

Even though the Certbot client saves the Nginx configuration when using CentOS, editing the Nginx client's configuration manually will prevent the file from updating in the future. To do that, create a new Nginx file with the following command:

sudo vi /etc/nginx/conf.d/domain_name.conf

With that command, you create a separate Nginx file that spots HTTPS connections using all the security measures mentioned earlier.

To add the security measures, duplicate the following example in Nginx:

# HTTPS server
server {
    listen 443 ssl;
    server_name domain_name;
    ssl_certificate /etc/letsencrypt/live/domain_name/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/domain_name/privkey.pem;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 5m;
    ssl_protocols TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;
    ssl_dhparam /etc/ssl/certs/dhparam.pem;
    ssl_ciphers
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256;
    add_header Strict-Transport-Security "max-age=31536000; includeSubdomains";
    location / {
    root /usr/share/nginx/html;
    index index.html index.htm;
    }
}


#HTTP redirect
server {
   listen 80;
server_name domain_name;
return 301 https://$server_name$request_uri; 
}

Make sure you save the file in Nginx, and then reboot Nginx with the following command:

sudo systemctl restart nginx

You can now open your website in the web browser using the https://domain_name. If it loads, this means that the installation is successful.

If you want to check further how well the server encryption works within the browser, use a Qualys SSL Labs test. Put your domain (host) name on their website, and press the Submit button. The test will provide information about the different aspects of your server encryption.