Rappel sur les différentes étapes pour mettre en place un server dédié à Owncloud

Chap 1. Prise en main du RPi et installation de Mate sur un Raspbian
Chap 2. Installation de OwnCloud sur un Raspberry Pi
Chap 3. Sécuriser votre RPi
Chap 4. Accès au serveur Web Owncloud à partir de son nom de domaine
Chap 5. Connection SSH
Chap 6. Les fichiers journaux
Chap 7. Let’s Encrypt (LE)
Chap 8. Ajout d’un disque dur externe et migration de données
Chap 9. Suppression et ajout d’une interface graphique
Chap 10. Rappel sur les différentes étapes pour mettre en place un server dédié à Owncloud

Chap 10. Rappel sur les différentes étapes pour mettre en place un server dédié à Owncloud

Ce chapitre n’a pour but que de vous faire un petit résumé des différentes étapes à partir de l’installation de Owncloud sur un Raspberry Pi, jusqu’à avoir un server fonctionnel.

Je vais aussi en profiter de cette partie pour tester la dernière version en date de Owcloud.

Pour rappel, nous avons besoin de:

  1. Matériel:

    – Raspberry Pi 2 B
    – Carte micro SD, Classe 10
    – Câble HDMI avec un moniteur (écran télé) qui supporte le HDMI
    – Câble Ethernet

  2. Firmware:

    – Owncloud 9.1.3
    – Raspbian 8.0

  3. Configuration:

    – Adresse IP Publique
    – Adresse IP Privée statique (LAN) pour le RPi
    – Nom de domaine (NetLibre, nsupdate)
    – Certificat LE (Lets encrypt)

Ne vous attendez donc pas à ce que je détaille les différentes étapes de l’installation, puisque çà a déjà été abordé dans les différents chapites associés. Je vous renvoie donc vers les différentes sections pour plus d’information.

Chap 1. Prise en main du RPi
—————————————–

$ df -h

$ sudo umount /dev/sdb1

$ sudo apt install dcfldd

$ sudo dcfldd if=20XX-YY-ZZ-raspbian-jessie-lite.img of=/dev/sdb bs=1M
$sync

$ sudo cat >  /etc/network/interfaces.d/eth0 << eof > auto eth0
>
> iface eth0 inet static
>     address 172.16.1.16
>      netmask 255.255.255.0
>      gateway 172.16.1.1
> eof

# ifdown eth0

# ifup eth0

# vi /etc/resolv.conf
# Generated by resolvconf
nameserver 8.8.8.8
nameserver 8.8.4.4

# chattr +i /etc/resolv.conf 


$ sudo apt update
$ sudo apt upgrade

$ sudo apt install vim

$ sudo raspi-config 

Un petit plus,

pi@raspberrypi:~ $ sudo hostname nouveau-nom
pi@nouveau-nom:~ $ sudo vim /etc/hosts
!--sortie tronquée--!
127.0.1.1	nouveau-nom

Faite une copie de sauvegarde du système installé sur la carte SD vers un autre support (disque dur local par exemple):

$ sudo umount /dev/sdb1
$ sudo umount /dev/sdb2

mon@ordi$ cd ~/Backup

$ sudo dcfldd if=/dev/sdb of=sd.img bs=4M

Chap 3. Sécuriser votre RPi
—————————————–

mon@ordi$ ssh pi@10.1.2.3

$ sudo adduser USERNAME
$ sudo adduser USERNAME sudo

$ groups pi
pi : pi adm dialout cdrom sudo audio video plugdev games users input netdev spi i2c gpio
$ groups USERNAME
USERNAME : USERNAME sudo

$ sudo usermod -a -G adm,dialout,cdrom,audio,video,plugdev,games,users,input,netdev,spi,i2c,gpio USERNAME

mon@ordi$ ssh USERNAME@10.1.2.3

sudo deluser --remove-home pi

Je n’ai pas réussi à supprimer l’utilisateur pi du premier coup, car la commande renvoie l’erreur que cet utilisateur a un process actif (bash). J’ai du redémarrer le RPi et relancer la même commande. Une autre alternative serait d’utiliser la commande ci-dessous:

$ sudo userdel -f pi

$ sudo passwd -dl root

$ sudo vim /etc/ssh/sshd_config
PasswordAuthentication no
PermitRootLogin no
$ sudo service ssh restart

*Connection SSH côté client
—————————————

mon@ordi$ sudo apt-get install openssh-client
mon@ordi$ ssh-keygen -t rsa

N’ommetez pas la passphrase!!!

Les clés générées devraient se trouver dans le répertoire ~/.ssh:
– clé privée: id_rsa (vous devez ne jamais fournir cette clé à personne)
– clé publique: id_rsa.pub

mon@ordi$ ssh-copy-id -i ~/.ssh/id_rsa.pub USERNAME@10.1.2.3

*Connection SSH côté server
—————————————

USERNAME@raspberrypi$ sudo apt-get install openssh-server

Vérifier et modifier les permissions pour les fichiers et dossiers si nécessaire.

drwx------ .ssh
-rw------- .ssh/authorized_keys


$ sudo vim /etc/ssh/sshd_config
PasswordAuthentication no

$ sudo service ssh restart

*Parefeux
—————————————

$ sudo vim /etc/iptables.firewall.rules
*filter

# Allow all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT -d 127.0.0.0/8 -j REJECT

# Accept all established inbound connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow all outbound traffic - you can modify this to only allow certain traffic
-A OUTPUT -j ACCEPT

# Allow HTTP and HTTPS connections from anywhere (the normal ports for websites and SSL).
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT

# Allow RDP connections from anywhere (uncomment if rdp connection is needed)
# -A INPUT -p tcp --dport 3389 -j ACCEPT

# Allow SSH connections
# The -dport number should be the same port number you set in sshd_config
-A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT

# Allow ping
-A INPUT -p icmp --icmp-type echo-request -j ACCEPT

# Log iptables denied calls
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7

# Drop all other inbound - default deny unless explicitly allowed policy
-A INPUT -j DROP
-A FORWARD -j DROP

COMMIT
$ sudo iptables-restore < /etc/iptables.firewall.rules
$ sudo iptables -L

sudo vim /etc/network/if-pre-up.d/firewall
#!/bin/sh
/sbin/iptables-restore < /etc/iptables.firewall.rules

$ sudo chmod +x /etc/network/if-pre-up.d/firewall

$ sudo apt install fail2ban

Chap 2. Installation de OwnCloud sur un Raspberry Pi
—————————————–

$ mkdir /home/USERNAME/www-dev
$ cd /home/USERNAME/www-dev


$ sudo wget http://download.owncloud.org/community/owncloud-9.1.3.tar.bz2
$ sudo wget http://download.owncloud.org/community/owncloud-9.1.3.tar.bz2.md5
$ md5sum -c owncloud-9.1.3.tar.bz2.md5 < owncloud-9.1.3.tar.bz2
owncloud-9.1.3.tar.bz2: OK

$ sudo tar -xvf owncloud-9.1.3.tar.bz2

$ sudo chown -R www-data:www-data /home/USERNAME/www-dev

*Apache
—————————————

$ sudo vim /etc/apache2/sites-available/owncloud.conf
Alias /owncloud "/home/USERNAME/www-dev/owncloud/"
<Directory /home/USERNAME/www-dev/owncloud/>
 Options +FollowSymlinks
 AllowOverride All

 <IfModule mod_dav.c>
 Dav off
 </IfModule>

 SetEnv HOME /home/USERNAME/www-dev/owncloud
 SetEnv HTTP_HOME /home/USERNAME/www-dev/owncloud

</Directory>


Lier symboliquement /etc/apache2/sites-enable/owncloud.conf à /etc/apache2/sites-avaibled/owncloud.conf:
$ sudo a2ensite owncloud.conf

Remplacer a2ensite par a2dissite pour supprimer le lien symbolique.

$ sudo a2enmod rewrite
$ sudo a2enmod headers

$ sudo service apache2 restart
$ sudo systemctl daemon-reload

$ sudo a2enmod ssl
$ sudo a2ensite default-ssl
$ sudo service apache2 reload

$ sudo cp /etc/php5/apache2/php.ini /etc/php5/apache2/php.ini.bak
$ sudo vim /etc/php5/apache2/php.ini
upload_max_filesize = 2G
post_max_size = 2G

$ sudo service apache2 restart

 

*MySQL/MariaDB
—————————————

$ sudo mysql_secure_installation
Enter current pasword for root, #taper le mot de passe root de MariaDB, qui devrait être le même que celui lors de l'installation du service
Change root password, #taper “n” pour NON
Remove anonymous users, #taper “y” pour OUI
Disallow root login remotely, #taper “y” pour OUI
Remove test database and access to it, #taper “y” pour OUI
Reload privilege tables no, #taper “y” pour OUI

$ sudo mysql -u root -p
Enter password: #taper le mot de passe root de MariaDB

MariaDB [(none)]> CREATE USER 'ownclouduser'@'localhost' IDENTIFIED BY 'password';
MariaDB [(none)]> CREATE DATABASE IF NOT EXISTS owncloudDB;
MariaDB [(none)]> GRANT ALL PRIVILEGES ON owncloudDB.* TO 'ownclouduser'@'localhost' IDENTIFIED BY 'password';
MariaDB [(none)]> quit

 

Si vous rencontrez un message du type:

Error 403: Forbidden
You don’t have permission to access/owncloud/ on this server

Il suffit d’ajouter dans le fichier de configuration de apache2 les lignes ci-dessous. Pour rappel, ce n’est pas nécessaire de le faire avec la version 8 de Owncloud.

$ sudo vim /etc/apache2/apache2.conf

<Directory /home/USERNAME/www-dev/>
 Options Indexes FollowSymLinks
 AllowOverride All
 Require all granted
</Directory>

Chap 5. Connection en SSH
—————————————–

*SSH serveur
---------------------------------------

raspi$ sudo vim /etc/ssh/ssh_config
ClientAliveInterval 60
$ sudo service sshd restart

*SSH client
---------------------------------------

monOrdi$ vim ~/.ssh/config
Host *
ServerAliveInterval 60

Modification/mise-à-jour de la passephrase:

monOrdi$ cd ~/.ssh/

monOrdi:~/.ssh $ ls 
id_rsa id_rsa.pub 
monOrdi:~/.ssh $ ssh-keygen -f id_rsa -p

Chap 4. Accès au serveur Web Owncloud à partir
—————————————–

Je vous propose de revoir ce chapitre pour les détails du comment pointer votre adresse IP publique à votre nom de domaine.

$ sudo cp  /etc/apache2/apache2.conf  /etc/apache2/apache2.conf.bak
$ sudo vim /etc/apache2/apache2.conf

Ajouter les deux lignes a la fin de la page

ServerSignature Off
ServerTokens Prod

$ sudo service apache2 restart

$ sudo vim ~/www-dev/owncloud/config/config.php
'trusted_domains' =>
  array (
    0 => 'localhost',
    1 => '10.1.2.3',
    2 => 'Mon.Adresse.IP.Publique',
    3 => '.netlib.re',
    4 => '.nsupdate.info',
  ),

$ sudo service apache2 restart

Voici le contenu de mon fichier /etc/apache2/site-enabled/owncloud.conf
=====================================================
Alias /owncloud "/home/USERNAME/www-dev/owncloud"

 <VirtualHost *:80>
 ServerName MaPage.netlib.re
 Redirect permanent / https://MaPage.netlib.re/
</VirtualHost>

<VirtualHost *:80>
 ServerName MaPage.nsupdate.info
 Redirect permanent / https://MaPage.nsupdate.info/
</VirtualHost>

# Web server configuration

<VirtualHost *:443>
 ServerName MaPage.netlib.re/
 ServerAlias MaPage.nsupdate.info/

 # SSL configuration
 #SSLEngine on

 # Restrict/deny/allow access to certain directories

 <Directory /home/USERNAME/www-dev/owncloud/>
 Options +FollowSymlinks
 AllowOverride All

 <IfModule mod_dav.c>
 Dav off
 </IfModule>

 SetEnv HOME /home/USERNAME/www-dev/owncloud
 SetEnv HTTP_HOME /home/USERNAME/www-dev/owncloud
 </Directory>

 <Directory "/home/USERNAME/www-dev/owncloud/data/">
 # just in case if .htaccess gets disabled
 Require all denied
 </Directory>

</VirtualHost>



# modern configuration, tweak to your needs
SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite !--Sortie Tronquee--!
SSLHonorCipherOrder     on
SSLCompression          off

# OCSP Stapling, only in httpd 2.3.3 and later
SSLUseStapling          on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLStaplingCache        shmcb:/var/run/ocsp(128000) 

 

Ci-dessous, quelques commandes utile pour vérifier les erreurs de syntax dans /var/apache2/site-enabled/owncloud.conf

$ sudo apache2ctl configtest
$ sudo journalctl | tail


$ systemctl status apache2.service 

Pour régler les problèmes annoncés dans la page d'administration de Owncloud, il suffit d'installer php5-apcu

$ sudo apt install php5-apcu 

Puis d'ajouter la ligne ci-dessous dans ~/www-dev/USERNAME/owncloud/config/config.php

<?php
$CONFIG = array (
!--Sortie Tronquee--!
'memcache.local' => '\OC\Memcache\APCu',
);
$ sudo service apache2 restart


Chap 7. Let's Encrypt (LE)
-----------------------------------------

Le nouveau système pour l'installation de LE est beaucoup plus simple qu'auparavant.


$ mkdir ~/Letsencrypt
$ cd Letsencrypt/
~/Letsencrypt $ wget https://dl.eff.org/certbot-auto
~/Letsencrypt $ chmod a+x certbot-auto $ ./certbot-auto

Puis faites un test de verification du renouvellement automatique.

~/Letsencrypt $ certbot-auto renew --dry-run 

Créer ensuite une règle dans crontab, qui va lancer automatiquement, une demande de renouvellement du certificat une fois tous les 12 heures.

$ sudo crontab -e
  #Minute Hour Day of Month Month Day of Week Command
  #(0-59) (0-23) (1-31) (1-12 or Jan-Dec) (0-6 or Sun-Sat)

crontab
* */12 * * * /home/matakasi/letsencrypt/certbot-auto renew --quiet --no-self-upgrade >> /var/log/apache2/letsencrypt-renew.log 2>&1

Référence:

Apache on Debian (other)

Publicités

Let’s Encrypt (LE)

Chap 1. Prise en main du RPi et installation de Mate sur un Raspbian
Chap 2. Installation de OwnCloud sur un Raspberry Pi
Chap 3. Sécuriser votre RPi
Chap 4. Accès au serveur Web Owncloud à partir de son nom de domaine
Chap 5. Connection SSH
Chap 6. Les fichiers journaux
Chap 7. Let’s Encrypt (LE)
Chap 8. Ajout d’un disque dur externe et migration de données
Chap 9. Suppression et ajout d’une interface graphique
Chap 10. Rappel sur les différentes étapes pour mettre en place un server dédié à Owncloud

Chap 7. Let’s Encrypt (LE)

Certificats & CA

Dans un des chapitres précédents, je vous ai fait installé un Certificat auto-signé (self-signed certificate). Ce qui fait qu’à chaque fois que vous vous connectez à votre page, vous auvez droit à un message d’avertissement comme ci-dessous.

036

Pour éviter ce genre de désagrément, il vous faudra un certificat signé par une autorité de certification (CA). Malgré le fait qu’un site présente un certificat auto-signé ou signé par un CA, garder en tête que rien ne prouve que le site visité est bel et bien émis par son propriétaire. Cependant, la présence de certificats apporte une assurance que les communications avec le serveur sont chiffrées.

Let’s Encrypt est un très bon choix de CA, puisque ce dernier offre des certificats gratuits qui de plus, ssont reconnus par la plupart des navigateurs internets, etc, sans oublier que le projet est soutenu par pas mal d’entreprises de poids, dont la liste se trouve ici.

Installation et configuration de Let’s Encrypt

Letsencrypt se trouve dans le dépot Jessie-backport de debian, mais nous n’allons pas l’installer avec la méthode conventionnelle.

Il faut savoir qu’une fois lestencrypt installé et, surtout en fonction des options d’installation choisies, ce dernier peut modifier les configurations de vos différents serveurs (serveur web, serveur owncloud, etc.) en fonction de ces besoins. Deuxième point à prendre en compte, c’est que cette application étant toujours en mode Béta, si vous n’êtes pas confortable avec l’utilisation de logiciels ou d’applications en mode Béta, passer votre chemin.

Le plugin Webroot, anciennement appelé simplefs, est la meilleure option à choisir, pour pouvoir garder entièrement le contrôle sur chacun de nos serveurs, sans que letsencrypt s’y mèle lors de l’installation, et même après. Avec ce plugin, le client letsencrypt ne fera rien de plus que ce qu’on lui demande de faire, c’est à dire de créer/ renouveller/révoquer un certificat.

Allons-y pour l’installation.

1. Créer un dossier pour l’installation de letsencrypt

$ sudo mkdir -p /var/www/html/owncloud/letsencrypt/.well-known/acme-challenge

Vérifier les permissions, puis restreindre au maximum ce qu’on peut.

$ ls -l /var/www/html/owncloud/
drwxr-xr-x 3 root root 4096 Apr 8 16:58 letsencrypt

$ sudo chown -R www-data:www-data /var/www/html/owncloud/letsencrypt

$ sudo chmod -R 750 /var/www/html/owncloud/letsencrypt

2. Lancer l’installation

Installer le paquet « git » dans un premier temps, qu’on utilisera pour télécharger le client Let’s Encrypt par la suite.

$ sudo apt-get install git

Télécharger une copie conforme du dossier officiel Let’s Encrypt à partir de github, à placer dans le dossier /opt.

Petite note concernant le dossier /opt, sur un système à base de debian, on y place généralement les logiciels tierces, non compris dans les dépôts officiels, dans ce dossier.

$ cd /opt

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

$ ls /opt/letsencrypt
  acme
  letshelp-letsencrypt
  CHANGES.rst                     LICENSE.txt
  CONTRIBUTING.md                 linter_plugin.py
  docker-compose.yml              MANIFEST.in
  Dockerfile                      pep8.travis.sh
  Dockerfile-dev                  README.rst
  docs                            readthedocs.org.requirements.txt
  examples                        setup.cfg
  letsencrypt                     setup.py
  letsencrypt-apache              tests
  letsencrypt-auto                tools
  letsencrypt-auto-source         tox.cover.sh
  letsencrypt-compatibility-test  tox.ini
  letsencrypt-nginx               Vagrantfile

Avant d’aller plus loin, vérifions que la commande letsencrypt-auto fonctionne correctement, en lançant la commande de demande d’aide par exemple (« letsencrypt-auto –help » ou « letsencrypt-auto –help all »).

/opt/letsencrypt$ sudo ./letsencrypt-auto --help [all]
!---Tronquée---!
ca-certificates is already the newest version.
gcc is already the newest version.
gcc set to manually installed.
python is already the newest version.
The following extra packages will be installed:
  dh-python libexpat1-dev libmpdec2 libpython-dev libpython2.7-dev
  libpython3-stdlib libpython3.4-minimal libpython3.4-stdlib
  python-chardet-whl python-colorama-whl python-distlib-whl
  python-html5lib-whl python-pip-whl python-pkg-resources
  python-requests-whl python-setuptools-whl python-six-whl
  python-urllib3-whl python2.7-dev python3 python3-minimal
  python3-pkg-resources python3-virtualenv python3.4 python3.4-minimal
Suggested packages:
  augeas-doc augeas-tools python-distribute python-distribute-doc
  python3-doc python3-tk python3-venv python3-setuptools python3.4-venv
  python3.4-doc binfmt-support
Recommended packages:
  libssl-doc
!---Tronquée---!
Installing Python packages...
Installation succeeded.

Comme vous pouvez le constater, letsencrypt installe automatiquement toutes les dépendances dont il a besoin.

L’option « all » après l’instruction « –help », est optionnel, mais nous fournit plus d’information concernant les options disponibles avec la commande lestencrypt.
Si vous avez un résultat comme ci-dessus avec l’option « –help » ou « –help all », c’est que vous êtes bon pour poursuivre la procédure d’obtention de certificats signés par le CA, Let’s Encrypt.

3. letsencrypt-auto

Letsencrypt est un progamme écrit en python, qui se charge d’installer et de mettre à jour automatiquement tous les outils dont il a besoin comme on l’a vu plus haut. Pour l’utiliser, il suffit juste de se placer dans le dossier /opt/letsencrypt, puis de lancer la commande « ./letsencrypt-auto ».
Pour information, durant la phase Béta, le nombre de certificats émis par le CA (Let’s Encrypt), est assez limité. De ce fait, avant de lancer votre requête, faites un test pour vérifié que votre requête serait accordée ou non.

N’oubliez pas de désactiver la redirection http vers https, sinon vous allez avoir droit un message d’erreur du type:

044

Pour ce faire, ajouter un dièse ‘#’ devant l’instruction de redirection.

$ sudo vim /etc/apache2/site-availables/owncloud.conf

  ServerName linuxintosh.nsupdate.info
# Redirect permanent / https://.nsupdate.info

  LogLevel info ssl:warn

  ErrorLog /var/log/apache2/error.log
  CustomLog /var/log/apache2/access.log combined

N’oubliez pas de réactiver la redirection, une fois le certificat final obtenu. Ne vous inquiétez pas, je vais vous le rappeler un peu plus tard dans ce chapitre.

4. Test de vérification avant installation du certificat

Poursuivons notre aventure! Faisons un test de requête de certificat.

/opt/letsencrypt$ sudo letsencrypt-auto certonly --test-cert

Selectionner l’option 2 « Place files in webroot directory (webroot)

038

Entrez votre adresse email

039

Accepter les conditions d’utilisation

040

Entrer l’URL, .netlib.re par exemple, pour accéder à votre serveur Owncloud

041

Entrer le chemin du webroot, /var/www/html (sur Debian par défaut)

042

043

Vérifier le résultat

045

# ls /etc/letsencrypt/live/.netlib.re
  cert.pem chain.pem fullchain.pem privkey.pem

Si tout est bon et que le résultat de ce test vous convient, lancer maintenant l’installation.

5. Installation du certificat

Rappeler vous que je me suis enregistré sur deux domaines différents (netlib.re, et nsupdate.info qui est l’alias du premier). Il me faut donc un seul certificat qui serait valide pour ces deux domaines à la fois.

Afin d’automatiser un peu plus les la demande de certificat et d’éviter de retaper toutes les informations comme lors du test, j’ai ajouté d’autres paramètres à la commande letsencrypt-auto.

/opt/letsencrypt$ sudo ./letsencrypt-auto certonly \
  --agree-tos \
  --webroot \
  --webroot-path /var/www/html/ \
  --email admin@example.com \
  --domains .netlib.re \
  --domains .nsupdate.info

Pour une version allégée de la même commande,

/opt/letsencrypt $ sudo ./letsencrypt-auto certonly \
  --agree-tos \
  --webroot \
  -w /var/www/html/ \
  -m admin@example.com \
  -d .netlib.re \
  -d .nsupdate.info

046

Le message dit que vous avez déjà un certificat associé au même nom de domaine que celui entré manuellement, puis nous demande ce qu’on veut faire. J’ai choisi l’option 2, qui va remplacer/renouveller le certificat existant.

Si tout s’est bien passé, vous devriez avoir un message avec la date d’expiration de votre certificat, comme ci-dessous.

047

Le certificat signé par le CA va se placer ensuite dans le dossier /etc/letsencrypt/live/.

6. Vérification

Vérifions justement le contenu du dossier /etc/letsencrypt/live/, dans lequel doit se trouver toutes les clés générées par les commandes ‘letsencrypt’ ou ‘letsencrypt-auto’.

$ sudo ls -a /etc/letsencrypt/live/.netlib.re/
  . .. cert.pem chain.pem fullchain.pem privkey.pem
  • privkey.pem – clé privée à ne jamais partager avec personne
  • cert.pem – certificat du serveur uniquement
  • chain.pem – certificat pour root et intermédiaire uniquement
  • fullchain.pem – ensemble de tous les certificats (chain.pem + cert.pem)
$ sudo ls -l /etc/letsencrypt/live/.netlib.re/
  total 0
  lrwxrwxrwx 1 root root 45 Apr 19 22:58 cert.pem -> ../../archive/linuxintosh.netlib.re/cert3.pem
  lrwxrwxrwx 1 root root 46 Apr 19 22:58 chain.pem -> ../../archive/linuxintosh.netlib.re/chain3.pem
  lrwxrwxrwx 1 root root 50 Apr 19 22:58 fullchain.pem -> ../../archive/linuxintosh.netlib.re/fullchain3.pem
  lrwxrwxrwx 1 root root 48 Apr 19 22:58 privkey.pem -> ../../archive/linuxintosh.netlib.re/privkey3.pem 

$ sudo ls -l /etc/letsencrypt/archive/.netlib.re/
  total 48
  -rw-r--r-- 1 root root 1870 Apr 8 19:11 cert1.pem
  -rw-r--r-- 1 root root 1850 Apr 8 19:51 cert2.pem
  -rw-r--r-- 1 root root 1850 Apr 19 22:58 cert3.pem
  -rw-r--r-- 1 root root 1675 Apr 8 19:11 chain1.pem
  -rw-r--r-- 1 root root 1647 Apr 8 19:51 chain2.pem
  -rw-r--r-- 1 root root 1647 Apr 19 22:58 chain3.pem
  -rw-r--r-- 1 root root 3545 Apr 8 19:11 fullchain1.pem
  -rw-r--r-- 1 root root 3497 Apr 8 19:51 fullchain2.pem
  -rw-r--r-- 1 root root 3497 Apr 19 22:58 fullchain3.pem
  -rw-r--r-- 1 root root 1704 Apr 8 19:11 privkey1.pem
  -rw-r--r-- 1 root root 1704 Apr 8 19:51 privkey2.pem
  -rw-r--r-- 1 root root 1708 Apr 19 22:58 privkey3.pem 

$ sudo ls -l /etc/letsencrypt/keys/
  total 12
  -rw------- 1 root root 1704 Apr  8 19:11 0000_key-letsencrypt.pem
  -rw------- 1 root root 1704 Apr  8 19:51 0001_key-letsencrypt.pem
  -rw------- 1 root root 1708 Apr 19 22:58 0002_key-letsencrypt.pem

Pour information, /etc/letsencrypt/archive et /etc/letsencrypt/keys contiennent toutes les anciennes clés et certificats, par contre /etc/letsencrypt/live n’en contient que la dernière version.

Vérifier ensuite qu’il n’y a pas de fichiers qui traine dans le dossier .well-known/acme-challenge/. Si c’est le cas, supprimer tout ce qu’il contient comme information.

$ sudo -s
# rm /var/www/owncloud/letsencrypt/.well-known/acme-challenge/*

 

Mise-à-jour des informations de Owncloud

1. Réactiver la redirection HTTP vers HTTPS

Une fois que votre certificat émis, supprimer le dièse ‘#’ devant « Redirect » afin de pouvoir rediriger de nouveau, les traffics HTTP vers HTTPs.

$ sudo vim /etc/apache2/site-availables/owncloud.conf

  ServerName linuxintosh.nsupdate.info
  Redirect permanent / https://.nsupdate.info

  LogLevel info ssl:warn

  ErrorLog /var/log/apache2/error.log
  CustomLog /var/log/apache2/access.log combined

2. Mettre à jour les informations du vHost avec le nouveau certificat signé

Désactiver les certificats auto-signés puisqu’on n’en a plus besoin, puis ajouter le chemin d’accès aux clés et chaînes généré par Let’s Encrypt, dans le fichier de configuration de owncloud.

$ sudo vim /etc/apache2/sites-available/ownCloud.conf

  # Self-signed certificate
  #
  #SSLCertificateFile /etc/ssl/localcerts/owncloud.pem
  #SSLCertificateKeyFile /etc/ssl/localcerts/owncloud.key

  # Let's Encrypt certificate
  #
  SSLCertificateFile /etc/letsencrypt/live/.netlib.re/cert.pem
  SSLCertificateKeyFile /etc/letsencrypt/live/.netlib.re/privkey.pem
  SSLCertificateChainFile /etc/letsencrypt/live/.netlib.re/fullchain.pem

  # Certificate signed by CA
  #
  #SSLCACertificateFile /Path/to/CA/Certificate
  #SSLVerifyDepth 2

3. Vérifier l’état de connection à votre page

Vous devriez pouvoir accéder directement à votre page, sans avoir à valider quoi que ce soit.

048
Navigateur – Chromium

049

 Navigateur – Firefox

4. Un petit test de plus!

Une fois n’est pas coutume, lancer de nouveau un test sur Qualys SSL Labs et voyer le résultat.

060
Cette fois ci, le test passe et j’obtient un A+ comme note. Youpiii!

Quelques informations supplémentaires

1. Renouvellement du certificat

Le certificat signé par Let’s Encrypt n’est valide que pour une durée de 90jours maximum. Il est donc préférable de s’y prendre un peu à l’avance pour mettre à jour notre certificat. Vous pouvez le faire de façon manuelle ou automatique.

Avec la méthode manuelle, taper dans une console,

/opt/letsencrypt$ sudo ./letsencrypt-auto renew
  Checking for new version...
  Requesting root privileges to run letsencrypt...
  sudo /home/USERNAME/.local/share/letsencrypt/bin/letsencrypt renew

  -------------------------------------------------------------------------------
  Processing /etc/letsencrypt/renewal/.netlib.re.conf
  -------------------------------------------------------------------------------

  The following certs are not due for renewal yet:
  /etc/letsencrypt/live/.netlib.re/fullchain.pem (skipped)
  No renewals were attempted.

Par contre je n’ai pas réussi à faire fonctionner le renouvellement automatique avec CRON. J’ai essayé plusieurs fois, mais j’ai des doutes sur la fonctionnalité de la commande ci-dessous, bien qu’en théorie, çà devrait marcher.

$ sudo crontab -e
  #Minute Hour Day of Month Month Day of Week Command
  #(0-59) (0-23) (1-31) (1-12 or Jan-Dec) (0-6 or Sun-Sat)

  crontab
  * * */1 * * /opt/letsencrypt/letsencrypt-auto renew >> /var/log/apache2/letsencrypt-renew.log 2>&1

Ici, Cron doit exécuter la commande « letsencrypt-auto renew » une fois par jour. A chaque exécution de cette commande, je devrais avoir une information dans le fichier /var/log/apache2/letsencrypt-renew.log, ainsi qu’un email doit être envoyé du serveur, mais nada.
J’ai noté qu’en y apportant une petite modification dans la commande, comme par exemple, si je veux effectuer une requête de renouvellement de certificats à la minute, la commande semble fonctionner après quelques bidouilles. Je ne vais pas trop tarder dessus. Je pense avoir effectué suffisament de test pour vérifier que la commande de renouvellement de certificat fonctionne sans problème, mais couplée avec cron, rien ne va plus!

Voici ce que j’ai réussi à récupérer dans les logs quand çà fonctionne.

/var/log/apache2$ cat letsencrypt-renew.log
  Checking for new version...
  Requesting root privileges to run letsencrypt...
  /root/.local/share/letsencrypt/bin/letsencrypt renew

  -------------------------------------------------------------------------------
  Processing /etc/letsencrypt/renewal/.netlib.re.conf
  -------------------------------------------------------------------------------

  The following certs are not due for renewal yet:
  /etc/letsencrypt/live/.netlib.re/fullchain.pem (skipped)
  No renewals were attempted.

Dans les notes sur la page officielle de Let’s Encrypt, il est dit qu’ils vont sortir un script bientôt pour automatiser la tâche de renouvellement des certificats.

Sinon, utiliser l’installeur Apache ou Nginx au lieu de Webroot comme j’ai procédé dans cet article. Ces installeurs vont gérer directement le renouvellement des certificats, sans que vous ayez à vous soucier de quoi que ce soit.

2. Révocation du certificat

Si pour une raison quelconque, vous souhaitez révoquer votre certificat de Let’s Encrypt, taper la commande ci-dessous en précisant le nom de domaine concerné.

/opt/letsencrypt$ sudo ./letsencrypt-auto revoke --cert-path /etc/letsencrypt/live/.netlib.re/cert.pem
  Checking for new version...
  Requesting root privileges to run letsencrypt...
  /root/.local/share/letsencrypt/bin/letsencrypt revoke --cert-path /etc/letsencrypt/live/.netlib.re/cert.pem

Vous n’aurez pas de confirmation de révocation du certificat. Par contre, si vous retaper exactement la même commande, vous allez avoir un message vous prévenant que le certificat a déjà été révoqué.

/opt/letsencrypt$ sudo ./letsencrypt-auto revoke --cert-path /etc/letsencrypt/live/linuxintosh.netlib.re/cert.pem
  Checking for new version...
  Requesting root privileges to run letsencrypt...
  /root/.local/share/letsencrypt/bin/letsencrypt revoke --cert-path /etc/letsencrypt/live/.netlib.re/cert.pem
  An unexpected error occurred:
  The request message was malformed :: Certificate already revoked
  Please see the logfiles in /var/log/letsencrypt for more details.

Vous pouvez le vérifier en accédant à votre page.

061

3. Mise-à-jour du client letsencrypt

Pour mettre à jour le client letsencrypt, accéder au dossier /opt/letsencrypt, puis taper la commande « git pull ».

$ cd /opt/letsencrypt
$ sudo git pull

N’oubliez pas que le client Let’s Encrypt est toujours en mode Béta. Prennez donc le temps de visiter la page officielle de Let’s Encrypt pour lire les informations sur les dernières mise-à-jour.

Les articles ci-dessous sont très intéressants. Je ne peux que vous le recommander. Si l’anglais vous rébute, utilisez l’outil itool de Google pour traduire ces pages.

Why Use a Certificate?
Fishing for Hackers: Analysis of a Linux Server Attack

Sources et Références

User script location in Debian
Fully automate Let’s Encrypt certificate on Debian using central webroot Folder
Client certificate authentication
Apache directives
Set server wide ssl configuration
Install Let’s Encrypt to Create SSL Certificates
Crontab generator
Missing Docs for cert.pem, chain.pem, fullchain.pem, etc #608
Where are my certificates?