The Recommendation for Always-on SSL: Encrypting Your Website with Let’s Encrypt

SSL stands for "Secure Sockets Layer" and is a term generally used to refer to data encryption.
Currently, the SSL specification itself has become obsolete, and in reality, TLS (Transport Layer Security) is used in most cases. However, because the general recognition of "encryption = SSL" has spread so widely, it is still frequently referred to or written as "SSL implementation" rather than "TLS implementation."

It can be slightly confusing since there is a gap between general terminology and the actual technology name in use, but currently, the newest encryption standard is TLS 1.2.
Technically, older SSL specifications (SSL 1.0, SSL 2.0, SSL 3.0) are outdated and have confirmed vulnerabilities, meaning they are fundamentally unsupported by modern major web browsers today.
If you implement encryption using an older standard, browsers will issue a warning and flag your site as insecure.

"Implementing SSL" refers to encrypting the data exchanged between the server and the user when browsing a website.
By encrypting this communication, the site is protected against tampering from malicious users. Even in the unlikely event that the data is intercepted, it remains encrypted and unreadable, safely protecting the information by preventing anyone from correctly interpreting it.

Let’s Encrypt is a project launched to promote the widespread adoption of HTTPS communication (encrypted communication utilizing the SSL/TLS protocols).
It is operated by the Internet Security Research Group (ISRG), a US public benefit corporation whose mission is to reduce barriers to secure communication over the Internet.
Since the main goal is widespread adoption, anyone who owns a domain name can use it completely free of charge. Furthermore, because the project aims to automate and simplify renewals as much as possible, you can easily implement it by running just a few lines of commands after installation.

Reference Site:
Let’s Encrypt

If you are using a dedicated server, VPS, or cloud platform, you can set up and use Let’s Encrypt directly inside the server environment.
Even on some shared servers, installation may be supported, or it may be provided as a built-in free original SSL service.
In this guide, we will proceed with the setup using CentOS 7 and Nginx. (It can also be implemented using Apache.)
We will proceed assuming that the basic Nginx configuration is already completed and a website is currently up and running over HTTP.
*This setup assumes that you have already acquired an original domain name.

We will be using Git for the installation.
If you do not have Git installed, let's install it first.
Although it may not be the absolute latest version, you can install it easily using the yum command, so please use this if it is not yet installed.

$ sudo yum install git

Install Let’s Encrypt.

$ git clone https://github.com/letsencrypt/letsencrypt.git

Navigate to the installation directory.

$ cd letsencrypt

You can issue the certificate using the following command:

$ ./letsencrypt-auto certonly --webroot --webroot-path [Document Root Path] -d [Domain Name]

For example, if the domain's root directory is boelexample.com and the domain name is boelexample.com:

$ ./letsencrypt-auto certonly --webroot --webroot-path ~/boelexample.com -d boelexample.com

Using this command allows you to execute the process without stopping your web server.
Once completed, a .well-known directory will be generated in the root directory. You can simply ignore this.
To enhance security, generate and configure a Diffie-Hellman parameter.

$ sudo openssl dhparam -out /etc/ssl/private/dhparam.pem 2048

Once the certificate installation is complete, proceed with the Nginx configuration.
The minimum required settings are as follows:

server {
listen 80;
server_name boelexample.com;
# To enforce HTTPS communication at all times, configure a redirect for HTTP requests
rewrite ^ https://$server_name$request_uri? permanent;
}

server{
listen 443 ssl;
server_name boelexample.com;
ssl_certificate /etc/letsencrypt/live/boelexample.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/boelexample.com/privkey.pem;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets on;

ssl_dhparam /etc/ssl/private/dhparam.pem;
# Specifying protocols (Allow only TLS and disallow SSL)
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
# Specifying cipher suites
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
ssl_prefer_server_ciphers on;

# Specifying the root directory (No need to change from the root directory currently set for HTTP)
root   /home/user/boelexample.com;
}

After completing the configuration, reload Nginx.

$ sudo nginx -t
$ sudo systemctl reload nginx

Let's try accessing the configured domain page in a web browser.
This completes the setup.

Reference Sites:
Easily Setting Up an HTTPS Server with Let's Encrypt
Configuring Nginx to Disable SSLv3
Detailed Meanings of SSL Settings in Nginx

Once you finish setting up the SSL environment and view your website, you might sometimes encounter warnings.
In such cases, not only will browser warnings appear, but the website may also fail to display correctly.
This often happens when files loaded on the website—especially external files from a CDN or similar source—are not configured appropriately.
Here is a summary of common mistakes to watch out for:

Loading JS or CSS files using an absolute path starting with http://
→ Change the files loaded from within the server to relative paths, or to absolute paths starting with https://.

Specifying the src attribute of images using an absolute path starting with http://
→ Just like with JS and CSS, change the file paths to relative paths or absolute paths starting with https://.

Specifying file retrieval within CSS using an absolute path starting with http://
→ This is easily overlooked, but if you load Web fonts, background-image assets, or similar resources within your CSS using absolute paths, the same warning will appear. Switch them to relative paths or paths starting with https://.

SSL certificates come in different validation categories. There are three types: DV, OV, and EV.
If your goal is simply to secure your own website with SSL, DV (Domain Validation) is perfectly sufficient.
OV and EV certificates involve proving the legal and physical existence of the operating organization (company) alongside data encryption.
These levels serve purely to demonstrate to users that the website is trustworthy and credible; they do not indicate a difference in encryption strength.
It is important to note that this should not be interpreted as DV having weak encryption and EV having strong encryption.
However, depending on the Certificate Authority, encryption strengths may occasionally be structured around these validation levels.

This is Domain Validation. It is a certificate that can be issued to anyone who owns a domain, and Let’s Encrypt falls into this category.
It can be issued easily, for free, or at a very low cost.
Because anyone with a domain can obtain it, it cannot verify the actual existence of a business. While it achieves encrypted communication, it cannot provide solid verification regarding the website's organizational reliability.
(It proves that the domain itself is verified, but since the actual individual, group, or organization running the domain is not verified, risks like spoofing still exist.)

This is Organization Validation. It proves the legal existence of a company by verifying its identity over the phone.
Since the existence of the corporation is confirmed via means outside the Internet, obtaining this validation allows you to prove to users that the corporate site is authentic.
Because the verification is conducted with a representative over the phone, operators of fraudulent phishing sites cannot get a certificate issued even if they apply.
Additionally, these certificates cannot be issued by individuals.

This is a much stricter version of the OV corporate validation. Undergoing rigorous auditing based on a unified global standard, it allows an organization to demonstrate with the highest level of reliability that it is not fraudulent.
When an EV certificate is implemented, the company name is displayed in the browser's address bar.

Reference Site:
Let's Re-learn: What is an SSL Server Certificate? (Part 2)

We have covered the basics of Let’s Encrypt and SSL.
Depending on the browser, the evaluation metric has shifted toward flagging non-SSL pages as insecure. In the future, building all websites with encryption may become the standard requirement.
In the past, challenges regarding setup effort, cost, and technical barriers left a high-threshold impression in many ways. However, Let’s Encrypt has resolved these hurdles and significantly lowered the barrier to entry.
Why not take this opportunity to implement SSL, which has become far more accessible than ever before?