In this article, you'll learn how to install Certbot on Ubuntu 24.04, and use it to install Let's Encrypt certificates and configure them for both Apache and Nginx to use HTTPS instead of HTTP.

Quick-Start Guide: Install Certbot on Ubuntu 24.04

If you're looking for the fastest way to install Certbot and set up Let's Encrypt on Ubuntu 24.04, here are the essential commands:

# Update packages and install Certbot
sudo apt update
sudo apt install -y certbot

# For Apache users
sudo apt install -y python3-certbot-apache
sudo certbot --apache -d example.com

# For Nginx users
sudo apt install -y python3-certbot-nginx
sudo certbot --nginx -d example.com

For detailed instructions, including manual installation and configuration options, continue reading below.

Prerequisites

• To follow this tutorial, you'll need an Ubuntu 24.04 server with sudo privileges. If you haven't noticed, we offer the most affordable and reliable Ubuntu servers in the world. Our NVMe VPS options provide lightning-fast performance for your SSL-secured websites.

Step 1: Install Certbot on Ubuntu 24.04

To install Certbot on Ubuntu 24.04, you'll first need to update your package repositories to ensure you're installing the latest version. Updating your package list refreshes your system's knowledge of available software and their versions, which is an essential first step before installing any new application:

sudo apt update

Next, use the apt command to install certbot:

sudo apt install -y certbot

The Certbot command line tool will automate the process of getting and installing a Let's Encrypt certificate that you can use with Apache and Nginx servers, valid for 90 days, with the possibility of an automated renewal.

Note

Before proceeding with certificate installation, ensure that TCP ports 80 (HTTP) and 443 (HTTPS) are open on your server's firewall. These ports are essential for the Let's Encrypt validation process - port 80 allows the initial domain verification challenge to complete successfully, while port 443 is needed for serving encrypted HTTPS traffic once your certificate is installed.

Step 2: Install a Let’s Encrypt Certificate Using Certbot

To create a Let’s Encrypt certificate with certbot on Ubuntu, you’ll use the following command structure:

sudo certbot certonly --webroot --webroot-path WEB_SERVER_ROOT_PATH -m EMAIL -d DOMAIN --agree-tos -n

Here is what each part of the preceding command means:

• certonly: (certificate only) used to just obtain the certificate without installing it anywhere.
• --webroot: An option that is used here to keep the web server running while Certbot runs, since we’re already running a local web server, and don't want to stop it during the certificate issuance process.
• --webroot-path or -w: Defines the top-level directory (“web root”) containing the files served by your webserver. Note that the web root path must be the path on which files from the domain are served. In our example, it's the web root path from which our http://www.example.com URL serves files.
• --mail or -m : The email which will be used by the certificate authority to alert you when a domain will expire.
• --domain or -d: The domain name you’ll use to access the server by.--agree-tos: Confirms our agreement to the ACME server's subscriber agreement.
• --non-interactive or -n is used to execute the command without ever asking for user input or prompts.

Now that you are familiar with the certbot options and actions, you can form and execute a certbot command to create a certificate. For example, you can use the following command, making sure to set the appropriate values for your case:

sudo certbot certonly --webroot --webroot-path /var/www/html/ -m devops@example.com -d www.example.com --agree-tos -n

Once the command is executed, the following two files will be automatically created under the respective subdirectories as follows:

• The private key: /etc/letsencrypt/live/www.example.com/privkey.pem
• The certificate: /etc/letsencrypt/live/www.example.com/fullchain.pem

Now that you have your Let's Encrypt private key file and your certificate file, you can install your certificate on your web server.

"Only Domain Names Are Supported, Not IP Addresses" Certbot Error

The "Only domain names are supported, not IP addresses" error in Certbot occurs because Let’s Encrypt does not issue SSL certificates for IP addresses. Certificates are only provided for fully qualified domain names (FQDNs). To resolve this, ensure you are using a valid domain name instead of an IP address when requesting a certificate. Register a domain if needed.

Step 3: Configuring Apache with Let's Encrypt Certificates

Now that you’ve created a Let’s Encrypt certificate, you can configure your Apache server to use it and enable HTTPS on your website.

First, you'll need to modify Apache's default configuration file to integrate your newly acquired Let's Encrypt SSL certificate. This configuration file controls how Apache handles incoming requests and determines which virtual hosts use HTTPS encryption:

sudo nano /etc/apache2/sites-enabled/000-default.conf

Make sure you set up a domain, and then replace the key and the certificate paths with the Let’s Encrypt private key file and the certificate file (the changes you have to make are highlighted in yellow in the code below):

<VirtualHost *:80>
        Define servername www.example.com
        ServerName ${SERVERNAME}
        RewriteEngine on
        RewriteRule ^/.*$ https://\${SERVERNAME}%{SCRIPT_FILENAME}?%{QUERY_STRING} [R=301]
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
<VirtualHost *:443>
        SSLEngine On
        SSLCertificateFile /etc/letsencrypt/live/www.example.com/fullchain.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/www.example.com/privkey.pem
        ServerName ${SERVERNAME}
        DocumentRoot /var/www/html
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Here, you set the SSLCertificateFile directive to the path of the Let’s Encrypt certificate file, and you set the SSLCertificateKeyFile directive to the private key’s path.
Next, test for configuration errors:

sudo apache2ctl configtest

You should receive an output that contains the text Syntax OK, which means you can safely reload Apache, otherwise, you will get a very specific description pointing out the error you have to fix.
Next, restart Apache:

sudo systemctl restart apache2

Now, reload your website in the browser. You will notice a secured padlock with a valid certificate message as you can see in the following example, which was taken from the Google Chrome browser:

With this, you now have HTTPS enabled in your Apache web server, and you can now secure your web traffic, which establishes customer trust and protects both your internal and public data.

Step 3.2: Configuring Nginx with Let's Encrypt Certificates

To configure your Let’s Encrypt certificate with your NGINX server and enable HTTPS on your website. First, edit NGINX’s default configuration file:

sudo nano /etc/nginx/sites-enabled/default

Set up your domain name. Then replace the private key and the certificate paths with the Let’s Encrypt private key file and the certificate file generated by Certbot (the changes you have to make are highlighted in yellow in the code below):

server {
   listen 80;
   listen [::]:80;
   server_name www.example.com;
   access_log off;
   location / {
         rewrite ^ https://$host$request_uri? permanent;
   }
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name www.example.com;
    root /var/www/html;
    index index.php index.html index.htm index.nginx-debian.html;
    autoindex off;
    ssl_certificate /etc/letsencrypt/live/www.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/www.example.com/privkey.pem;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!MD5;

    location ~ \.php$ {
         include snippets/fastcgi-php.conf;
         fastcgi_pass unix:/var/run/php/php-fpm.sock;
         fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
         include fastcgi_params;
    }
}

Here, you set the ssl_certificate directive to the Let’s Encrypt certificate file path you created earlier, and the ssl_certificate_key directive to the Let’s Encrypt private key file path.
With the configuration file modified, check for syntax errors in it using the following command:

sudo nginx -t

The output should let you know that the configuration file test is successful.

Now, restart NGINX:

sudo systemctl restart nginx

Reload your browser and you will notice a secured padlock with a valid certificate message.

Step 4: Verifying Your Let's Encrypt Certificate Information

In the pop-up that comes up when clicking the padlock or settings icon on the left side of the URL, click on "Certificate is secure" or "Connection is Secure" depending on your browser. This will give you detailed information on the CA certificate:

Congrats!

Your Ubuntu server's Apache or Nginx web server has become CA certified with Let's Encrypt, and you can now securely transfer data through HTTPS, and protect your online transactions, and with best security practices, you can handle paid subscriptions, eCommerce orders, memberships, or charity and online fundraising.

Installing a non-Let's-Encrypt CA Certificates

If you are looking to install a non-Let's-Encrypt CA Certificate you'll generally need to do the following:

1) Creating a Certificate Signing Request (CSR)

The CSR contains information (e.g. common name, organization, country) which the Certificate Authority (CA) will use to create your certificate. You generate it on the server where you want to install the certificate. It includes the public key that will be part of your certificate, and is signed with the corresponding private key.
Check out How to Create a Self-Signed Certificate, which describes CSR creation for self-signed certificates (which also applies to CA certificates).

2) Uploading the CSR to the Certificate Authority (CA)

Please refer to the documentation of the certificate authority of your choice, and follow their instructions to properly upload your certificate signing request, along with any additional information.

Once the CSR is uploaded, the CA replies with your final certificate ready to use.

FAQ

What are the differences between Let's Encrypt Certificates vs Paid TLS/SSL Certificates?

Although Let's Encrypt provides free SSL certificates. Paid TLS/SSL certificates often give you additional features such as extended validation and warranty. These paid TLS/SSL certificates are usually suitable for businesses needing higher trust levels. Both types of certificates encrypt data, but paid SSLs often come with better customer support and additional security features. If you have a business, it is better to use a paid certificate. To get affordable TLS/SSL certificates, check out our website.

Is Let's Encrypt safe?

Yes, Let's Encrypt is safe. It provides the same level of encryption as paid SSL certificates. It is backed by major tech companies and regularly audited for security. Automatic renewals ensure your site stays secure. However, it lacks some advanced features offered by paid certificates. For most websites, Let's Encrypt is a reliable and secure option.

What to do when Let's Encrypt Root Certificate is expiring?

Let's Encrypt's root certificate expiration is a known issue. Ensure your systems are updated to trust the new root certificate. Older devices might face connectivity issues. Regularly check for updates and ensure compatibility with new certificates. This change is a normal part of maintaining secure encryption. Proper updates will keep your site secure and trusted.

How to perform Let's Encrypt renewals with Certbot?

Renewing Let's Encrypt certificates with Certbot is straightforward. Certbot automatically handles renewals for you. By default, it checks for renewal every day and renews certificates that are within 30 days of expiring. Ensure your server is configured to allow automatic renewals. Manual renewal can be done if needed, but automation is recommended for continuous security.

Does Let's Encrypt offer Wildcard Certificates?

Let's Encrypt offers wildcard certificates, securing multiple subdomains under a single domain. This simplifies certificate management. To obtain a wildcard certificate, use DNS-based domain validation. Ensure your DNS provider supports the necessary API calls. Wildcard certificates are beneficial for sites with numerous subdomains, reducing the need for separate certificates for each one.

Securing your web traffic with SSL/TLS encryption to handle HTTPS communications is an essential part of building any public or private web service, because without it, your web service will have weak privacy and insecure data transfer, and users won’t trust your services.

Why Create a Self-Signed Certificate on Ubuntu?

Once you create a self-signed certificate on Ubuntu, SSL/TLS encryption will protect your data transfer and prevent sensitive data exposure, in addition to ensuring that the connection is between the correct entities by cryptographically verifying that you’re connecting with an authentic server, and that the messages have not been interfered with while being transferred.

Note: From now on we will refer to SSL/TLS certificates as simply "SSL certificates" for brevity.

How to Create a Self-Signed Certificate on Ubuntu

To create a self-signed certificate on Ubuntu, you'll need to use OpenSSL to generate a private key and a self-signed certificate, specifying the required details like the certificate's validity period and your organization's information. Next, you'll save the key and certificate files in a secure location, and then use it in your Apache or Nginx server configuration.

(Special Offer) - Simplify Your SSL Setup with Our 1-Click VPS Applications

If generating a self-signed SSL certificate sounds daunting, we've got you covered. Our 1-Click VPS applications (WordPress, phpMyAdmin, LAMP, and LEMP, and many others) come with a pre-installed self-signed SSL certificate. Just a few clicks and you're ready to go! Visit our website to get started with the lowest-cost VPS offerings in the world (self-signed certificates included)!

Step 1 - Using OpenSSL to Generate a Self-Signed Certificate

To create a self-signed certificate on Ubuntu, you will use OpenSSL to generate a certificate file that will store some basic information about your site, accompanied by an SSL private key file that will be kept secret in the server, and the server then will use it to securely handle encrypted data.

OpenSSL is a software library that provides tools for general-purpose cryptography and secure communications.

The private SSL key is used by the server to encrypt the content it sends to clients (e.g., web browser) The public SSL certificate is shared publicly with clients requesting the content. So when you request a page, the browser gets the SSL certificate from the server, and uses it to decrypt and access the content signed by the associated private SSL key.

The first step to obtaining an SSL certificate is using OpenSSL to create a certificate signing request (CSR). In normal cases, the CSR will be sent to the Certificate Authority (CA) which in turn will create a certificate based on it. In our case (self-signed certificate), we will create the certificate ourselves based on this CSR we generate using OpenSSL. The CSR contains the common name(s) you want your certificate to secure, information about your company, and your public key.

Note: In order for a CSR to be created, it needs to have a private key from which the public key is extracted. This can be done by using an existing private key or generating a new private key. It is strongly recommended to generate a new private key when creating a CSR instead of using an existing one.

To create a certificate signing request (CSR) and a private key with the openssl library, you will use the openssl req command with the following command structure:

openssl req -x509 -newkey rsa:<rsa_value> -nodes -out <public certificate path> -keyout <private key path> -days <certificate duration in days> -subj "C=<country code>/O=<organization name>/OU=<organizational unit>/CN=<common name>"

Here is what each part of the preceding command means:

• -x509: A multi-purpose certificate utility. It can be used to display certificate information, convert certificates to various forms, sign certificate requests like a "mini CA" or edit certificate trust settings.
• -newkey: Specifies that a new private key should be created with the certificate request.
• -rsa:: The encryption algorithm you’ll use to generate your key. While you can use other encryption algorithms if you want, RSA is one of the best encryption systems that you can use to protect your data in transmission, especially because it comes with great compatibility. <rsa_value> represents the key size in bits.
• -nodes: is not the English word "nodes", it refers, instead, to "no DES". When given as an argument, it means OpenSSL will not encrypt the private key in a PKCS#12 file, and the private key will not have a passphrase. This is important for the web server to have access to the certificate file without needing a passphrase. Otherwise the server would wait for the user to manually enter the passphrase every time the server restarts, which is not convenient.
• -out: defines the path the public key will be generated to, including the filename.
• -keyout: defines the path the private key will be generated to, including the filename.
• -days: The certificate’s lifetime in days.
• -subj: is used to provide all the necessary information within the command itself, instead of having to provide each required piece of information via command line prompts.
  • C defines the two-letter country code where your company is legally located.
  • O defines the organization’s name.
  • OU defines the organizational unit name, which can be the name of your department within the organization.
  • CN is the common name, where you either enter the fully-qualified domain name (FQDN) you’ll use to access the server by (e.g., www.example.com), or the public IP of the server.

Now that you are familiar with the openssl command options and actions, you can form and execute an openssl command to generate a certificate signing request (CSR) as follows:

sudo openssl req -x509 -newkey rsa:4096 -nodes -out /etc/ssl/certs/ssl-selfsigned.pem -keyout /etc/ssl/private/ssl-selfsigned.key -days 365 -subj "/C=US/O=MyCompany/OU=Technical Department/CN=www.example.com"

This command will generate two files automatically created under the respective subdirectories you’ve declared:

• /etc/ssl/private/: will be the location of the SSL private key file.
• /etc/ssl/certs/: will be the location of your CSR file.

In our example, this means that the following files will be generated:

• /etc/ssl/private/ssl-selfsigned.key: your SSL private key file.
• /etc/ssl/certs/ssl-selfsigned.pem: your CSR file, which you can use as a self-signed certificate.

Step 2 - Configuring Apache and Nginx to Use a Self-Signed Certificate

Now that you have your very own self-signed SSL certificate in the form of a CSR file, you can use it to encrypt your data and serve HTTPS requests. To do so, you need to configure your web server to use it. In this step, you’ll learn how to configure and use your self-signed SSL certificate on the two most popular HTTP web servers: Apache, and Nginx.

Creating a Self-Signed SSL Certificate For Apache on Ubuntu

In this section, you’ll learn how to configure the Apache web server to use your self-signed SSL certificate.

First, open Apache’s default configuration file:

sudo nano /etc/apache2/sites-enabled/000-default.conf

By default, your Apache welcome page loads on port 80 without an SSL certificate.

Your Apache’s default configuration will be similar to the following:

<VirtualHost *:80>
        Define servername www.example.com
        ServerName ${SERVERNAME}
        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html
</VirtualHost>

Replace the existing content with the following configuration, and make sure to set the correct values where needed (highlighted in yellow below):

<VirtualHost *:80>
        Define servername www.example.com
        ServerName ${SERVERNAME}
        RewriteEngine on
        RewriteRule ^/.*$ https://\${SERVERNAME}%{SCRIPT_FILENAME}?%{QUERY_STRING} [R=301]
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
<VirtualHost *:443>
        SSLEngine On
        SSLCertificateFile /etc/ssl/certs/ssl-selfsigned.pem
        SSLCertificateKeyFile /etc/ssl/private/ssl-selfsigned.key
        ServerName ${SERVERNAME}
        DocumentRoot /var/www/html
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Here you add two configurations, one for HTTP connections on port 80, and one for HTTPS on port 443.

In the HTTP configuration, you use the RewriteEngine and RewriteRule to redirect HTTP requests to HTTPS. And you also set locations for log files.

In the Apache SSL virtual host example configuration above, you set the SSLEngine directive to On to enable the SSL/TLS Protocol Engine. You set the paths of the self-signed SSL certificate and the SSL private key files you generated earlier. You declare the server name, and the document root directory that holds the files Apache serves. And you also set locations for log files.

Next, use the a2enmod tool to enable the SSL and the RewriteEngine Apache modules. This allows Apache to use SSL/TLS encryption, and the RewriteEngine feature to rewrite requested URLs and redirect users from HTTP to HTTPS:

sudo a2enmod ssl rewrite

Next, test for configuration errors:

sudo apache2ctl configtest

You should receive an output that contains the text Syntax OK, which means you can safely reload Apache, otherwise, you will get a very specific description pointing out the error you have to fix.

Next, restart Apache:

sudo systemctl restart apache2

Now visit your website’s domain name or IP address using https:// at the beginning:

https://domain_name_or_IP

You should see an error telling you that the website is not secure. This means that the self-signed certificate is properly installed, but because the browser does not recognize your certificate as valid, you’ll receive this error. As we’ve mentioned earlier, this self-signed certificate is only for testing purposes and internal use, and not to secure your website for production, because your certificate is not signed by any of the browser’s known certificate authorities. To install a certificate that browsers trust check out this article.

Now that you’ve learned how to configure Apache to use a self-signed certificate, you’ll see how to do the same with an Nginx server.

Creating a Self-Signed SSL Certificate For Nginx on Ubuntu

In this section, you’ll learn how to configure the Nginx web server to use your self-signed SSL certificate.

First, open Nginx's default configuration file:

sudo nano /etc/nginx/sites-enabled/default

By default, your Nginx welcome page loads on port 80 without an SSL certificate. So, you would see something similar to the following configuration:

server {
        listen 80;
        listen [::]:80;
        root /var/www/html;

        index index.html index.htm index.nginx-debian.html;

        server_name www.example.com;
        location / {
                    try_files $uri $uri/ =404;
        }
}

Replace the existing content with the following configuration, and make sure to set the correct values where needed (highlighted in yellow below):

server {
    listen 80;
    listen [::]:80;
    server_name www.example.com;
    access_log off;
    location / {
        rewrite ^ https://$host$request_uri? permanent;
    }
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name www.example.com;
    root /var/www/html;
    index index.php index.html index.htm index.nginx-debian.html;
    autoindex off;
    ssl_certificate /etc/ssl/certs/ssl-selfsigned.pem;
    ssl_certificate_key /etc/ssl/private/ssl-selfsigned.key;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!MD5;

    location ~ \.php$ {
         include snippets/fastcgi-php.conf;
         fastcgi_pass unix:/var/run/php/php-fpm.sock;
         fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
         include fastcgi_params;
    }
}

Here, you have two server blocks representing configuration for two ports: port 80 which serves HTTP requests, and port 443 that serves HTTPS requests.

Notice that, in the HTTP configuration, you use the rewrite directive in the location block to redirect HTTP requests to HTTPS.

In the HTTPS configuration, you set up Nginx to use SSL and set the path of the self-signed SSL certificate file and the SSL private key file you generated earlier. In the location ~ \.php$, you set up Nginx to process PHP files with the php-fpm package.

With the configuration file modified, check for syntax errors in it using the following command:

sudo nginx -t

The output should let you know that the configuration file test is successful.
Now, restart Nginx:

sudo systemctl restart nginx

Now visit your website’s domain name or IP address using https:// at the beginning:

https://domain_name_or_IP

Again, you should see an error telling you that the website is not secure, as this self-signed certificate is only for testing purposes and internal use, and not to secure your website for production, because your certificate is not signed by any of the browser’s known certificate authorities. Again, to install a certificate that browsers trust check out this article.

Step 3 - Verify That Your Self-Signed SSL Certificate Works

Before you verify that your self-signed SSL certificate works, please check the following:

• In the configuration files of both Apache and Nginx, remember to set the server name value to whatever you intend to address your server with. This can be a hostname, full domain name, or an IP address, and make sure it matches the Common Name you chose when creating the certificate. In Apache, the server name is configured using the ServerName directive, and in Nginx, it’s the server_name directive.
• The document root is the root directory you serve your web files from. It is configured using the DocumentRoot directive in Apache, and the root directive in Nginx.
• The redirection configurations we’ve added introduce the good practice of responding on port 80, even if you want to force all traffic to be encrypted. Whenever a user requests a page using an HTTP request, they will be automatically redirected to the HTTPS equivalent of the URL they’ve requested. You can test this new redirect functionality by visiting your site with plain http://and you’ll notice that you will be automatically redirected to a URL beginning with https://.
• If you visit your site in a browser, prefixing https:// to the URL, you would get an error, explaining that your website is not secure as mentioned above. This means that the browser can’t verify the identity of the server, since the certificate is not signed by any of its known certificate authorities. However, this is completely normal for a self-signed certificate and actually means that your SSL configuration is successful.

On receiving the browser error that tells you that the connection is not secure, click the Advanced button or More information depending on the browser, and choose to proceed. The following is an example of the error in the Google Chrome browser:

Once you proceed, your browser will load the Apache or Nginx welcome page, but with a noticeable danger icon and a Not Secure label at the beginning of your URL.

If you click the danger icon, the browser will inform you that the certificate is not valid:

A Self-Signed SSL Certificate with Apache (Example)

Here is the Apache welcome page with a self-signed SSL certificate:

A Self-Signed SSL Certificate with Nginx (Example)

In the pop-ups above, click on “Certificate is not valid” for more details on the self-signed certificate. (Note the 1-year duration, we’ve declared using the days value on the certificate’s creation).

Although this sounds like something has gone wrong, don't worry! This is how you verify that the self-signed certificate is successfully installed!

To avoid this error and install a trusted certificate check out this article.

Congrats!

Your website has become certified with a self-signed certificate, and you can now securely transfer data through HTTPS, and protect your internal traffic.

Facing Difficulties? - Simplify Your SSL Setup with Our 1-Click VPS Applications

If generating a self-signed SSL certificate sounds too complex, we've got you covered. Our 1-Click VPS applications (WordPress, phpMyAdmin, LAMP, and LEMP, and many others) come with a pre-installed self-signed SSL certificate. Just a few clicks and you're ready to go! Visit our website to get started with the lowest-cost VPS offerings in the world (self-signed certificates included)!

FAQ: Creating a Self-Signed Certificate on Ubuntu for Apache and Nginx

How to Renew a Self-Signed Certificate?

To renew a self-signed certificate, generate a new certificate with updated validity. For Apache or Nginx on Ubuntu, use OpenSSL to create a new key and certificate.

Update the configuration files of your web server to use the new certificate and restart the server to apply the changes.

How to Remove a Self-Signed Certificate?

To remove a self-signed certificate, delete the certificate and key files from your server, then update your web server's configuration files to remove references to the deleted certificate and restart the server.

Firefox: The Certificate is Not Trusted Because it is Self-Signed

Firefox does not trust self-signed certificates by default because they are not issued by a recognized Certificate Authority (CA). To bypass this, you can manually add the self-signed certificate to Firefox's trusted certificates:

1. Visit the site with the self-signed certificate in Firefox.
2. Click on the warning icon in the address bar.
3. Click "Advanced" and then "Accept the Risk and Continue."

~ Never take any risks when it comes to your server’s security!

While your business will surely offer more and more online services and transactions, internet security becomes both a priority and a necessity for your customers’ online transactions, to ensure that sensitive information – such as a credit card number and personal information – are only being transmitted to legitimate online businesses like yours.

In order to keep customer information private and secure, you will need to add SSL certificates to your website, which are an essential component of the data encryption process that makes internet transactions secure. 

In other terms, SSL are digital passports that provide authentication to protect the confidentiality and integrity of website communication with browsers.

The SSL certificate's job is to initiate secure sessions with the user’s browser via the secure sockets layer (SSL) protocol. This secure connection cannot be established without the SSL certificate, which digitally connects company information to a cryptographic key.

What Effect Do SSL certificates Have on Your Business?

There are many benefits to using SSL certificates. Namely, SSL-based websites can:

• Utilize HTTPs, which optimizes SEO and elicits a better rank in the search results of search engines such as Google.
• Create safer experiences for customers, because data they submit is encrypted before it is transmitted through the internet.
• Build customer trust and improve conversions.
• Protect both the customer and internal data.
• Encrypt browser-to-server and server-to-server communication.
• Increase security of your mobile and cloud apps.

Technicalities anyone?

Here is how SSL certificates work:

1. A browser or server attempts to connect to a website (i.e. a web server) secured with SSL. The browser/server requests that the web server identify itself.
2. The web server sends the browser/server a copy of its SSL certificate.
3. The browser/server checks to see whether or not it trusts the SSL certificate. 
4. If so, it sends a message to the web server.
5. The web server sends back a digitally signed acknowledgment to start an SSL encrypted session.
6. Encrypted data is shared between the browser/server and the web server.

Self-Signed Certificate vs CA Certificate: What’s the Difference?

When using a self-signed certificate, you’re essentially vouching for your own identity. It’s like writing “I have graduated” on a piece of paper and considering it your official graduation certificate. While you might be excellent in your academics, people aren’t going to trust your self-created certificate! They’d want the document to be issued and signed by an official institution such as a college or university.

In much the same way, no browsers, email clients, or operating systems are going to trust digital certificates that are signed by the entities they’re designed to validate. Hence, why they don’t show any of the above-mentioned trust indicators for self-signed certificates.

But it gets worse. Not only will browsers not trust a self-signed certificate, but they’ll even display a security warning page with error messages like the one shown below, this means that your website visitors must manually click on the “Accept Risk” button to open your site — and that can drive them away.

The difference between a self-signed and a CA certificate is the issuer of the certificate. A self-signed certificate is created, signed, and issued by the subject of the certificate (the entity it is issued to), while a CA certificate is created, signed, and issued by a third party called a certificate authority (CA) that is authorized to validate the identity of the applicant.

Pros and Cons anyone?

In this next section, we will schematize the pros and cons outlining in a clearer way the real differences between the self-signed and CA certificates.

Advantages of Self-Signed SSL Certificates

• They are free.
• They are very convenient for internal (intranet) sites, and sites used in testing environments.
• You can specify the certificate’s lifetime adding more control over its use.
• Data encryption and decryption are done with the same ciphers used by paid SSL certificates.

Disadvantages of Self-Signed SSL Certificates

• They can cost you more than you think. While you can save some money using a free Self-Signed SSL Certificate at first. There is a high risk that attackers can cause enormous damage to your website, which may be astronomically higher than the price you would pay for an SSL Certificate.

• Their lifetime is manually set upon creation, hence a renewal reminder should be set before they expire, which would cause a management hassle.
• No support for advanced PKI (Public Key Infrastructure) functions (e.g. Online checking of the revocation list etc.).
• They cannot be revoked which makes a compromised certificate difficult to identify, and this has several security challenges.

Couple these self-signed certificate vulnerabilities with the operational challenges most organizations face with expiring and misconfigured certificates, and you can see how attackers can easily exploit this vulnerability.

Advantages of CA Certificates

• They are suitable for all public-facing websites and software.
• They can be revoked by the certificate authority if they discover that it has been compromised, but organizations using self-signed certificates must go through the process of replacing or rotating the certificate. 
• They support PKI (Public Key Infrastructure) functions, like:
   - SSL/TLS certificates to secure web browsing experiences and communications.
   - Digital signatures on software.
   - Restricted access to enterprise intranets and VPNs.
   - Password-free Wifi access based on device ownership.
   - Email and data encryption.
• They offer protection and customers’ trust for:
   - Paid subscriptions or memberships.
   - Tax information, health records of users, or any other personally identifiable information (PII).
   - Donations, charity, or fundraising.
   - eCommerce facilities.

Disadvantages of CA certificates

• They are paid services. Although there are some free CA certificates such as Let's Encrypt 
• You cannot specify the certificate’s lifetime, which is a limiting factor for control freaks.
• You might be led to pay subscriptions for fake and fraudulent CAs... So always make sure that you are purchasing from a trustworthy CA like Symantec, Let's Encrypt, GeoTrust, Comodo, DigiCert, Thawte, GoDaddy, Network Solutions, RapidSSLonline, SSL.com, Entrust Datacard

Bottom Line?

• A self-signed certificate is convenient when used in private networks and testing environments.
• A CA certificate signed by a publicly trusted CA can build trust among website visitors, and therefore, it is used to validate public websites.

How to set up your Self-Signed or CA certificate

Our tech team has prepared a step-by-step tutorial with hands-on examples for securing your site with self-signed or CA certificates on Ubuntu.

Reader Alert

If you feel that this topic is too technical, or beyond your expertise, you can choose a very convenient and practical solution, ready-made, fully tested, and developed by SSD Nodes (That is us ) to create a website with an active SSL self-signed certificate.

Just visit our website, choose the server’s specifications that fit your needs, along with any of the 1-Click Applications we offer (WordPress, Zabbix, phpMyAdmin, Webmin, Nextcloud, LAMP, LEMP, Grafana, MongoDB to name a few), complete your checkout, and in a couple of minutes, our algorithms will make it ready to use with an active SSL self-signed certificate!

Enjoy!

To install Nginx and Certbot on Ubuntu/Debian systems, you first need to make sure that your FQDN has an A record pointing at your server's public IP, and then simply run:

$ sudo apt install nginx;
$ sudo snap install core; sudo snap refresh core
$ sudo snap install --classic certbot

To issue a free SSL/TLS certificate from Let's Encrypt, and automatically modify Nginx to use those certificates, run the below command:

$ sudo certbot --nginx

That's it! Nginx is now serving it's default website, at /etc/nginx/sites-enabled/default as an HTTPS website.

A More Detailed Explanation

One of the most basic tasks you will perform while setting up your next website, app or API server is to ensure that the traffic is encrypted between the client and the server, and that the identity of the original server is verifiable. TLS enables us to do that.
Continuing our series on Nginx Basics, we will see how to procure a TLS (also known as SSL) certificate and make Nginx use it to encrypt and secure all web traffic.

Prerequisites

In order to follow along, you need the following:

• A very basic understanding of Nginx configuration, as discussed here.
• A very basic understanding of how TLS works
• A VPS with a public IP, running Ubuntu 20.04 LTS. If you don't already have one, head over to SSDNodes and treat yourself to some delicious compute
• A registered domain name, like www.example.com where you want to host your project.

Initial Setup

1. Setting Up DNS Record

The first thing you need to do, is to point visit the DNS management service that you are using. This could be the very place that you bought your domain name from, like Hover, Namecheap, Gandi or GoDaddy. Or it could be the third party DNS service provider like Cloudflare. At your name server control panel, create an A record for your domain pointing to the Public IP address of your VPS.

For example, if you own example.com and want to run a website called test.example.com, then create an A record for test.example.com pointing at  your IP address which itself would look something like 127.74.45.11
Here, example.com is known as your Domain Name and, test.example.com is known as your Fully Qualified Domain Name or FQDN

To find your IP, simply use the command:

$ ip addr

Output:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:fe:d4:a4:87 brd ff:ff:ff:ff:ff:ff
    inet 63.250.55.96/24 brd 63.250.55.255 scope global noprefixroute enp3s0
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:feff:fed4:a487/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

Depending on what you have installed on your VPS, Docker, LXD etc there might be quite a few network interfaces and to figure out which one is your public interface can get a bit tricky. But by default, there are only two. A loopback interface, called lo, and our public interface usually called enp3s0 or eth0 or ens3. In our case it is enp3s0 and the IP address (listed as inet) is 63.250.55.96

The IP address will be different in your case, set an A record for it, and then we can move on to step two.

2. Installing Necessary Packages

Apart from the obviously needed Nginx package we will also need Certbot to fetch TLS certificates and automatically configure Nginx for us. For Ubuntu 20.04 and Debian 10 systems you can run the following commands:

$ sudo apt install nginx -y
$ sudo systemctl start nginx
$ sudo snap install core; sudo snap refresh core
$ sudo snap install --classic certbot

Once, Nginx is installed you will be able to see a basic HTML website if you type in your public IP address into your web browser's address bar.

3. Adding Server Name to Nginx config

In order to make things easier, for Certbot, we can modify the file /etc/nginx/sites-enabled/default and replace the following line:

server_name _;

With the proper FQDN of your server:

server_name test.example.com;

Make sure to use your own specific FQDN instead of just example.com this will be read by Certbot to automatically try and fetch certificate for it.

Fetching Let's Encrypt TLS Certificate Using Certbot

Let's Encrypt is the certificate authority that we will be using to issue a free TLS certificate for our website. Certbot is the program that will talk to Let's Encrypt and automatically fetch the certificate for us. To learn more about how TLS and Let's Encrypt works you can check out this blog post.

To fetch and install the certificates in a single command:

$ sudo certbot --nginx

It will prompt you to enter your email address, which is needed for certificate renewals and other security updates:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Enter email address (used for urgent renewal and security notices)
(Enter 'c' to cancel): name@example.com

Next, you need to accept Let's Encrypt's Terms of Service:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
agree in order to register with the ACME server. Do you agree?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: Y

This will be followed by an option to sign up for their newsletter, which you can agree to, or deny. After this, certbot will go through all your nginx configuration files and if you have been following along so far, it will grab your FQDN automatically, like so:

Account registered.

Which names would you like to activate HTTPS for?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: test.iranvir.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel):

Press ENTER and Certbot will fetch the certificates and then modify your Nginx configuration to automatically use the new certifcates. Certbot will also configure Nginx to automatically redirect all the unecrypted  traffic (reaching on port 80) to encrypted traffic (reaching on port 443). If you have not modified the configuration file, the process will still work but you will have to manually enter the FQDN when prompted.

Final Steps

The certificates expires after 90 days. To renew them, simply run the command:

$ certbot renew

I would recommend, adding the above command to your crontab file. This would allow your server to automatically run the command after a given time interval. For example, adding the below line to your /etc/crontab:

0 0 * * * root certbot renew

Would make sure that your VPS tries to renew the certificate everyday at midnight. And when the expiry date draws closer, it will automatically renew it as well!

Changes in the Configuration

If you are doing anything more complex than a WordPress blog, chances are you will need to know how to configure TLS/SSL certificates yourself. So let's look at the configuration file and how it has changed:

Initially, the file /etc/nginx/sites-enabled/default looked like this:

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    root /var/www/html;
    index index.html index.htm index.nginx-debian.html;
    server_name test.example.com; #Custom change made by us during this tutorial

    location / {
        try_files $uri $uri/ =404;
    }
}

The same configuration, after issues the certbot --nginx command, looks like this:

server {

    root /var/www/html;
    index index.html index.htm index.nginx-debian.html;
    server_name test.example.com;

    location / {
        try_files $uri $uri/ =404;
    }

    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/test.example.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/test.example.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}

server {
    if ($host = test.example.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot

    listen 80 default_server;
    listen [::]:80 default_server;

    server_name test.iranvir.com;
    return 404; # managed by Certbot

}

The comments indicate which parts of the configuration are managed by Certbot. For example, from our initial server block the line listen 80 default_server; directive got replaced by listen 443 ssl; and a few extra lines were added to indicate SSL(or TLS) specific settings, like the location of fullchain.pem and privkey.pem files which are your certificate and private key, respectively. In addition, a new server block is added that listens on port 80, and if the incoming HTTP traffic is for http://test.example.com it redirectly it all to https://test.example.com thereby ensuring that all the traffic is encrypted, without the end user of the website having to worry about it.