====== Https and SSL certificates ======
<WRAP center round todo 60%>
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.
</WRAP>

===== 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!!.

  * [[http://www.bitdefender.fr/blog/Pourquoi-le-protocole-HTTPS-est-%28toujours%29-bon-pour-vous-437.html|Development on why https is better for the one who browses the web.]]
   * [[http://sebsauvage.net/comprendre/ssl/index.html|A more complete article by Sebsauvage on the issue.]]
   * To summarize, https is like a condom: it does not protect everything, but it's the minimum to avoid trouble.

===== Installing a self-signed certificate =====
<WRAP center round important 60%>
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. [[en:https_ssl#lets_encrypt|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.
</WRAP>

**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:
  * http://blog.moncoindunet.fr/linux/openssl-creer-un-certificat-auto-signe/
  * http://doc.ubuntu-fr.org/tutoriel/securiser_apache2_avec_ssl

===== 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"):
<code>
git clone https://github.com/certbot/certbot
</code>

And place it in the certbot directory.

Launch the client:

<code>
cd certbot
sudo ./certbot-auto 
</code>


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.) ((Avoid it nevertheless, one file per subdomain is a better choice.)), 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/]]] ((Thanks to TychoBrahe for the corrections.)), Which adapts to All certificates:
<code bash check_cert.sh>
#!/bin/bash
 
set -euo pipefail
IFS=$'\n\t'
 
 
error() {
msg="$1"
>&2 echo "$msg"
exit 1
}
 
test $# -eq 0 && error "Usage: $0 <certificate_file>"
 
FILE="$1"
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;
</code>

Copy the information(above) to a file with the name: ''check_cert.sh'' and then run the following command:
<code>
./check_cert.sh /etc/letsencrypt/live/monsite.net/cert.pem
</code>

Adapted accordingly to where the certificate is stored.

==== Renew the certificate ====

To renew the certificate, simply run the same command as to install it:
<code>
cd letsencrypt
Sudo ./certbot-auto
</code>

<WRAP center round tip 90%>
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


</WRAP>


===== Improve and test site security via https =====
To verify the https quality when accessing sites, try these links:
   * Https://www.ssllabs.com/ssltest/analyze.html: Allows you to see the biggest errors
   * Https://observatory.mozilla.org/: Mozilla is more demanding and allows to have a site well secured


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:
  SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4"

<WRAP center round help 60%>
To be tested, new proposal is:
  ALL:!aNULL:!eNULL:!LOW:!MEDIUM:!EXP:!RC4:!3DES:!MD5:!PSK:+HIGH
</WRAP>


<WRAP center round tip 60%>
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]].
  SSLCipherSuite 'EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA'
</WRAP>


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

{{tag>Web Server Tutorial Draft}}