=== Introduction ===
Ce document explique la marche à suivre pour installer sur un Serveur SME-9.1, un certificat SSL émis par l'autorité de certification Let's Encrypt.

Ce document s'est inspiré de la contribution Letsencrypt produite par Flep, Hfwang, DanB35 et Brianr. Vous pouvez consulter cette contribution à la page [https://wiki.contribs.org/Letsencrypt https://wiki.contribs.org/Letsencrypt].

Référence: [https://fr.wikipedia.org/wiki/Let's_Encrypt https://fr.wikipedia.org/wiki/Let's_Encrypt].

Let's Encrypt est une autorité de certification lancée le 3 décembre 2015 (''Bêta Version Publique''). Cette autorité fournit des certificats gratuits X.509 pour le protocole cryptographique TLS au moyen d'un processus automatisé destiné à se passer du processus complexe actuel impliquant la création manuelle, la validation, la signature, l'installation et le renouvellement des certificats pour la sécurisation des sites Internet.

'''NOTE:'''

- Un document PDF expliquant plus en détails les procédures de test et de vérification est disponible à l'adresse: https://www.micronator.org/PDF/SME/RF-232_SME-9.1_LetsEncrypt/RF-232_SME-9.1_LetsEncrypt.sh.pdf.<br/>
- Pour l'installation d'un Serveur SME-9.x, voir: https://www.micronator.org/?page_id=236.<br/>
- Pour installer MediaWiki sur un Serveur SME9.x, voir: https://www.micronator.org/PDF/MediaWiki/RF-232_SME-9.1_Mediawiki.pdf.<br/>
- Pour les autres documents disponibles, voir: https://www.micronator.org/?page_id=275.

=== Limites ===
'''90 jours'''

Les certificats Let's Encrypt sont valides pour 90 jours. Elle recommande de les renouveler tous les 60 jours pour avoir une certaine marge de manoeuvre.

'''5/7'''

En date du 2015-12-03 16:46:08 UTC:

* Limite de 5 certificats par domaine, dans une fenêtre de 7 jours.
* Limite de 10 enregistrements par IP, toutes les 3 heures.

Référence: [https://community.letsencrypt.org/t/public-beta-rate-limits/4772 https://community.letsencrypt.org/t/public-beta-rate-limits/4772].

<nowiki>*</nowiki> Certificats par domaine signifie 5 émissions de certificat et non pas combien de domaines au sein d'un certificat multi-domaines SAN.

<nowiki>** </nowiki>Un certificat multi-domaines SAN ayant <u>domain1</u>.com, <u>www.domain1</u>.com, <u>domain2</u>.com, <u>www.domain2</u>.com, <u>toto</u>.info, <u>titi</u>.org est compté comme 1 certificat, mais on ne peut renouveler ce certificat multi-domaines plus de 5 fois par période de 7 jours?

<nowiki>*** </nowiki>Il n'y a pas de limites pour le nombre de domaines contenus dans un certificat multi-domaines SAN ou plus précisément jusqu'au maximum standard de 100. Let's Encrypt a choisi cette limite de 100 sur une base de prudence, car il semble que lorsqu'on en obtient plus de 100, certains navigateurs Web ont un comportement erratique. Let's Encrypt peut probablement augmenter cette limite si quelqu'un en fait la demande.

=== Mode Officiel vs TEST (staging) ===

'''Fichier de configuration'''

'''Certificat de TEST'''

Le fichier de configuration pour une demande de certificat de test doit spécifier la CA '''acme-staging''' qui seule, émet ces certificats de test pour '''Let's Encrypt'''.

 <nowiki>#!/bin/bash</nowiki>
 <nowiki># config.sh</nowiki>
 <nowiki> </nowiki>
 '''CA="https://acme-staging.api.letsencrypt.org/directory"  <nowiki># CA pour mode TEST.</nowiki>'''
 <nowiki> </nowiki>
 WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"
 HOOK="/etc/letsencrypt.sh/letsencrypt-hook.sh"
 <nowiki>#</nowiki><nowiki>#</nowiki> E-mail to use during the registration (default: <unset>)
 CONTACT_EMAIL="admin@<span style="color: #ff0000;">'''nom-de-votre-domaine'''</span>"

Il est fortement recommandé de commencer avec un certificat de test pour valider toutes les manipulations avant de demander un certificat officiel.

Après avoir créé le fichier de configuration de test (''/etc/letsencrypt.sh/<span style="color: #ff0000;">config-test.sh</span>''), la marche à suivre est exactement comme celle pour une demande officielle, sauf qu'il faut spécifier le fichier de configuration avec le paramètre <span style="color: #ff0000;">--config</span>. 

 # /etc/letsencrypt.sh/letsencrypt.sh -c <span style="color: #ff0000;">'''--config'''</span> /etc/letsencrypt.sh/<span style="color: #ff0000;">'''config-test.sh'''</span>

On peut aussi forcer le renouvellement avec le paramètre <span style="color: #ff0000;">--force</span>.

 # /etc/letsencrypt.sh/letsencrypt.sh -c <span style="color: #ff0000;">'''--config'''</span> /etc/letsencrypt.sh/config-test.sh <span style="color: #ff0000;">'''--force'''</span>

IMPORTANT: Après avoir effectué tous les tests nécessaires, il faut absolument effacer la clé de compte, <u>/etc/letsencrypt.sh/private_key.pem</u>

 rm /etc/letsencrypt.sh/private_key.pem

sinon l'émetrice officielle "CA acme-v01" répondra qu'aucun compte enregistré chez-elle ne correspond à la clé utilisée et expliquera sa réponse avec: {"type":"urn:acme:error:unauthorized","detail":"<u>No registration exists matching provided key</u>","status":403}.

'''Certificat officiel'''

Pour une demande de certificat officiel, il est inutile de spécifier un fichier de configuration car par défaut c'est le fichier '''config.sh''' qui est utilisé.

Fichier '''config.sh''' de la configuration standard.

 <nowiki>#!/bin/bash</nowiki>
 <nowiki># config.sh</nowiki>
 <nowiki> </nowiki>
 WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"
 HOOK="/etc/letsencrypt.sh/letsencrypt-hook.sh"
 <nowiki>#</nowiki><nowiki>#</nowiki> E-mail to use during the registration (default: <unset>)
 CONTACT_EMAIL="admin@<span style="color: #ff0000;">'''nom-de-votre-domaine'''</span>"

=== Aide ===
Pour afficher l'aide du '''client letsencrypt.sh'''.

 letsencrypt.sh --help

== Installation du client ==
=== git ===
Avec PuTTY, on se logue à la console du serveur de notre domaine en tant qu'usager root et on installe git.

 <nowiki># </nowiki>yum -y install git

=== Téléchargement ===
Un sous-répertoire letsencrypt.sh va être créé dans le répertoire dans lequel on lance la commande git. On se rend donc dans /etc, car on veut que le sous-répertoire '''letsencrypt.sh''' y soit créé.

 <nowiki># </nowiki>'''cd /etc'''

On télécharge le client.

 <nowiki># </nowiki>'''git clone https://github.com/lukas2511/letsencrypt.sh'''

On sécurise le fichier '''letsencrypt.sh'''.

 <nowiki># </nowiki>'''chmod 700 /etc/letsencrypt.sh/letsencrypt.sh'''

== Création des fichiers et répertoires requis ==
=== Répertoire des défis ===
Le greffon webroot fonctionne en créant un fichier temporaire incluant chacun des domaines demandés dans ${webroot-path}/.well-known/acme-challenge/. Le serveur de validation de Let's Encrypt fera des requêtes HTTP pour valider que tous les noms de domaines/CNAME contenus dans ce fichier pointent vers le serveur exécutant letsencrypt.sh.

On crée le répertoire des défis (''challenge'') afin de prouver que le serveur est bien celui qu'il prétend être.

 <nowiki># </nowiki>mkdir -p /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge

=== Gabarit personnalisé ===
Nous avons besoin d'un gabarit personnalisé (''custom template'') pour indiquer à Apache le répertoire acme-challenge. On crée le répertoire pour le gabarit personnalisé.

 <nowiki># </nowiki>'''mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf'''

Pour le gabarit personnalisé, on crée le fichier VirtualHosts40ACME et on y insère son contenu.

 '''cat > /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts40ACME <<'EOT''''
 '''<nowiki>#</nowiki><nowiki>#</nowiki> Alias for letsencrypt'''
 '''<nowiki>#</nowiki><nowiki>#</nowiki>'''
 '''Alias /.well-known/acme-challenge /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge'''
 '''<nowiki> </nowiki>'''
 '''EOT'''

On développe le gabarit personnalisé.

 <nowiki># </nowiki>'''expand-template /etc/httpd/conf/httpd.conf'''

On redémarrage leservice httpd-e-smith

 <nowiki># </nowiki>'''service httpd-e-smith restart'''

=== Fichiers de configuration ===

'''config.sh'''

On crée le fichier config.sh et on y insère son contenu. Prendre tout le contenu de l'encadré pour la commande.

 cat > /etc/letsencrypt.sh/config.sh <<'EOT'
 <nowiki>#!/bin/bash</nowiki>
 <nowiki># config.sh</nowiki>
 <nowiki> </nowiki>
 WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"
 HOOK="/etc/letsencrypt.sh/letsencrypt-hook.sh"
 <nowiki># E-mail to use during the registration (default: <unset>)</nowiki>
 CONTACT_EMAIL<nowiki>="admin@</nowiki><u>'''micronator.org'''</u>"
 <nowiki> </nowiki>
 EOT

* Attention au domaine de l'adresse courriel CONTACT_EMAIL="admin@<u>'''micronator.org'''</u>" ci-dessus. Il faut le remplacer par votre domaine.

On sécurise le fichier.

 <nowiki># </nowiki>'''chmod 700 /etc/letsencrypt.sh/config.sh'''

'''domains.txt'''

Dans ce fichier, on énumère, <u>sur une seule ligne</u>, chacun des noms des domaines/CNAME qu'on veut couvrir avec notre certificat; chaque nom doit être séparé par un espace.

On crée le fichier et on y insère son contenu.

 cat > /etc/letsencrypt.sh/domains.txt <<'EOT'
 www.micronator.org micronator.org dorgee.micronator.org mail.micronator.org
 EOT

Le certificat '''SAN''' sera émis pour le premier domaine de la ligne. Ici le certificat sera émis pour le site www.micronator.org.

=== Script de point d'entrée ===
Lorsqu'un certificat est émis ou renouvelé, vous aurez besoin d'un script de point d'entrée pour mettre à jour les paramètres de modSSL et déclencher le rechargement des services système.

On crée le fichier letsencrypt-hook.sh et on y insère son contenu.

 cat > /etc/letsencrypt.sh/letsencrypt-hook.sh <<'EOT'
 <nowiki>#!/bin/bash</nowiki>
 <nowiki> </nowiki> 
 if [ $1 = "deploy_cert" ]; then
   KEY=$3
   CERT=$4
   CHAIN=${5/fullchain.pem/chain.pem}
 <nowiki>#</nowiki>
   /sbin/e-smith/db configuration setprop modSSL key $KEY
   /sbin/e-smith/db configuration setprop modSSL crt $CERT
   /sbin/e-smith/db configuration setprop modSSL CertificateChainFile $CHAIN
   /sbin/e-smith/signal-event domain-modify
   /sbin/e-smith/signal-event email-update
   /sbin/e-smith/signal-event ibay-modify
 fi
 EOT

On sécurise et on rend le fichier du script exécutable.

 <nowiki># </nowiki>'''chmod 700 /etc/letsencrypt.sh/letsencrypt-hook.sh'''

Nous pouvons maintenant demander un certificat officiel.

== Demande d'un certificat officiel ==

=== Manuel ===

'''Lancement de la demande'''

 '''# /etc/letsencrypt.sh/letsencrypt.sh -c '''
 
 # INFO: Using main config file /etc/letsencrypt.sh/config.sh
 + Generating account key...
 + Registering account key with letsencrypt...
 Processing www.micronator.org with alternative names: micronator.org dorgee.micronator.org mail.micronator.org
  + Signing domains...
  + Creating new directory /etc/letsencrypt.sh/certs/www.micronator.org ...
  + Generating private key...
  + Generating signing request...
  + Requesting challenge for www.micronator.org...
  + Requesting challenge for micronator.org...
 ...
  + Responding to challenge for www.micronator.org...
  + Challenge is valid!
  + Responding to challenge for micronator.org...
 ...
  + Requesting certificate...
  + Checking certificate...
  + Done!
  + Creating fullchain.pem...

* Le client letsencrypt.sh a utilisé de fichier de configuration par défaut config.sh.
* Il a créé une clé de compte, + Generating account key... 
* Il l'a enregistrée chez Let's Encrypt, + Registering account key with letsencrypt...
* La CA acme-v01, l'Émettrice officielle, a créé un compte-usager <u>au nom de la nouvelle clé de compte</u>.

=== Vérification du nouveau certificat ===
'''Console du serveur'''

On vérifie le répertoire '''/etc/letsencrypt.sh/certs/www.micronator.org/'''.

 # '''ls -ls /etc/letsencrypt.sh/certs/www.micronator.org/'''
 
 total 28
 4 -rw------- 1 root root 2118 12 mars  15:59 '''cert-1457816391.csr'''
 4 -rw------- 1 root root 2598 12 mars  16:00 '''cert-1457816391.pem'''
 0 lrwxrwxrwx 1 root root   19 12 mars  16:00 cert.csr -> cert-1457816391.csr
 0 lrwxrwxrwx 1 root root   19 12 mars  16:00 cert.pem -> cert-1457816391.pem
 4 -rw------- 1 root root 1675 12 mars  16:00 '''chain-1457816391.pem'''
 0 lrwxrwxrwx 1 root root   20 12 mars  16:00 chain.pem -> chain-1457816391.pem
 8 -rw------- 1 root root 4273 12 mars  16:00 fullchain-1457816391.pem
 0 lrwxrwxrwx 1 root root   24 12 mars  16:00 fullchain.pem -> fullchain-1457816391.pem
 4 -rw------- 1 root root 3243 12 mars  16:00 '''privkey-1457796476.pem'''
 4 -rw------- 1 root root 3243 12 mars  16:00 privkey-1457796476.pem_T_2016-03-12_10h27
 0 lrwxrwxrwx 1 root root   22 12 mars  16:00 privkey.pem -> '''privkey-1457796476.pem'''
 #

'''modSSL'''

Les propriétés de modSSL <u>ont été modifiées</u>.

 <nowiki># </nowiki>'''config show modSSL'''
 <nowiki> </nowiki>
 modSSL=service
     '''CertificateChainFile'''<nowiki>=/etc/letsencrypt.sh/certs/www.micronator.org/chain.pem</nowiki>
     TCPPort=443
     access=public
     '''crt'''<nowiki>=/etc/letsencrypt.sh/certs/www.micronator.org/cert.pem</nowiki>
     '''key'''<nowiki>=/etc/letsencrypt.sh/certs/www.micronator.org/privkey.pem</nowiki>
     status=enabled

'''Fichier pem'''

On affiche la date de création du fichier '''pem'''.

 <nowiki># </nowiki>'''ls -ls /home/e-smith/ssl.pem/dorgee.micronator.org.pem'''
 <nowiki> </nowiki>
 8 -rw-r--r-- 1 root root 7897 '''12 mars  16:00''' /home/e-smith/ssl.pem/dorgee.micronator.org.pem

Le fichier pem vient tout juste d'être recréé, il a la même date et heure que le fichier cert.pem. Le nouveau certificat a été installé et il est fonctionnel.

'''Qualys SSL Lab'''

Sur le site [https://www.ssllabs.com/ssltest/ https://www.ssllabs.com/ssltest/], on entre le FQDN de notre premier domaine | Submit et on vérifie.

'''Navigateur'''

La '''CA''' '''acme-v01''' étant dans le magasin des '''CA''' et de ce fait reconnue, le certificat est automatiquement accepté.

On clique l'icône verte à gauche de l'URL | on clique l'icône '''>''' à droite à l'écran qui s'affiche | '''Plus d'informations''' | '''Afficher le certificat''' | onglet '''Détails''' | '''Nom alternatif du sujet du certificat''' et on voit tous les CNAME du certificat.

'''Note pour Internet Explorer & l'antivirus Avast'''

La protection Courriel/Web d'Avast! doit être capable de balayer votre trafic Web avant de l'envoyer au fureteur. Le balayage d'un connecteur logiciel (''socket'') chiffré TLS exige qu'Avast! puisse déchiffrer la connexion. Il n'y a pas d'autre moyen pour Avast!, de déchiffrer la connexion, que de générer son propre certificat et de le signer avec un certificat racine d'Avast déjà installé sur le système. De cette façon, Avast! peut vérifier la connexion.

Même si on importe le fichier du certificat de Let's Encrypt dans IE, ce dernier persiste à utiliser celui d'Avast!.

'''Conclusion'''

Le client letsencrypt.sh fonctionne très bien pour un demande de certificat officiel. Il en va de même pour tous nos fichiers de configuration. Avec le script de point d'entrée: les propriétés de modSSL ont été modifiées, les changements signalés et le certificat installé.

== Renouvellement ==
'''Limite de 90 jours'''

Les certificats Let's Encrypt sont valides pour 90 jours. Il est recommandé de les renouveler à tous les 60 jours afin d'avoir une certaine marge de manoeuvre.

=== Manuel ===

'''Situation actuelle'''

* Aucun ajout d'un nouveau domaine ou CNAME.
* Aucune modification des fichiers de configuration.
* Le dernier certificat officiel est toujours valide (''plus longtemps que 30 jours'') et il n'a pas été révoqué.

Si nous lancions le client letsencrypt.sh, il nous retournerait ce qui suit.

 <nowiki># </nowiki>'''/etc/letsencrypt.sh/letsencrypt.sh -c'''
 <nowiki> </nowiki>
 <nowiki># INFO: Using main config file /etc/letsencrypt.sh/config.sh</nowiki>
 Processing www.micronator.org with alternative names: micronator.org dorgee.micronator.org mail.micronator.org 
  + Checking domain name(s) of existing cert... unchanged.
  + Checking expire date of existing cert...
  + Valid till Jun 10 20:01:00 2016 GMT (Longer than 30 days). <span style="color: #ff0000;">'''Skipping!'''</span>

Au début de l'exécution, le client letsencrypt.sh:

# a examiné le fichier config.sh et n'a vu aucune modification,
# a examiné le fichier /etc/letsencrypt.sh/domains.txt et vu qu'il n'avait pas été modifié par rapport au dernier certificat: unchanged,
# a vérifié la validité du certificat et vu qu'il était encore valide pour plus de 30 jours: Longer than 30 days,
# a affiché la dernière ligne du message: <span style="color: #ff0000;">'''Skipping!'''</span>, et <u>il s'est arrêté </u>sans aller plus loin,
# arrêté, il ne s'est pas rendu au script de point d'entrée<nowiki>;</nowiki> les propriétés de modSSL sont demeurées inchangées et il n'y a eu aucun changement de signaler.

=== Manuel forcé ===

Ne voulant pas atteindre la limite '''5/7''', nous laissons le renouvellement de votre dernier certificat '''officiel''' et valide à votre entière discrétion en utilisant le paramètre '''--force'''.

 <nowiki># </nowiki>'''/etc/letsencrypt.sh/letsencrypt.sh -c''' <span style="color: #ff0000;">'''--force'''</span>

=== Automatique ===

'''Répertoire pour le gabarit personnalisé'''

Création du répertoire.

 <nowiki># </nowiki>'''mkdir -p /etc/e-smith/templates-custom/etc/crontab'''

'''Création de la tâche cron'''

Comme nous l'avons vu précédemment, lorsque le certificat est encore valide pour plus de 30 jours, le client letsencrypt.sh s'arrête avant de demander un renouvellement et ainsi, il n'incommode pas inutilement les serveurs de Let's Encrypt.

On crée le fichier de la tâche '''cron''' et on y insère son contenu. Il s'exécutera quotidiennement à '''02H15'''. Prendre tout le contenu de l'encadré pour la commande.

 cat > /etc/e-smith/templates-custom/etc/crontab/renouvelerSSL <<'EOT'
 <nowiki> </nowiki>
 <nowiki>#</nowiki>
 <nowiki># Tâche</nowiki> cron qui lance le client letsencrypt.sh pour le renouvellement du certificat
 <nowiki># </nowiki>Elle s'exécutera quotidiennement à 02H15
 <nowiki>#</nowiki>
 <nowiki># </nowiki>Si le certificat est encore valide pour plus de 30 jours, qu'il n'y a eu aucune
 <nowiki># modification des fichiers de configuration et aucun changement dans le fichier</nowiki>
 <nowiki># domains.txt, le client ne fera rien et attendra son prochain lanc</nowiki>ement.
 <nowiki># </nowiki>
 <nowiki># Si le certificat est encore valide pour </nowiki>moins de 30 jours, le client:
 <nowiki># 1) demandera un renouvellement du certificat,</nowiki>
 <nowiki># 2) ajustera les pointeurs des fichiers du certificat,</nowiki>
 <nowiki># 3) appellera le script de point d'entrée qui ajustera les paramètres de modSSL</nowiki>
 <nowiki># </nowiki>   et signalera les changements puis, le script letsencrypt.sh s'arrêtera.
 <nowiki># </nowiki>
 <nowiki># ┌───────────── min (0 - 59) </nowiki>
 <nowiki># │ ┌────────────── </nowiki>heure (0 - 23)
 <nowiki># │ │ ┌─────────────── </nowiki>jour du mois (1 - 31)
 <nowiki># │ │ │ ┌──────────────── </nowiki>mois (1 - 12)
 <nowiki># │ │ │ │ ┌───────────────── </nowiki>jour de la semaine (0 - 6) (0 à 6 sont de dimanche à samedi,
 <nowiki># │ │ │ │ │ </nowiki>                 7 est dimanche, même que 0)
 <nowiki># │ │ │ │ │</nowiki>
 <nowiki># * * * * * </nowiki> [usager] commande à exécuter
 <nowiki>#</nowiki>
 15 02 * * * root /etc/letsencrypt.sh/letsencrypt.sh -c
 <nowiki> </nowiki>
 EOT

L'heure et le jour du mois peuvent être choisis à votre discrétion – nous avons choisi un moment qui ne devrait pas en être un de pointe (''tel le premier du mois'') dans l'espoir de réduire la charge des serveurs de '''Let's Encrypt'''. Étant donné que les certificats ont une durée de vie limitée à 90 jours, ce script aura amplement le temps pour renouveler notre certificat.

On sécurise le fichier.

 <nowiki># </nowiki>'''chmod 600 /etc/e-smith/templates-custom/etc/crontab/renouvelerSSL'''

On développe le gabarit personnalisé.

 <nowiki># </nowiki>'''expand-template /etc/crontab'''

On redémarre le démon '''crond'''.

 <nowiki># </nowiki>'''service crond restart'''

'''Courriel de notification'''

Lors d'un lancement de la tâche cron, root/admin recevra un courriel à exactement '''02H15'''.

* <span style="color: #ff0000;">'''Skipping!'''</span> indiquera que le renouvellement n'a pas eu lieu, car le certificat est encore valide pour plus de '''30''' jours.

== Sauvegarde du répertoire /etc/letsencrypt.sh ==
Le répertoire '''/etc''' et ses sous-répertoires ne sont pas tous inclus dans la sauvegarde standard. Nous allons créer un gabarit personnalisé pour inclure le répertoire '''/etc/letsencrypt.sh''' et ses sous-répertoires dans la sauvegarde standard.

''Référence:'' [https://wiki.contribs.org/Backup_with_dar https://wiki.contribs.org/Backup_with_dar]

''Paragraphe:'' ''Adding/Excluding Directories and Files from the backup list''.

=== Création du gabarit personnalisé ===
On crée le répertoire pour le gabarit personnalisé.

 <nowiki># </nowiki>'''mkdir -p /etc/e-smith/templates-custom/etc/dar/DailyBackup.dcf'''

On sécurise.

 # '''chmod 600 /etc/e-smith/templates-custom/etc/dar/DailyBackup.dcf'''

On crée le fichier '''41go-into''' et on y insère son contenu pour indiquer d'inclure le répertoire '''/etc/letsencrypt.sh'''. 

 cat > /etc/e-smith/templates-custom/etc/dar/DailyBackup.dcf/DailyBackup.dcf <<'EOT'
 <nowiki># Indique à la sauvegarde d'inclure le répertoire /etc/letsencrytp et tous ses </nowiki>
 <nowiki># sous-répertoires dans la sauvegarde standard.</nowiki>
 <nowiki>#</nowiki>
 <nowiki># Ci-dessous, il n'y a pas de caractère </nowiki>"/" avant etc
 --go-into etc/letsencrypt.sh  
 EOT

On développe le gabarit personnalisé.

 <nowiki># </nowiki>'''expand-template /etc/dar/DailyBackup.dcf'''

=== Vérification ===

Le lendemain de ces procédures, avec [https://www.micronator.org/?page_id=97 VirtualBox], nous avons créé un serveur semblable à celui de notre serveur passerelle et nous y avons restauré la sauvegarde de la nuit passée.

 ...
 Restoring file's data: /etc/e-smith/templates-custom/etc/dar/DailyBackup.dcf
 Restoring file's data: '''/etc/e-smith/templates-custom/etc/dar/DailyBackup.dcf/DailyBackup.dcf'''
 Restoring file's data: /etc/letsencrypt.sh
 ...
 Restoring file's data: /etc/letsencrypt.sh/certs/www.micronator.org/'''privkey.pem'''
 Restoring file's data: /etc/letsencrypt.sh/certs/www.micronator.org/cert-1457802076.csr
 Restoring file's data: /etc/letsencrypt.sh/certs/www.micronator.org/'''fullchain-1457816391.pem'''
 Restoring file's data: /etc/letsencrypt.sh/certs/www.micronator.org/fullchain-1457796476.pem
 Restoring file's data: '''/etc/letsencrypt.sh/certs/www.micronator.org'''/'''cert-1457816391.pem'''
 ...
 Restoring file's data: '''/etc/letsencrypt.sh/config.sh'''
 Restoring file's data: /etc/letsencrypt.sh/LICENSE
 Restoring file's data: /etc/letsencrypt.sh/config.sh.example
 Restoring file's data: '''/etc/letsencrypt.sh/domains.txt'''
 ...

Nous voyons que l'inclusion du répertoire et de ses sous-répertoires de /etc/letsencrypt.sh a fonctionné.

À la console du serveur virtuel, on affiche le répertoire du gabarit pour vérifier si le fichier '''VirtualHosts40ACME '''a été sauvegardé.

 <nowiki># </nowiki>'''ls -als /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts40ACME'''
 <nowiki> </nowiki>
 4 -rw-r--r-- 1 root root  127 12 mars  08:58 '''VirtualHosts40ACME'''

Le gabarit personnalisé '''httpd.conf''' a été sauvegardé, car il fait partie des répertoires de la sauvegarde standard des Serveurs SME.

== Révocation ==
=== Introduction ===
À certaines occasions, telle la mise au rancart d'un serveur, on devrait révoquer le certificat du serveur.

Pour révoquer un certificat, <u>il faut avoir la même clé de compte que celle utilisée lors de l'obtention du certificat.</u>

Nous allons révoquer le dernier certificat obtenu, <u>'''cert-1457816391.pem'''</u>.

 '''4 -rw------- 1 root root 2598 12 mars  16:00 <u>cert-1457816391.pem'''</u>

=== Commande de révocation ===
La <u>commande générale</u> pour la révocation d'un certificat.

 '''/etc/letsencrypt.sh/letsencrypt.sh  --revoke  /chemin/du/cert-numéro.pem'''

On révoque le certificat.

 # '''/etc/letsencrypt.sh/letsencrypt.sh     \'''
   '''--revoke                               \'''
   '''/etc/letsencrypt.sh/certs/www.micronator.org/cert-1457816391.pem'''
 
 <nowiki># INFO: Using main config file /etc/letsencrypt.sh/config.sh</nowiki>
 Revoking /etc/letsencrypt.sh/certs/www.micronator.org/cert-1457816391.pem
  + Done.
  + Renaming certificate to /etc/letsencrypt.sh/certs/www.micronator.org/cert-1457816391.pem-<span style="color: #ff0000;">'''revoked'''</span>

Le certificat a été révoqué et aucune erreur n'a été reçue.
<br/>
<br/>