Logo Khaganat
This translation is older than the original page and might be outdated. See what has changed.
Translations of this page?:

Https and SSL certificates

This article is a “draft form” and contains fragmentary information. If you have the opportunity, complete it, and add links to better-provided pages.

Take the information contained here carefully and check.

Why https?

When you visit a website, a flow of data flows between your computer and that of the server where the site is hosted. For some sites, it does not matter that this feed is readable by everyone, but from the moment you enter a password, you should go through the “https” protocol wich ensures that the exchanges between you and the server are encrypted. This so your transferred information is hard to spy upon!!.

Installing a self-signed certificate

A self-signed certificate will generate an alert on any serious browser. Because this(installed) certificate is very basic and serves only on a test server(for testing around https). It will not be recognized by any authority!!

There's now: “Let's encrypt”, which provides you with a recognized certificate free of charge. At the time these lines are written, it is still in beta, not free of defects but functional and therefore to privilege. See below.

The self-signed certificate can still be of interest, locally or if you work in a vm(Virtual Machine) without web access. But NOT for use in production.

In root

Install the ssl-cert package. It will install a “pre-configured” certificate for the server(on which it is installed).

Check that in/etc/apache2/sites-available/default-ssl.conf, the options SSLCertificateKeyFile and SSLCertificateFile point to the certificate

SSLCertificateFile      /etc/ssl/certs/ssl-cert-snakeoil.pem
SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key

Enable SSL support:

a2ensite default-ssl
a2enmod ssl
service apache2 restart

For more details on installing a self-signed certificate, and if you want to use a less “turnkey” method, see:

Let's Encrypt

Creating a certificate with “Let's encrypt” is a very simple thing! ™

First, place yourself on a user account and retrieve the Let's Encrypt client(now called “CertBot”):

git clone https://github.com/certbot/certbot

And place it in the certbot directory.

Launch the client:

cd certbot
sudo ./certbot-auto 

The certificates are found in /etc/letsencrypt/live/ once the client has finished. It asks a few questions, like including an email to receive notifications, and the domain names for which you want a certificate.

It also asks if we want an automatic redirection from http to https.

All you have to do is configure apache2 with these certificates. An provided configuration file with what already exist, but make sure it is appropriate. As an priority, all this is finalized(all alone) and there is nothing else to do now(info valid at the end of August 2016).

Subdomains and different domains on the same machine

For “Let's encrypt” to generate a certificate for all the domains hosted on the server, it is better to make a file by vhost in Apache. OBS: Make only unsecured versions(port 80), because “let's encrypt” automatically generates the secure versions(port 443, the “https”).

Let's encrypt seems to locate the subdomains correctly in the same file(name1.mydomain.com, name2.mydomain.com, etc.) 1), but not the different domain names(mondomaine.com and mondomaine2.com for example), which must imperatively be different configuration files.

Know the expiration date of the let's encrypt certificate

Currently, the duration of the certificates issued by “let's encrypt” is very short(90 days only). You will receive an e-mail(at the address you entered when creating the certificate) about it, but if you have many domains to manage and you do not sort through the mails from time to time, how do you then know whether you already have renewed or not??

Here is an inspiring script to use for this kind of trouble: https://blog.hbis.fr/2010/06/24/openssl-check_expire_date/] 2), Which adapts to All certificates:

set -euo pipefail
error() {
>&2 echo "$msg"
exit 1
test $# -eq 0 && error "Usage: $0 <certificate_file>"
test ! -f "$FILE" && error "$FILE: file not found."
EXPIRE_DATE=$(openssl x509 -in "$FILE" -noout -enddate | cut -f2 -d=);
echo "Certificate file: $FILE";
echo "Expiration date: $EXPIRE_DATE";
exit 0;

Copy the information(above) to a file with the name: check_cert.sh and then run the following command:

./check_cert.sh /etc/letsencrypt/live/monsite.net/cert.pem

Adapted accordingly to where the certificate is stored.

Renew the certificate

To renew the certificate, simply run the same command as to install it:

cd letsencrypt
Sudo ./certbot-auto

To renew everything automatically(without interaction), the following command looks good:

 certbot-auto renew

In this case, using the “cron task” every 90 days would be sufficient to renew the certificates. The following is an example of a cron task, with a renewal every two months(and a logging service):

1 1 1 2,4,6,8,10,12 * /root/letsencrypt/certbot-auto renew > /root/renewlets.log

Improve and test site security via https

To verify the https quality when accessing sites, try these links:

See apache's SSL configuration file /etc/apache2/mods-available/ssl.conf. Fail!! The SSL3 protocol is no longer considered “safe” since the PODDLEd attack demonstration…

 SSLProtocol all -SSLv2 -SSLv3

(Note the “-” in front of SSLv3)

Prohibit the compression of encrypted exchanges(yes, yes.. this introduces attack possibilities)

 SSLCompression off

And finally the list of “crypto algorithms” allowed:


To be tested, new proposal is:


Former configuration, generates an A- date: 11/02/2016. The news at the top comes from https://www.digicert.com/ssl-support/ssl-enabling-perfect-forward-secrecy.htm.


Note the “!” before some algorithm names to forbid them, for example:! PSK,! RC4, etc…

Then impose to negotiate the protocols in the above order: listed from the safest to the least safe:

SSLHonorCipherOrder On

Remember to restart Apache:

# /etc/init.d/apache2 restart
Avoid it nevertheless, one file per subdomain is a better choice.
Thanks to TychoBrahe for the corrections.
CC Attribution-Share Alike 4.0 International Driven by DokuWiki
en/https_ssl.txt · Last modified: 2021/12/03 19:19 by

Licences Mentions légales Accueil du site Contact