The SSL certificate

Some of you might wonder in which situations an SSL certificate should be used. This tutorial will help you to find an answer whether or not you should upgrade your website or anything else by adding encryption.

The most important parts of a certificate are the public key and the private key.
The following image shows you what is happening when a client tries to establish an encrypted connection to some webserver.



First the client contacts the server and offers available encryption types, the server and the client come to an agreement on which type to use.
The web server sends the public key to the client so the client will be able to encrypt its requests. The webserver got his private key to decrypt all encrypted client requests. With the private key you are able to decrypt all client requests which were encrypted with the public key, that is why you should never hand out your private key to any third party.

To show you the advantage of using encryption, we created an HTML page containing a simple form which can be found on many websites. In the textfields we entered a username and password.

The username we chose: test@contabo.de

The password we entered: "unencryptedpassword"

To show the difference between encrypted messages and not encrypted messages, we captured some packets using a networking-tool.

Without any encryption we could easily extract the username and password used, we could also see which sites we visit.


With encryption enabled we could not find neither username nor password.
It just shows a packet containing some encrypted data, without the private key we cannot determine which data was actually sent.

If you are running a website, an email server or just an FTP server, it is always up to you to offer encryption or not. Offering encryption to your customers is the best way to act professionally.

There are many types of encryption, this post just handles certificates. Usually encryption algorithms have not changed for years, if you are going to optimize your server you will of course have to think about encryption types, etc.


The real meaning of those connection warnings:

If you are running a web interface (cPanel, Plesk, Webmin etc.) you probably encountered a warning as follows:


"The connection is not private", usually you should rethink if you really want to proceed. There is the possibility that some server got hijacked and you are redirected to the wrong website. In this case the warning pops up because the certificate is not valid for the domain we entered. On a web interface you will get a similar warning when using a so called "self signed certificate". Your browser got a list of authorities which it will trust, signed certificates by one of those authorities will not show any warning.

It can be really unwanted if that warning is showing to all of your customers, sometimes this warning is misinterpreted and the website will be left.

There is only one way to remove this warning, you need to get a certificate signed by some official authority.

Some official authorities, such as "Lets Encrypt", will sign your certificate for free, this is a nice option but not really recommended on a production environment. Usually the domain validated certificate or wildcard  certificate is being used for production environment, those certificates usually are valid for 365 days (1 year).

There are some differences between single domain, multi domain and wildcard certificates. Usually you would want a certificate for "yourdomain.tld" or "www.yourdomain.tld". A single domain certificate will be valid only for one of those domains, a multi domain certificate alias UCC (Unified Communications Certificate) is valid for all domains included within that certificate. In case you want "www.yourdomain.tld", "yourdomain.tld" and "subdomain.yourdomain.tld" within a single certificate, a UCC should fit your needs.

There is also some extended validation available, some bigger companies take advantage of this (e.g. PayPal pp_ev). At this point I want to mention that the private key and certificate will always remain the same, there is no encryption change, the certificate will just get signed.

Right after you got your certificate signed by some official authority, everyone will be able to access your encrypted website without any warning.


Encryption is important, all services (email server, FTP server, web server, etc.) running on your server should offer a way to establish an encrypted connection. There is no need of installing a signed certificate on each service, for most services self-signed certificates are fine.


Posted by: Gianni-Donato | Tagged as: , , , , 4 Comments

Let’s Encrypt!

In times when data security is an important topic, encryption is a vital part of it. Unfortunately, in most cases, it is a complex task which many users are not able to handle properly due to the lack of expert knowledge in this field. To secure a website via Secure Socket Layer (SSL) or Transport Layer Security (TLS) for being accessible via Hypertext-Transfer-Protocol Secure (HTTPS), a certificate is needed.

Encrypted connections are based on certificates, if a user is accessing a website via HTTPS, an encrypted connection is being established. Before this encrypted connection can be established successfully, the certificate provided by the accessed server is being verified if it can be trusted. This verification of trust is basically done as follows:

  1. Signature verification of the certificate based on the chain of trust
  2. Verification if the accessed domain corresponds to the domain which is valid according to the certificate

What is this chain of trust all about?

In general every operating system and even browsers like Firefox or Google Chrome come with pre-installed certificates from trusted certificate authorities (CAs). These certificates are always trusted if they are not revoked in the meantime. The chain of trust verification basically verifies, if the signature of the certificate in question is already trusted by the pre-installed certificates of the trusted certificate authorities. It is called chain of trust as it is for example possible, that the signature of Let's Encrypt is not trusted on your system but the certificate which is used by Let's Encrypt in order to sign your certificate is also signed with a certificate of a third trusted certificate authority which is trusted on your system. Therefore Let's Encrypt guarantees that your certificate can be trusted and the third certificate authority, which is trusted on your system, guarantees that Let's Encrypt can be trusted as well.

How does the Let's Encrypt project differ to other certificate authorities?

As establishing and running a trusted certificate authority is expansive, normally a fee has to be paid in order to have your certificate being signed from a trusted certificate authority. Let's Encrypt did establish a trusted certificate authority which offers the signing of certificates for free and aims to improve and automate the process of certificate creation and installation in general. The main idea behind this project is to create a more secure and privacy respecting web.

Free certificates with our Webspace Packages

As we already informed you with the post Webspace: Free SSL certificates available now!, domains added via our Webspace Packages are already equipped with a Let's Encrypt signed certificate. Even the renewal of the certificates is handled completely automatically.

Let's Encrypt via AutoSSL in cPanel

Since cPanel & WHM Version 58.0.17, Let's Encrypt is officially supported by cPanel. Currently it is necessary to integrate it via shell by invoking the installation script located at /scripts/install_lets_encrypt_autossl_provider as root user. After successful installation it is possible to choose Let's Encrypt as the default certificate provider via Home >> SSL/TLS >> Manage AutoSSL.
autossl_lets_encrypt Specific user settings can be done via the "Manage Users" tab.

Let's Encrypt via extension in Plesk

Also Plesk in versions 12.5 and later supports Let's Encrypt by an extension. The installation and configuration steps in this tutorial work for both Linux and Windows installations.

To install the extension, please go in Plesk to:

"Tools & Settings" >> in the area "Plesk" >> "Updates & Upgrades"

A new tab is opening. Eventually you have to confirm a self signed certificate for this site in your browser. On the site, please choose "Add/Remove Components".


Please mark the extension for installation like in the picture above and start the installation with "Continue". The installation finishes with the message "All operations with products and components have been successfully completed.". With a click on "OK" you will come back to the main menu. You can close the browser tab then.
Now you have to request the certificate and activate it for the domain. To do so, please change to "Websites & Domains" and choose "Show more" to increase the available list of options for your domain. As you can see, there is now an additional option for Let's Encrypt.


Please open this link and check the e-mail address. Consider if the site should be available over www too and if necessary, set the tick at "include www.yourdomain.com as an alternative domain name.". With a click on "OK", you will start the request for the certificate. When the process has finished, your site should already be reachable over https. To be on the safe side, you can now go to the the "Hosting Settings" of your domain and check in the area "Security" the option "Permanent SEO-safe 301 redirect from HTTP to HTTPS". This will prevent unencrypted connections to your website. In the option below you can choose the just ordered certificate manually to be used for your site if has not been chosen automatically.

If there was an error shown during the certificate request, please check if the A record of your domain is pointing to the IP address of your server. This also applies to the subdomain with www.

Let's Encrypt usage without an Administration Panel (Debian 8)

The usage of Certbot is recommended together with Let's Encrypt. We are using the Apache webserver and the operating system Debian 8 for our example.

In order to install Certbot together with all dependencies, the following commands have to be executed as root user:

# Activate Debian Jessie backports repository

echo "deb http://ftp.debian.org/debian jessie-backports main" >> /etc/apt/sources.list && apt-get update


# Installation of Certbot

apt-get install python-certbot-apache -t jessie-backports


After the installation it is possible to automatically generate signed certificates for your domains via Certbot. The certificates will be configured automatically within your Apache webserver too. The following command invokes a configuration dialogue which is asking for information like domain name(s) and your e-mail address. After submitting the required information and agreeing to the terms of service of Let's Encrypt, your signed certificate(s) will be created and configured within Apache. It is also possible to decide whether your domain shall be accessible via HTTP and HTTPS or if HTTPS connections shall be forced.

# Starting the automated configuration dialogue

certbot --apache

If you desire to configure your certificate(s) on your own, the following command can be used for creating the signed certificate(s) only.

# Creation of certificate(s) only

certbot --apache certonly

Certbot does not only support Apache with Debian 8 as operating system, there are several combinations of webservers and operating systems possible which can be seen via the following link: Certbot.

Let's Encrypt installation without Administration Panel (CentOS 7.2)

As the usage of Certbot on CentOS does not differ from the usage on Debian 8, we are just taking a short look into the installation of Certbot on CentOS. As the Apache/httpd default package (yum install httpd) on CentOS does not include the SSL module, you need to make sure to have this module installed before installing Certbot.

# Installation of Extra Packages for Enterprise Linux and optionally mod_ssl

yum install epel-release mod_ssl 

# Installation of Certbot

yum install python-certbot-apache


Configuration of an automated certificate renewal

Since Let's Encrypt certificates are only valid for three months, it is vital to configure an automated renewal.

As the Certbot package of Debian 8 already configures a cron-job for the certificate renewal we are going to show you how the cron-job can also be configured for a standard CentOS installation.

# /etc/cron.d/certbot


0 */12 * * * root test -x /usr/bin/certbot && perl -e 'sleep int(rand(3600))' && certbot -q renew


This cron-job runs every 12 hours and triggers the renewal of all your certificates, if they will expire in less than 30 days. It is recommended to leave this value of twice a day as this will help recognizing that a certificate has been revoked.



Posted by: Dirk | Tagged as: , , , No Comments