SME-101.04 Certificat Let's Encrypt

Description générale

Le Cahier-4 du cours Micronator-101 décrit la marche à suivre pour installer gratuitement un certificat émis par Let's Encrypt pour des communications TLS/SSL.

Un certificat émis par l'autorité de certification Let's Encrypt vous permettra de chiffrer tous vos échanges Internet avec une clé reconnue mondialement; un tel certificat est un prérequis pour les paiements via Stripe ou PayPal.

Ce cahier est inspiré de la Contribution Letsencrypt produite par Flep, Hfwang, DanB35 et Brianr. https://wiki.contribs.org/Letsencrypt.

Serveurs SME sme-9 et dev

Marche à suivre

Utilisant un Serveur SME-9.2 physique - 206.248.138.152 nous allons décrire l'installation du client dehydrated de Let's Encrypt.

Tous nos essais seront effectués pour un certificat avec un seul domaine: micronator-101.com.

• Nous allons d’abord utiliser le client dehydrated pour l’installation d'un premier certificat de test que nous vérifierons à l’aide d'un navigateur Web.
• Une fois cette installation vérifiée, nous utiliserons le client dehydrated pour une demande de certificat officiel que nous vérifierons aussi à l’aide d'un navigateur Web.
• Nous répéterons les mêmes opérations pour le serveur virtuel - 192.168.1.1 sur le réseau LOCAL.
• Nous créerons un gabarit personnalisé pour indiquer à la sauvegarde standard du Serveur SME-9.x d’inclure le répertoire /etc/dehydrated.
• Nous terminerons en décrivant la marche à suivre pour recréer un certificat standard auto-signé par le Serveur SME.

Remarques

Pour la suite du cours Micronator-101, vu que nous avons maintenant un nom de domaine FQDN, micronator-101.com, un nouveau serveur physique a été installé, mis à jour et branché directement à l'Internet.

Particularités du nouveau Serveur SME:

• Il se nomme sme-9.micronator-101.com.
• L'adresse IP de sa carte eth0 sur le réseau LOCAL a été défini à 192.168.1.1.
• L'adresse IP de sa carte eth1 sur le réseau externe est: publique - 206.248.138.152, utilisant PPPoE et a été obtenue par le DHCP de notre FAI.
• Aucune Contrib ni aucun client DNS dynamique n'ont été installés.

Configuration des cartes réseau du nouveau Serveur SME.

# ifconfig

eth0     Link encap:Ethernet HWaddr 00:26:B9:7A:8E:DC
         inet adr:192.168.1.1 Bcast:192.168.1.255 Masque:255.255.255.0
         UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
         RX packets:234 errors:0 dropped:0 overruns:0 frame:0
         TX packets:236 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 lg file transmission:1000
         RX bytes:34407 (33.6 KiB) TX bytes:45952 (44.8 KiB)
         Interruption:16
 
eth1     Link encap:Ethernet HWaddr EC:08:6B:04:BF:7E
         UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
         RX packets:343 errors:0 dropped:0 overruns:0 frame:0
         TX packets:361 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 lg file transmission:1000
         RX bytes:100096 (97.7 KiB) TX bytes:62490 (61.0 KiB)

lo       Link encap:Boucle locale
         inet adr:127.0.0.1 Masque:255.0.0.0
         UP LOOPBACK RUNNING MTU:65536 Metric:1
         RX packets:161 errors:0 dropped:0 overruns:0 frame:0
         TX packets:161 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 lg file transmission:0
         RX bytes:12722 (12.4 KiB) TX bytes:12722 (12.4 KiB)
 
ppp0     Link encap:Protocole Point-à-Point
         inet adr:206.248.138.152 P-t-P:206.248.155.244 Masque:255.255.255.255
         UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
         RX packets:331 errors:0 dropped:0 overruns:0 frame:0
         TX packets:349 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 lg file transmission:3
         RX bytes:91985 (89.8 KiB) TX bytes:54356 (53.0 KiB)

Cours SME-101

But final du cours SME-101

Après avoir suivi le cours SME-101, l'Étudiant possédera un site de Commerce en ligne fiable et hautement sécuritaire. De plus, il pourra utiliser un clone de son site, sur un Serveur SME virtuel sur sa station de travail, pour tester de nouvelles extensions et applications sans compromettre la sécurité ou l'intégrité de son site en ligne.

Documentation

Le cours SME-101, se voulant une base solide pour la création d'un site de Commerce en ligne, comprend plusieurs cahiers:

• Cahier-00: Les bases de Linux, SME-101.00 Linux de base.
• Cahier-01: Installation et configuration des logiciels prérequis sur le poste de travail de l'Étudiant de même que le téléchargement des fichiers qui seront installés sur le Serveur SME virtuel, SME-101.01 Logiciels de la station de travail.
• Cahier-02: Description du parcours des paquets IP du Serveur SME vers l'Internet, création de la machine virtuelle, installation/configuration du serveur Linux SME et enfin, sauvegarde/restauration de ce dernier, SME-101.02 Serveur SME.
• Cahier-03: Abonnement à un FAI, installation et configuration d'un modem ADSL/VDSL, création d'un domaine chez un fournisseur de Service DNS dynamique avec installation d'un script pour sa mise à jour et enfin la marche à suivre pour l'obtention et la configuration d'un domaine FQDN, SME-101.03 ADSL/VDSL, DDNS et Domaine FQDN.
• Cahier-04: Installation d'un certificat SSL de l'autorité de certification Let's Encrypt et script de mise à jour, SME-101.04 Certificat Let's Encrypt.
• Cahier-05A: Installation et configuration de WordPress, SME-101.05A WordPress.
• Cahier-05B: Installation et configuration de l'extension de sécurité Wordfence, SME-101.05B Wordfence.
• Cahier-06: Installation et configuration de l'extension de vente en ligne WooCommerce, création de comptes chez Stripe et PayPal pour les paiements en ligne, SME-101.06 WooCommerce.
• Cahier-07: Sauvegarde/restauration ou migration d'un site avec l'extension Duplicator, SME-101.07 Duplicator.
• Cahier-08: Serveur mandataire inversé, SME-101.08 Serveur mandataire inversé.
• Cahier-09: Supplément: SME & BackupPC-4.2, SME-101.09: Supplément: SME & BackupPC-4.2.

Tous les logiciels nécessaires sont du domaine public ou LIBRE sous licence GPL; ils ne coûtent pas un sous. Le seul achat nécessaire est l'obtention d'un nom de domaine FQDN au prix initial de $15 CAD et son renouvellement annuel d'environ $30 CAD.

Particularités de ce document

Notes au lecteur

• Les captures d’écrans ne sont que des références.

• Les informations écrites ont préséance sur celles retrouvées dans les captures d’écrans. Se référer aux différents tableaux lorsque ceux-ci sont présents.

Conventions

• Toutes les commandes à entrer à la console du Serveur SME commencent habituellement avec l'invite # pour l'usager root ou $ pour un usager sans privilège particulier.
• L'invite mysql> de la console MySQL est toujours présente.
• La sortie de la commande est séparée de celle-ci par une ligne vide sans couleur de fond.
• L'invite de retour n'est jamais présent pour la plupart des commandes.
• Les affichages à surveiller sont en rouge, bleu, orange ou magenta.

# ping 192.168.1.149

192.168.1.149 is alive

Les liens de référence Internet sont en bleu de même que ceux intra-document mais, ces derniers débute par un " # ".

  Manipulation, truc ou ruse pour se tirer d’embarras.

  Une recommandation ou astuce.

  Une note.

  Une étape, note ou procédure à surveiller.

  Danger pour la sécurité du système.

  Indique que la commande est sur une seule ligne. Pour ce document en PDF, il faudra copier la commande entière dans un éditeur de texte ASCII tel que NotePad++ et la mettre sur une seule ligne avant de la copier à la console.

Une chaîne de caractères en magenta indique qu’il faut remplacer cette chaîne par vos propres paramètres.

Commande à exécuter si ce n'est déjà fait.

Commande indiquée à titre d'information seulement.

Glossaire

Ce chapitre rassemble quelques termes pour permettre une brève introduction à la cryptographie.

Cryptographie asymétrique

Référence: https://fr.wikipedia.org/wiki/Cryptographie_asym%C3%A9trique.

La cryptographie asymétrique, ou cryptographie à clé publique, est une méthode de chiffrement qui s'oppose à la cryptographie symétrique. Elle repose sur l'utilisation d'une clé publique (qui est diffusée) et d'une clé privée (gardée secrète), la première permettant de coder le message et la seconde de le décoder. Ainsi, l'expéditeur peut utiliser la clé publique du destinataire pour coder un message que seul le destinataire (en possession de sa clé privée) peut décoder, garantissant la confidentialité du contenu.

Chiffrement

L'un des rôles de la clé publique est de permettre le chiffrement; c'est donc cette clé qu'utilisera Bob pour envoyer des messages chiffrés à Alice. L'autre clé — l'information secrète — sert à déchiffrer. Ainsi, Alice, et elle seule, peut prendre connaissance des messages de Bob. La connaissance d'une clé ne permet pas de déduire l'autre.

Échange de clés Diffie-Hellman

Référence: https://fr.wikipedia.org/wiki/%C3%89change_de_cl%C3%A9s_Diffie-Hellman.

En cryptographie, l'échange de clés Diffie-Hellman, du nom de ses auteurs Whitfield Diffie et Martin Hellman, est une méthode par laquelle deux agents nommés conventionnellement Alice et Bob peuvent se mettre d'accord sur un nombre (qu'ils peuvent utiliser comme clé pour chiffrer la conversation suivante) sans qu'un troisième agent appelé Ève puisse découvrir le nombre, même en ayant écouté tous leurs échanges.

Somme de contrôle

Référence: https://fr.wikipedia.org/wiki/Somme_de_contr%C3%B4le.

La somme de contrôle (checksum), parfois appelée "empreinte", est un nombre qu'on ajoute à un message à transmettre pour permettre au récepteur de vérifier que le message reçu est bien celui qui a été envoyé. L'ajout d'une somme de contrôle à un message est une forme de contrôle par redondance.

Nonce

Référence: https://fr.wikipedia.org/wiki/Nonce_cryptographique.

Le nonce est un nombre arbitraire, à usage unique, utilisé pour signer un ensemble de données d'une communication électronique. Il permet notamment d'éviter les attaques de type "Attaque par rejeu".

Condensat

Référence: http://gdt.oqlf.gouv.qc.ca.

Séquence de caractères alphanumériques de longueur fixe qui représente le contenu d'un message, sans le révéler, dont la valeur unique est produite par un algorithme de hachage et qu'on utilise pour créer une signature numérique.

Empreinte numérique

Référence: http://gdt.oqlf.gouv.qc.ca/ficheOqlf.aspx?Id_Fiche=8371028.

L'empreinte numérique sert à authentifier un message ou à vérifier l'identité de son auteur.

Une empreinte numérique a toujours la même taille, quelle que soit la longueur du message initial. À l'instar d'une empreinte digitale, deux messages différents n'ont pas la même empreinte numérique. Après avoir calculé l'empreinte de son message, l'expéditeur la chiffre avec sa clé privée. Il envoie ensuite cette signature en même temps que le reste de son message. Lorsque le destinataire reçoit cette empreinte chiffrée, il la déchiffre grâce à la clé publique de l'expéditeur. Le destinataire compare alors le résultat obtenu avec le résultat qu'il calcule lui-même à partir du message reçu. Si les deux empreintes numériques sont identiques, il est assuré à la fois de l'identité de l'expéditeur et de l'intégrité du message.

Homme-du-milieu

Référence: https://fr.wikipedia.org/wiki/Attaque_de_l'homme_du_milieu.

L'attaque de l'homme-du-milieu (HdM) ou man-in-the-middle attack (MITM) est une attaque qui a pour but d'intercepter les communications entre deux parties, sans que ni l'une ni l'autre ne puisse se douter que le canal de communication entre elles a été compromis. Le canal le plus courant est une connexion à Internet de l'internaute lambda. L'attaquant doit d'abord être capable d'observer et d'intercepter les messages d'une victime à l'autre. L'attaque “homme-du-milieu” est particulièrement applicable dans la méthode d'échange de clés Diffie-Hellman, quand cet échange est utilisé sans authentification. Avec authentification, Diffie-Hellman est en revanche invulnérable aux écoutes du canal, et est d'ailleurs conçu pour cela.

Certificat

Référence: https://fr.wikipedia.org/wiki/Certificat_%C3%A9lectronique.

Un certificat électronique (aussi appelé certificat numérique ou certificat de clé publique) peut être vu comme une carte d'identité numérique. Il est utilisé principalement pour identifier et authentifier une personne physique ou morale, mais aussi pour chiffrer des échanges.

Il est signé par un tiers de confiance qui atteste du lien entre l'identité physique et l'entité numérique (Virtuel).

Le standard le plus utilisé pour la création des certificats numériques est le X.509.

Référence: https://fr.wikipedia.org/wiki/X.509.

Dans le système X.509, une autorité de certification attribue un certificat liant une clé publique à un nom distinctif (Distinguished Name) dont le format est défini par la recommandation X.500, ou encore à un nom alternatif (Alternative Name) tel qu'une adresse électronique ou un enregistrement DNS.

Ce certificat place la signature d'une autorité de certification dans le dernier champ. Concrètement, cette signature est réalisée par un condensat de tous les champs précédents du certificat et un chiffrement de ce condensat par la clé privée de l'autorité de certification. N'importe qui possédant la clé publique de cette autorité de certification peut déchiffrer le condensat et le comparer au calcul de son propre condensat du certificat. Si les deux condensats sont identiques, cela garantit que le certificat est intègre et qu'il n'a pas été modifié.

Chaîne de certification

Le certificat de l'autorité de certification qui contient sa clé publique peut à son tour être signé par un autre certificat de plus haut niveau, formant ainsi une chaîne. Tout en haut de la chaîne on trouve les certificats les plus importants: les certificats racines.

Certificats racines

Les certificats racines sont des clés publiques non signées, ou auto-signées, dans lesquelles repose la confiance. Les logiciels, comme les navigateurs Web ou les clients de messagerie détiennent des certificats racines de nombreuses autorités de certification commerciales ou gouvernementales. Quand un navigateur ouvre une connexion sécurisée (TLS/SSL) vers un site possédant un certificat émis par une autorité connue, il considère le site comme sûr dans la mesure où le chemin de certification est validé. Le passage en mode sécurisé est alors transparent.

Certificats à Validation de Domaine (DV)

Référence: https://www.certificat.fr/fr/produits/certificats+ssl/validation+du+domaine/.

Les certificats à Nom de Domaine (DV) sont émis très rapidement, et ce, en quelques minutes. Le propriétaire ou le webmestre du nom de domaine doit confirmer la requête par courriel.

Pendant votre demande, vous devez indiquer une adresse courriel pour confirmation; vous pouvez choisir parmi une liste de différents courriel standard comme admin@, root@, administrator@ etc... ou l'adresse courriel qui est listée dans les informations du Whois du nom de domaine.

Avantages

Un certificat SSL DV est facile à obtenir. Vous obtenez ce certificat en quelques minutes.

Bon à savoir

Ce type de Certificat SSL certifie seulement que le site Internet est sécurisé. Il n'y a pas d'Autorité de Certification qui a vérifié et validé l'identité du propriétaire du site Internet.

Pour qui?

Les certificats DV seront utilisés pour les sites Internet qui ont juste besoin d'une connexion https (connexion sécurisée) ou une connexion sécurisée pour webmail, intranet, citrix secure gateway, et ainsi de suite. Ce Certificat SSL est parfait dans le cas où quelqu'un a besoin immédiatement d'un certificat.

SAN et Wildcard

Référence: https://www.thawte.fr/ssl/san-uc-ssl-certificates/#.

Référence: https://www.thawte.fr/ssl/wildcard-ssl-certificates/.

Que signifient les termes SAN (Subject Alternative Names) et UC (Unified Communications)?

Les certificats qui utilisent les SAN (Subject Alternative Names) sont des outils puissants qui permettent de sécuriser plusieurs noms de domaines de façon efficace et économique. Les certificats SSL Thawte permettent de sécuriser jusqu'à 25 noms de domaines complets avec un seul certificat utilisant les SAN. Les noms de certificats qui utilisent les SAN sont également appelés certificats UC (Unified Communications ou communications unifiées) et sont utilisés avec Microsoft Exchange Server 2007, Microsoft Exchange Server 2010 et Microsoft Communications Server. L'objectif d'un certificat avec SAN est le même que n'importe quel autre certificat; il permet à un serveur de définir son identité et d'établir une communication sécurisée. Les certificats avec SAN procurent également un champ SAN (Subject Alternative Name) qui permet de protéger les noms de domaines additionnels avec un seul certificat.

Pourquoi ai-je besoin d'un SAN?

Au lieu d'acheter des certificats individuels pour chaque nom de domaine, vous pouvez ajouter des noms de domaines dans les champs SAN pour partager le même certificat. Non seulement l'entreprise économise le coût d'achat de certificats individuels, mais elle gagne également du temps en évitant d'avoir à gérer plusieurs certificats.

Par exemple, un seul certificat avec prise en charge des SAN serait capable de sécuriser les noms de domaines suivants:

• www.macompagnie.com
• mail.macompagnie.com
• macompagnie.com
• www.toto.net
• mail.toto.net
• toto.net

Certificat SAN vs certificat Wildcard

Les certificats Wildcard sont similaires aux certificats SAN avec quelques restrictions. Avec un certificat Wildcard, vous pouvez sécuriser plusieurs sous-domaines avec un seul domaine racine. Par exemple, si vous avez un certificat Wildcard pour www.macompagnie.com, il sécurise également intranet.macompagnie.com et email.macompagnie.com avec le même certificat.

Cependant, vous ne pourrez pas sécuriser plusieurs domaines uniques comme www.macompagnie.net et www.toto.org.

Certificats SSL Wildcard

Sécurisation de plusieurs sous-domaines sur un seul serveur.

Les certificats SSL Wildcard Thawte sécurisent plusieurs sous-domaines avec un certificat SSL unique, réduisant ainsi le temps et le coût de gestion. L'utilisation de la notation Wildcard (un astérisque et un point avant votre nom de domaine) vous permet d'étendre la sécurité à différents sous-domaines, basés sur le nom de votre domaine de niveau supérieur.

CNAME

Référence: http://archive.li/L15Hm.

Un enregistrement CNAME ou enregistrement de Nom Canonique est un type d'enregistrement ressource dans le Domain Name System (DNS) qui spécifie que le nom de domaine est un alias d'un autre nom de domaine canonique.

Utilisation d'enregistrement CNAME En utilisant les CNAME, vous rendez les données de votre DNS plus facile à gérer. Les enregistrements CNAME redirigent vers un enregistrement A. Par conséquent, si vous changez l'adresse IP d'un enregistrement A, tous vos enregistrements CNAME pointés vers cet enregistrement, suivent automatiquement le nouvel IP de l'enregistrement A. La solution alternative est d'avoir des enregistrements A multiples mais alors, vous aurez des endroits multiples pour changer l'adresse IP qui augmente les chances d'erreur.

L'utilisation la plus populaire d'un enregistrement CNAME, est de fournir un accès à un serveur Web en utilisant soit le standard www.domaine.com ou soit domaine.com (sans le www). Cette règle est généralisée en ajoutant un enregistrement CNAME pour le nom www pointant au nom court [lors de la création d'un Enregistrement A pour le nom court (sans www)].

Exemple:

Vous avez un site Web avec le nom de domaine monsite.quebec. Ce nom de domaine est connecté à un enregistrement A qui traduit le nom de domaine à l'adresse IP appropriée, par exemple 11.22.33.44.

Vous avez aussi plusieurs sous-domaines, comme coquille.monsite.quebec, email.monsite.quebec, etc... et vous souhaitez que ces sous-domaines pointent à votre nom de domaine principal monsite.quebec. Au lieu de créer des enregistrements A pour chaque sous-domaine et les lier à l'adresse IP de votre domaine principal, vous créez un alias (enregistrement CNAME) pour chacun d'eux pour obtenir la figure ci-contre. Dans le cas où votre adresse IP change, vous devez seulement éditer un enregistrement A et tous les sous-domaines suivent automatiquement du fait des CNAME pointant vers le domaine principal.

  Micronator a un serveur privé (sur le réseau LOCAL) qui fait partie du domaine principal et dont le nom est coquille. Nous pouvons alors insérer un CNAME coquille pour ce serveur.

Let's Encrypt

Principe de fonctionnement de Letsencrypt

Référence: https://linuxfr.org/news/reparlons-de-let-s-encrypt.

La facilité d'utilisation promise par Let's Encrypt repose principalement sur le client dehydrated et sur l'automatisation qu'il propose.

Le client dehydrated s'occupe (ou peut s'occuper) de deux tâches distinctes:

1. obtenir un certificat pour le(s) domaine(s) souhaité(s), et
2. installer le certificat obtenu.

Pour obtenir un certificat, le client dehydrated:

• génère une paire de clefs et une demande de signature de certificat (Certificate Signing Request: CSR);
• envoie la demande à un serveur ACME;
• répond aux défis d'authentification (challenges) posés par la CA, permettant au demandeur de prouver qu'il contrôle le(s) domaine(s) demandé(s);
• reçoit le certificat signé en retour.

Le client installe le certificat proprement dit, la clef privée correspondante et les certificats intermédiaires là où le serveur Web pourra les trouver, enfin il configure et relance ledit serveur s'il sait le faire (si le serveur en question est Apache HTTP ou Nginx, pour l'instant).

Le client dehydrated garde aussi une trace des certificats obtenus. Lancé à intervalle régulier, il répétera automatiquement la procédure s'il détecte qu'un certificat est sur le point d'expirer.

En définitive, le but est que l'administrateur puisse mettre en place TLS en une seule commande, avant d'oublier jusqu'à l'existence même du client dehydrated.

Courriels du certificat

Aucun courriel n'est envoyé pour confirmer le certificat mais, vous devez fournir une adresse courriel et un/des CNAME valides lors de l'exécution du script dehydrated.

Transparence des certificats

Une partie de la mission de transparence de la société Let's Encrypt comprend la divulgation publique des certificats qu'elle délivre via Certificate Transparency. L'adresse courriel n'est pas divulguée publiquement.

Limites

90 jours

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

5/7

En date du 2018-10-05:

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

Référence: https://letsencrypt.org/docs/rate-limits/.

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

** Un certificat multi-domaines SAN ayant domaine1.com, www.domaine1.com, domaine2.com, www.domaine2.com, toto.info, titi.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?

*** 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.

  Note importante sur le fichier domains.txt

Si tous les domaines et sous domaines sont répertoriés sur la même ligne, il en résultera un seul certificat SAN (Subject-Alternative-Name) au nom du premier domaine de la ligne.

domaine1.com www.domaine1.com mail.domaine1.com domaine2.net www.domaine2.net domaine3.org

Si chacun des domaines est énuméré sur une ligne différente, il en résultera autant de certificats que le nombre de lignes dans le fichier.

domaine1.com www.domaine1.com mail.domaine1.com
domaine2.net www.domaine2.net
domaine3.org ftp.domaine3.org
domaine4.info www.domaine4.org

Le fichier domains.txt ci-dessus, indique qu'il devrait y avoir 4 certificats: domaine1.com, domaine2.net, domaine3.org et domaine4.info. Chaque certificat couvrant le domaine principal et ses CNAME (sous-domaines).

  Le résultat d'une telle énumération des domaines pourrait facilement atteindre ou dépasser la limite décrite 5/7.

Mode Officiel vs TEST (Staging)

Si vous voulez tester dehydrated et que vous n'êtes pas encore certain de vouloir l'adopter, vous pouvez utiliser l'option staging (incluant la ligne CA="https://acme-staging.api.letsencrypt.org/directory" dans le fichier de configuration config).

Le principal avantage est de pouvoir demander autant de certificats que vous avez besoin pour vos tests sans vous heurter à la limite 5/7.

Autorité de certification (CA)

CA officielle

Lors d'une demande de certificat officiel, le client dehydrated utilise la CA officielle, "Let’s Encrypt Authority X3".

CA de TEST

Un certificat de test ne sera pas signé directement par Let's Encrypt mais par sa CA de tests, "Fake LE Intermediate X1". Ce certificat de test ne sera pas reconnu par la plupart des navigateurs et affichera une erreur. La communication sera tout de même chiffrée.

La CA acme-staging est l'émettrice pour "Fake LE Intermediate X1".

  Il est fortement recommandé de débuter en demandant un certificat de test.

Fichier de configuration

Certificat officiel

Le fichier de configuration pour une demande de certificat officiel utilise la CA officielle "Let’s Encrypt Authority X3".

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

Fichier config de la configuration standard.

#!/bin/bash
WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"
CA="https://acme-v01.api.letsencrypt.org/directory"
BASEDIR="/etc/dehydrated"
CONTACT_EMAIL=admin@micronator.org
HOOK="/usr/bin/hook-script.sh"

PARAM_ACCEPT_TERMS="yes"

Certificat de TEST

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

#!/bin/bash
WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"
CA="https://acme-staging.api.letsencrypt.org/directory"
BASEDIR="/etc/dehydrated"
CONTACT_EMAIL="admin@nom-de-votre-domaine"
HOOK="/usr/bin/hook-script.sh"

PARAM_ACCEPT_TERMS="yes"

Clé de compte Let's Encrypt

  La clé de compte Let's Encrypt est différente de la clé privkey-nnnnnnnnn.pem utilisée par le Serveur SME. Cette dernière est stockée dans le répertoire /etc/dehydrated/certs/nom-du-domaine/.

La clé de compte account_key.pem est stockée dans un sous-répertoire de /etc/dehydrated/accounts/.

• Si on demande un certificat de TEST, un sous-répertoire y est créé pour stocker la clé de compte de TEST.
• Si on demande un certificat OFFICIEL, un autre sous-répertoire y est créé pour stocker la clé de compte OFFICIEL.
• Le sous-répertoire de la clé de compte de TEST est créé lors de la première demande d'un certificat de TEST et celui de la clé de compte OFFICIEL est créé lors de la première demande d'un certificat officiel.
•   Le sous-répertoire et la clé utilisée dépendent de la ligne CA="https://... dans le fichier de configuration config.

La clé de compte est utilisée exclusivement par le client dehydrated et uniquement pour:

• créer un compte usager chez la CA,
• signer les domaines et
• chiffrer la communication entre le Serveur SME et la CA.

Que ce soit pour une demande d'un certificat de TEST ou pour un certificat OFFICIEL, la clé de compte est toujours appelé account_key.pem.

  Une clé SSL est toujours constituée d'une partie publique et d'une partie privée.

Aide

Pour afficher l'aide du client dehydrated.

 dehydrated  --help

En cas de trouble majeur avec un certificat

Advenant un trouble majeur avec un certificat et que vous vouliez en recréer un original, émis et certifié par le Serveur SME lui-même, veillez consulter le chapitre: #Certificat standard SME.

À savoir

Conditions préalables

Le client dehydrated et le Serveur SME interagissent pour confirmer que la personne, demandant un certificat pour un nom d'hôte, contrôle réellement ce serveur.

Il existe quelques configurations préalables à une demande de certificat. Par exemple, si nous essayons d'obtenir un certificat pour www.exemple.com, toutes les conditions suivantes doivent être remplies:

• www.exemple.com est un nom de domaine valide - le nom de domaine a été enregistré et les enregistrements DNS sont publiés pour ce domaine.
• Le résultat d'une recherche DNS de www.exemple.com pointe vers l'adresse IP du Serveur SME – lorsqu'ils sont interrogés sur www.exemple.com, les enregistrements DNS publiés doivent donner l'adresse IP externe du Serveur SME.
• Le Serveur SME est connecté à l'Internet ou LOCAL avec la Contrib smeserver-letsencrypt.
• Les ports 80 et 443 sur le Serveur SME sont ouverts à l'Internet – ils ne sont pas derrière un pare-feu ou un filtrage par le FAI qui bloquerait ces ports.

Le client dehydrated émettra un certificat qui peut comprendre plusieurs noms d'hôte (par exemple: www.exemple.com, exemple.com et mail.exemple.com) qui tous, feront partie de la demande. Toutes les conditions ci-dessus doivent être remplies pour chacun des noms d'hôtes qu'on souhaite inclure dans le certificat.

  Assurez-vous que tout est correctement en place avant de continuer.

  Avant de commencer l'installation, vérifiez si vous, ou une CONTRIB précédemment installée, avez configuré des valeurs personnalisées pour votre certificat TLS/SSL présentement actif.

Par défaut la commande ci-dessous devrait donner le résultat suivant.

# config show modSSL

modSSL=service
    TCPPort=443
    access=public
    status=enabled

Si la commande affiche les paramètres crt, key, CertificateChainFile et leurs valeurs, il est fortement recommandé d'en faire une #Sauvegarde des fichiers du certificat actuel. Ainsi, si vous rencontrez un problème avec les fichiers du certificat généré par Let's Encrypt, vous serez alors en mesure de revenir aux paramètres précédents.

Certificat Let's Encrypt

Un certificat émis par l'autorité de certification Let's Encrypt vous permettra de chiffrer les connexions de votre serveur avec une clé TLS/SSL reconnue mondialement. Les usagers pourront utiliser https et vu que le certificat aura été émis par une autorité de certification reconnue, le cadenas sera toujours vert.

Ce chapitre est inspiré de la contribution Letsencrypt produite par: DanB35, Unnilennium, Mdo, Mercyh, RayMitchell et Gieres  https://wiki.contribs.org/Letsencrypt.

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

Let's Encrypt est une autorité de certification (CA) lancée le 3 décembre 2015 (Bêta Version Publique). Cette autorité fournit des certificats gratuits X.509 pour le protocole cryptographique TLS/SSL au moyen d'un mécanisme 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.

Installation

On installe la Contrib smeserver-letsencrypt.

# yum install -y --enablerepo=smecontribs smeserver-letsencrypt

Modules complémentaires chargés : fastestmirror, smeserver
...
Installation de     2 paquet(s)

Taille totale des téléchargements : 56 k
Taille d'installation : 98 k
...
Installé:
  smeserver-letsencrypt.noarch 0:0.4-4

Dépendance(s) installée(s) :
  dehydrated.noarch 0:0.5.0-3.el6.sme

Terminé !

==============================================================
WARNING: You now need to run BOTH of the following commands
to ensure consistent system state:

signal-event post-upgrade; signal-event reboot

You should run these commands unless you are certain that
yum made no changes to your system.
==============================================================

Signalisation des changements

On applique les changements en signalant une mise à jour et un réamorçage.

# signal-event post-upgrade ; signal-event reboot

  Ne pas signaler les changements pourrait empêcher la Contrib de fonctionner correctement et vos certificats ne seront pas renouvelés.

Mise à jour de la Contrib

  Vous pouvez manuellement mettre à jour la Contrib c.-à-d. smeserver-letsencrypt et dehydrated en utilisant la commande ci-dessous.

# yum update -y --enablerepo=smecontribs smeserver-letsencrypt dehydrated

Modules complémentaires chargés : fastestmirror, smeserver
Configuration du processus de mise à jour
Loading mirror speeds from cached hostfile
 * base: centos.ca-west.mirror.fullhost.io
 * smeaddons: mirror.canada.pialasse.com
 * smecontribs: mirror.canada.pialasse.com
 * smeextras: mirror.canada.pialasse.com
 * smeos: mirror.canada.pialasse.com
 * smeupdates: mirror.canada.pialasse.com
 * updates: centos.mirror.vexxhost.com
Aucun paquet marqué pour mise à jour

S'il y avait une mise à jour, cette commande l'installerait automatiquement.

Signalisation des changements

Si vous aviez fait une mise à jour, vous devriez signaler les changements.

# signal-event post-upgrade  ;  signal-event reboot

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 le fichier domains.txt pointent vers le serveur exécutant dehydrated.

On vérifie qu'on est bien dans le répertoire personnel de l'usager root. Ce sera notre répertoire de travail.

# pwd

/root

On crée le répertoire des défis (challenge).

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

On ajuste Récursivement le propriétaire et le groupe de ces répertoires.

# chown -R admin:shared /home/e-smith/files/ibays/Primary/html/.well-known/

On ajuste Récursivement les droits.

# chmod -R 2750 /home/e-smith/files/ibays/Primary/html/.well-known/

On vérifie le répertoire .well-known.

# ls -alsd  /home/e-smith/files/ibays/Primary/html/.well-known/

4 drwxr-s--- 3 admin shared 4096  3 oct.  16:33 /home/e-smith/files/ibays/Primary/html/.well-known/

On vérifie le répertoire acme-challenge.

# ls -alsd  /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge

4 drwxr-s--- 2 admin shared 4096  3 oct.  19:33 /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é.

# mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf

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

  Prendre tout le contenu de l'encadré pour la commande.

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

EOT

On vérifie.

# cat /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts40ACME

# Alias for letsencrypt
#
Alias  /.well-known/acme-challenge  /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge

  Il n'y a pas de ligne vide avant la ligne # Alias for letsencrypt. Ci-dessus, nous avons inséré une ligne vide pour faciliter la copie de la commande.

On développe le gabarit personnalisé.

# expand-template /etc/httpd/conf/httpd.conf

Redémarrage du service httpd-e-smith

# service httpd-e-smith restart

Restarting httpd-e-smith                                   [  OK  ]

Choix des domaines et des hôtes

On affiche les nom d'hôtes sur notre Serveur SME.

# db hosts show | grep .com

ftp.micronator-101.com=host
mail.micronator-101.com=host
proxy.micronator-101.com=host
sme-9.micronator-101.com=host
wpad.micronator-101.com=host
www.micronator-101.com=host

CNAME: pour micronator-101.com

  Si certains de vos défis sont renvoyés sans erreur, mais que certains échouent, il est possible que vous n'ayez pas d'enregistrements DNS A, MX ou CNAME pour tous les noms d'hôtes que vous avez ajoutés à votre certificat. Lorsque Let's Encrypt lance les défis pour une liste de noms d'hôtes et qu'un de ceux-ci ne répond pas, le défi échoue et le certificat n'est pas généré.

La cause principale des défis non relevés est qu'il n'existe pas d'enregistrements DNS pour tous les noms d'hôtes ajoutés au certificat. La plupart des administrateurs de systèmes ne créent pas tous les enregistrements DNS nécessaires et le certificat n'est pas généré.

Si on veut obtenir un certificat pour tous all les domaines et tous les noms d'hôtes.

# config setprop letsencrypt configure all

  La commande config setprop letsencrypt configure all est susceptible de provoquer une erreur de défi.

Nous voulons tous les noms d'hôtes affichés avec la commande db hosts show | grep .org sauf celui du nom du serveur: sme-9.micronator-101.com car, ce dernier ne répond pas au défi de Let's Encrypt.

Pour utiliser des hôtes ou des domaines activés individuellement, on active le paramètre configure à none et ensuite on ajoute les domaines et les noms d'hôtes désirés.

# config setprop letsencrypt configure none

Domaines

On inclut micronator-101.com.

# db domains setprop micronator-101.com letsencryptSSLcert enabled

On vérifie.

# db domains show

micronator-101.com=domain
    Content=Primary
    Description=Primary domain
    Nameservers=localhost
    Removable=no
    SystemPrimaryDomain=yes
    letsencryptSSLcert=enabled

Hôtes

On inclut tous les hôtes suivants.

# db hosts setprop ftp.micronator-101.com letsencryptSSLcert enabled

# db hosts setprop mail.micronator-101.com letsencryptSSLcert enabled

# db hosts setprop proxy.micronator-101.com letsencryptSSLcert enabled

# db hosts setprop wpad.micronator-101.com letsencryptSSLcert enabled

# db hosts setprop www.micronator-101.com letsencryptSSLcert enabled

Autres propriétés de configuration

Aucun autre paramètre n'est obligatoire; cependant, il est recommandé de configurer une adresse courriel. Si un problème est rencontré lors du renouvellement de votre certificat, les serveurs de Let's Encrypt vous en informeront.

Ajout d'une adresse courriel

  Le domaine de messagerie spécifié n'a nul besoin de correspondre à l'un des domaines pour lesquels vous demandez un certificat.

# config setprop letsencrypt email admin@micronator.org

Longueur de la clé privée

Si vous ne voulez pas la valeur par défaut de 4096 bits, vous pouvez définir la longueur de la clé privée de votre certificat. Ceci ne devrait pas être nécessaire dans la plupart des cas mais; si vous le souhaitiez, il faudrait utiliser la commande ci-dessous pour ce faire.

# config setprop letsencrypt keysize LONGUEUR-EN-BITS

Termes et conditions

  Veuillez d'abord lire les conditions d'utilisation de Let's Encrypt:  https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf

  Seulement si vous acceptez les termes et conditions de Let's Encrypt, lancez la commande ci-dessous.

# config setprop letsencrypt ACCEPT_TERMS yes

Activation du mode TEST

Référence: https://github.com/lukas2511/dehydrated.

Let's Encrypt impose des limites strictes. Si vous commencez à tester en utilisant un certificat OFFICIEL (la valeur par défaut), vous allez rapidement atteindre ces limites et vous vous retrouvez en restriction de demandes/renouvellements de certificats.

C'est pour cette raison que nous recommandons fortement de commencer en mode TEST afin de vérifier les configurations et surtout de ne pas dépasser la limite 5/7 de Let's Encrypt (5 certificats par 7 jours). Toutes erreurs ou autres problèmes rencontrés ne vous empêchera pas, plus tard, d'obtenir votre certificat de Production.

On active le mode TEST.

# config setprop letsencrypt status test

On signale les changements. (Peut prendre plusieurs secondes.)

#  signal-event console-save

Vérification

On vérifie si on est bien en mode TEST.

# cat /etc/dehydrated/config | grep CA

CA="https://acme-staging.api.letsencrypt.org/directory"

On vérifie l'adresse courriel.

# cat /etc/dehydrated/config | grep CONTACT

CONTACT_EMAIL=admin@micronator.org

On vérifie les domaines et les hôtes.

# cat /etc/dehydrated/domains.txt

micronator-101.com ftp.micronator-101.com mail.micronator-101.com proxy.micronator-101.com wpad.micronator-101.com www.micronator-101.com

  Tout le contenu du fichier domains.txt doit être entièrement sur une seule ligne sinon, vous aurez autant de certificats que de lignes et vous atteindrez la limite 5/7 de Let's Encrypt.

  Le certificat sera émis au nom du premier domaine de la ligne; ici, ce sera micronator-101.com.

Affichage de l'aide sur la commande dehydrated

# dehydrated --help

Usage: /usr/bin/dehydrated [-h] [command [argument]] [parameter [argument]] [parameter [argument]] ...

Default command: help

Commands:
 --version (-v)                   Print version information
 --register                       Register account key
 --account                        Update account contact information
 --cron (-c)                      Sign/renew non-existent/changed/expiring certificates.
 --signcsr (-s) path/to/csr.pem   Sign a given CSR, output CRT on stdout (advanced usage)
 --revoke (-r) path/to/cert.pem   Revoke specified certificate
 --cleanup (-gc)                  Move unused certificate files to archive directory
 --help (-h)                      Show help text
 --env (-e)                       Output configuration variables for use in other scripts

Parameters:
 --accept-terms                   Accept CAs terms of service
 --full-chain (-fc)               Print full chain when using --signcsr
 --ipv4 (-4)                      Resolve names to IPv4 addresses only
 --ipv6 (-6)                      Resolve names to IPv6 addresses only
 --domain (-d) domain.tld         Use specified domain name(s) instead of domains.txt entry (one 
                                  certificate!)
 --alias certalias                Use specified name for certificate directory (and per-certificate 
                                  config) instead of the primary domain (only used if --domain is
                                  specified)
 --keep-going (-g)                Keep going after encountering an error while creating/renewing multiple
                                  certificates in cron mode
 --force (-x)                     Force renew of certificate even if it is longer valid than value in
                                  RENEW_DAYS
 --no-lock (-n)                   Don't use lockfile (potentially dangerous!)
 --lock-suffix example.com        Suffix lockfile name with a string (useful for with -d)
 --ocsp                           Sets option in CSR indicating OCSP stapling to be mandatory
 --privkey (-p) path/to/key.pem   Use specified private key instead of account key (useful for
                                  revocation)
 --config (-f) path/to/config     Use specified config file
 --hook (-k) path/to/hook.sh      Use specified script for hooks
 --out (-o) certs/directory       Output certificates into the specified directory
 --challenge (-t) http-01|dns-01  Which challenge should be used? Currently http-01 and dns-01 are
                                  supported
 --algo (-a) rsa|prime256v1|secp384r1 Which public key algorithm should be used? Supported: rsa,
                                  prime256v1 and secp384r1

Lancement du script dehydrated

Vous pouvez maintenant exécuter le script dehydrated pour la première fois et vous assurer qu'il lui est possible de: se connecter aux serveurs de Let's Encrypt, valider les noms d'hôtes pour lesquels vous demandez le certificat, relever les défis et requérir le certificat.

# dehydrated -c

# INFO: Using main config file /etc/dehydrated/config
+ Generating account key...
+ Registering account key with ACME server...
Processing micronator-101.com with alternative names: ftp.micronator-101.com mail.micronator-101.com proxy.micronator-101.com wpad.micronator-101.com www.micronator-101.com
 + Signing domains...
 + Creating new directory /etc/dehydrated/certs/micronator-101.com ...
 + Creating chain cache directory /etc/dehydrated/chains
 + Generating private key...
 + Generating signing request...
 + Requesting challenge for micronator-101.com...
 + Requesting challenge for ftp.micronator-101.com...
 + Requesting challenge for mail.micronator-101.com...
 + Requesting challenge for proxy.micronator-101.com...
 + Requesting challenge for wpad.micronator-101.com...
 + Requesting challenge for www.micronator-101.com...
 + Responding to challenge for micronator-101.com...
 + Challenge is valid!
 + Responding to challenge for ftp.micronator-101.com...
 + Challenge is valid!
 + Responding to challenge for mail.micronator-101.com...
 + Challenge is valid!
 + Responding to challenge for proxy.micronator-101.com...
 + Challenge is valid!
 + Responding to challenge for wpad.micronator-101.com...
 + Challenge is valid!
 + Responding to challenge for www.micronator-101.com...
 + Challenge is valid!
 + Requesting certificate...
 + Checking certificate...
 + Done!
 + Creating fullchain.pem...
 + Using cached chain!
Set up modSSL db keys
Signal events
All complete
 + Done!

Aucune erreur, tout a bien fonctionné.

Analyse de la communication

• # INFO: Using main config file /etc/dehydrated/config: avec la demande du certificat, le script a utilisé le fichier de configuration.
• Processing micronator-101.com: il a analysé le fichier domains.txt.
• + Signing domains...: il a signé les domaines.
• + Creating new directory /etc/dehydrated/certs/micronator-101.com...: il a créé un répertoire utilisant le nom du premier domaine dans le fichier domains.txt.
• + Generating private key...: il a généré localement une clé privée TLS/SSL pour le serveur. Exemple: /etc/dehydrated/certs/micronator-101.com/privkey-1538661090.pem.
• + Generating signing request...: il a créé une requête CSR. Exemple: /etc/dehydrated/certs/micronator-101.com/cert- 1538661090.csr.
• + Requesting challenge: il a demandé les défis, attendu leurs validités...
• + Challenge is valid! ... et vérifié leurs réponses.
• + Requesting certificate...: il a fait la demande du certificat.
• + Checking certificate...: une fois reçu, il a vérifié le certificat.
• + Done!: le tout terminé,
• + Creating fullchain.pem... il a créé la chaîne de certification et ajusté les pointeurs.
• Il a alors appelé le script de point d'entrée et celui-ci a modifié les propriétés de modSSL et signalé les changements pour activer le nouveau certificat.

ERREUR

  Si vous recevez l'erreur ci-dessous, simplement relancer la demande. Il se peut que vous ayez à le faire plusieurs fois.

# dehydrated -c   # INFO: Using main config file /etc/dehydrated/config ERROR: Problem connecting to server (get for https://acme-v01.api.letsencrypt.org/directory; curl returned with 6)

Si les serveurs Let's Encrypt sont très occupés, ils peuvent retourner l'erreur ci-dessous. Simplement relancer la demande. Il se peut que vous ayez à le faire plusieurs fois.

... + Requesting challenge for micronator-101.com... ERROR: Problem connecting to server (post for https://acme-v01.api.api.letsencrypt.org/acme/new-authz; curl returned with 35) ...

Référence: https://community.letsencrypt.org/t/curl-returned-with-35-anti-replay-nonce-seems-ipv6-related/21026.

On peut vérifier le temps de réponse pour IPv4.

# date;time curl -s4 https://acme-v01.api.letsencrypt.org/acme/new-authz >/dev/null    jeu. oct. 4 09:48:54 EDT 2018    real 0m5.264s user 0m0.058s sys 0m0.046s

On peut vérifier le temps de réponse pour IPv6.

# date;time curl -s6 https://acme-v01.api.letsencrypt.org/acme/new-authz >/dev/null    jeu. oct. 4 09:52:35 EDT 2018    real 0m47.367s user 0m0.061s sys 0m0.042s

Normalement le temps de réponse devrait être très court.

# date;time curl -s4 https:https://acme-v01.api.letsencrypt.org/acme/new-authz >/dev/null   jeu. oct. 4 09:53:29 EDT 2018   real 0m0.004s user 0m0.002s sys 0m0.000s

Vérification du certificat

Si la commande fonctionne sans erreur, essayez de vous connecter à la page du gestionnaire Server Manager. Vous devriez voir une erreur indiquant que le certificat de sécurité n'a pas été émis par une autorité de certification approuvée. C'est parfaitement normal. Cependant, il devrait incorporer tous les noms d'hôtes que vous avez inclus et être valide pour les quatre-vingt-dix prochains jours.

Avec un Serveur SME branché directement à l'Internet, on peut utiliser le FQDN du domaine.

Avec Firefox, on se connecte au gestionnaire Server Manager.  

• Après avoir accepté le certificat, on clique le cadenas puis, on clique >.
• Plus d'informations.

• Afficher le certificat.
• - Certificat de test car, émis par "Fake LE Intermediate XI".
  - Détails.

• - Nom alternatif du sujet du certificat.
  - Nos noms d'hôtes sont présents.
• - Pas après.
  - Valide pour 90 jours > Fermer.

Mode Production

Tout fonctionne correctement, on peut passer en mode Production et demander un certificat OFFICIEL.

Activation du mode Production.

# config setprop letsencrypt status enabled

On signale les changements. Peut prendre plusieurs secondes.

# signal-event console-save

Demande d'un certificat OFFICIEL

On fait la demande d'un certificat OFFICIEL. Le paramètre -x est nécessaire pour forcer un nouveau certificat.

# dehydrated -c -x

# INFO: Using main config file /etc/dehydrated/config
+ Generating account key...
+ Registering account key with ACME server...
Processing micronator-101.com with alternative names: ftp.micronator-101.com mail.micronator-101.com proxy.micronator-101.com wpad.micronator-101.com www.micronator-101.com 
 + Checking domain name(s) of existing cert... unchanged.
 + Checking expire date of existing cert...
 + Valid till Jan  2 03:50:18 2019 GMT (Longer than 30 days). Ignoring because renew was forced!
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting challenge for micronator-101.com...
  ...
 + Challenge is valid!
 + Requesting certificate...
 + Checking certificate...
 + Done!
 + Creating fullchain.pem...
 + Walking chain...
Set up modSSL db keys
Signal events
All complete
 + Done!

Si cette demande a réussie, félicitations! Vous avez obtenu un certificat TLS/SSL OFFICIEL et valide qui se renouvellera automatiquement à perpétuité.

Vérification avec le gestionnaire Server Manager

Avec Firefox, on se connecte au gestionnaire Server Manager.

• Après avoir accepté le certificat, on clique le cadenas  >  >.
• Plus d'informations.

• Afficher le certificat.
• - Certificat Officiel car, émis par Let's Encrypt Authority X3.
  - Détails.

• - Nom alternatif du sujet du certificat.

- Nos noms d'hôtes sont présents.

• - Pas après.
  

- Valide pour 90 jours   >   Fermer.

• Le certificat SAN a été émis pour le premier domaine de la ligne du fichier /etc/dehydrated/domains.txt. Ici le certificat a été émis pour le site micronator-101.com.

On affiche le fichier les domaines.

# cat /etc/dehydrated/domains.txt

micronator-101.com ftp.micronator-101.com mail.micronator-101.com proxy.micronator-101.com wpad.micronator-101.com www.micronator-101.com

Vérification par Qualsys SSLLabs

Une fois que vous avez obtenu votre certificat, testez-le en vous rendant chez Qualsys SSLLabs, https://www.ssllabs.com/ssltest/, et soumettez le nom FQDN de votre domaine pour vous assurer qu'il fonctionne correctement.

• micronator-101.com  >  Submit.
• La remarque:
  

This server does not support Forward Secrecy with the reference browsers. Grade capped to B.

peut être ignorée car, le Serveur SME ne supporte pas Forward Secrecy.

Vérification des fichiers et répertoires

On vérifie le répertoire /etc/dehydrated/.

# ls -als /etc/dehydrated/

total 44
 4 drwxr-xr-x   7 root root  4096  4 oct.  10:38 .
12 drwxr-xr-x 102 root root 12288  4 oct.  10:57 ..
 4 drwx------   4 root root  4096  4 oct.  09:43 accounts
 4 drwx------   3 root root  4096  4 oct.  00:47 certs
 4 drwx------   2 root root  4096  4 oct.  09:54 chains
 4 -rw-r--r--   1 root root   261  4 oct.  09:42 config
 4 -rw-r--r--   1 root root   139  3 oct.  18:42 domains.txt
 4 drwxr-xr-x   2 root root  4096 26 févr.  2018 hooks_clean_challenge.d
 4 drwxr-xr-x   2 root root  4096  3 oct.  16:33 hooks_deploy_cert.d

On vérifie le répertoire /etc/dehydrated/certs/.

# ls -als /etc/dehydrated/certs/

total 12
4 drwx------ 3 root root 4096  4 oct.  00:47 .
4 drwxr-xr-x 7 root root 4096  4 oct.  10:38 ..
4 drwx------ 2 root root 4096  4 oct.  09:54 micronator-101.com

  Le script a créé un répertoire de stockage pour notre domaine micronator-101.com (le premier de la ligne de notre fichier /etc/dehydrated/domains.txt).

On vérifie le répertoire micronator-101.com/.

# ls -als /etc/dehydrated/certs/micronator-101.com/

total 40
4 drwx------ 2 root root 4096  4 oct.  11:43 .
4 drwx------ 3 root root 4096  4 oct.  00:47 ..
4 -rw------- 1 root root 1838  4 oct.  09:44 cert-1538660683.csr
0 -rw------- 1 root root    0  4 oct.  09:44 cert-1538660683.pem
4 -rw------- 1 root root 1838  4 oct.  09:51 cert-1538661090.csr
4 -rw------- 1 root root 2679  4 oct.  09:54 cert-1538661090.pem
0 lrwxrwxrwx 1 root root   19  4 oct.  09:54 cert.csr -> cert-1538661090.csr
0 lrwxrwxrwx 1 root root   19  4 oct.  09:54 cert.pem -> cert-1538661090.pem
4 -rw------- 1 root root 1684  4 oct.  09:54 chain-1538661090.pem
0 lrwxrwxrwx 1 root root   20  4 oct.  09:54 chain.pem -> chain-1538661090.pem
8 -rw------- 1 root root 4363  4 oct.  09:54 fullchain-1538661090.pem
0 lrwxrwxrwx 1 root root   24  4 oct.  09:54 fullchain.pem -> fullchain-1538661090.pem
4 -rw------- 1 root root 3247  4 oct.  09:44 privkey-1538660683.pem
4 -rw------- 1 root root 3243  4 oct.  09:51 privkey-1538661090.pem
0 lrwxrwxrwx 1 root root   22  4 oct.  09:54 privkey.pem -> privkey-1538661090.pem

• Tout ce qui est relatif à 1538660683 provient du premier certificat, celui en mode TEST.
• La requête: cert-1538660683.csr.
• Le certificat: cert-1538661090.pem.
• La chaîne de certification: chain-1538661090.pem.
• La clé privée SSL du serveur: privkey-1538661090.pem.
• Les pointeurs "->"sont ajustés en conséquence.

modSSL

Les paramètres de modSSL ont été modifiés.

# config show modSSL

modSSL=service
    CertificateChainFile=/etc/dehydrated/certs/micronator-101.com/chain.pem
    TCPPort=443
    access=public
    crt=/etc/dehydrated/certs/micronator-101.com/cert.pem
    key=/etc/dehydrated/certs/micronator-101.com/privkey.pem
    status=enabled

Conclusion

• Le client /usr/bin/dehydrated fonctionne correctement de même que tous les fichiers de configuration.
• Avec le script de point d'entrée /usr/bin/dehydrated_hooks les propriétés de modSSL ont été modifiées et les changements signalés pour installer le nouveau certificat.

Renouvellement

Manuel

Situation actuelle

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

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

# dehydrated -c

# INFO: Using main config file /etc/dehydrated/config
Processing micronator-101.com with alternative names: ftp.micronator-101.com mail.micronator-101.com proxy.micronator-101.com wpad.micronator-101.com www.micronator-101.com
 + Checking domain name(s) of existing cert... unchanged.
 + Checking expire date of existing cert...
 + Valid till Jan  2 12:54:21 2019 GMT (Longer than 30 days). Skipping renew!

Au début de l'exécution, le client dehydrated:

1. a examiné le fichier /etc/dehydrated/config et n'a vu aucune modification des paramètres,
2. a examiné le fichier /etc/dehydrated/domains.txt et vu qu'il n'avait pas été modifié par rapport au dernier certificat: unchanged,
3. a vérifié la validité du certificat et vu qu'il était encore valide pour plus de 30 jours: Longer than 30 days,
4. a affiché la dernière ligne du message: Skipping renew!, et il s'est arrêté sans aller plus loin,
5. arrêté, il ne s'est pas rendu au script de point d'entrée; les propriétés de modSSL sont demeurées inchangées et il n'y a eu aucun changement de signaler.

Manuel forcé

Nous avons plusieurs choix pour lancer le client dehydrated et l'obliger à renouveler notre premier certificat.

1. Attendre la fin du certificat.
2. Révoquer le certificat.
3. Modifier un domaine du fichier domains.txt.
4. Ajouter/enlever un domaine au fichier domains.txt.
5. Utiliser l'option --force lors du lancement de la commande dehydrated.

On choisit de lancer le client dehydrated avec l'option --force pour imposer un renouvellement.

# dehydrated -c --force 

# INFO: Using main config file /etc/dehydrated/config
Processing micronator-101.com with alternative names: ftp.micronator-101.com mail.micronator-101.com proxy.micronator-101.com wpad.micronator-101.com www.micronator-101.com
 + Checking domain name(s) of existing cert... unchanged.
 + Checking expire date of existing cert...
 + Valid till Jan  2 12:54:21 2019 GMT (Longer than 30 days). Ignoring because renew was forced!
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting challenge for micronator-101.com...
 + Already validated!
 + Requesting challenge for micronator-101.com...
 + Already validated!
 + Requesting challenge for mail.micronator-101.com...
 + Already validated!
 + Requesting challenge for ftp.micronator-101.com...
 + Already validated!
 + Requesting challenge for wpad.micronator-101.com...
 + Already validated!
 + Requesting challenge for proxy.micronator-101.com...
 + Already validated!
 + Requesting certificate...
 + Checking certificate...
 + Done!
 + Creating fullchain.pem...
 + Walking chain...
Set up modSSL db keys
Signal events
All complete
 + Done!

Aucune erreur, tout a bien fonctionné pour le renouvellement forcé.

Pour ce renouvellement, le client dehydrated:

1. a commencé par analyser le fichier de configuration config, # INFO: Using main config file /etc/dehydrated/config.
2. n'a pas généré de nouvelle clé de compte Let's Encrypt.
3. n'a vu aucune modification dans les noms de domaines + Checking domain name(s) of existing cert... unchanged.
4. a vérifié la date d'expiration du certificat, + Checking expire date of existing cert...
5. a ignoré le temps de validité restant, Ignoring because renew was forced!
6. a signé les domaines + Signing domains...
7. a généré une nouvelle clé privée pour le serveur: + Generating private key...
8. n'a pas créé de nouveaux répertoires.
9. a créé une nouvelle requête CSR, + Generating signing request...
10. a requis les défis et vérifié leurs réponses, + Requesting challenge / + Already validated!.
11. a fait la demande du certificat, + Requesting certificate...,
12. une fois reçu, il a vérifié le certificat, + Checking certificate...,
13. + Done!: le tout terminé,
14. + Creating fullchain.pem... il a créé la chaîne de certification et ajusté les pointeurs.
15. a alors appelé le script de point d'entrée et celui-ci a modifié les propriétés de modSSL et signalé les changements pour activer le nouveau certificat.

Tous les répertoires existaient, la ligne ci-dessous est donc manquante avec ce renouvellement.

+ Creating new directory /etc/dehydrated/certs/micronator-101.com ...

Vérification

On vérifie le répertoire /etc/dehydrated/.

# ls -als /etc/dehydrated/

total 44
 4 drwxr-xr-x   7 root root  4096  4 oct.  12:32 .
12 drwxr-xr-x 102 root root 12288  4 oct.  12:07 ..
 4 drwx------   4 root root  4096  4 oct.  09:43 accounts
 4 drwx------   3 root root  4096  4 oct.  00:47 certs
 4 drwx------   2 root root  4096  4 oct.  09:54 chains
 4 -rw-r--r--   1 root root   261  4 oct.  09:42 config
 4 -rw-r--r--   1 root root   139  3 oct.  18:42 domains.txt
 4 drwxr-xr-x   2 root root  4096 26 févr.  2018 hooks_clean_challenge.d
 4 drwxr-xr-x   2 root root  4096  3 oct.  16:33 hooks_deploy_cert.d

Aucun nouveau répertoire n'a été créé.

On vérifie le répertoire /etc/dehydrated/certs/.

# ls -als /etc/dehydrated/certs/

total 12
4 drwx------ 3 root root 4096  4 oct.  00:47 .
4 drwxr-xr-x 7 root root 4096  4 oct.  12:32 ..
4 drwx------ 2 root root 4096  4 oct.  12:32 micronator-101.com

Aucun nouveau répertoire n'a été créé.

On vérifie le répertoire /etc/dehydrated/certs/micronator-101.com/.

# ls -als /etc/dehydrated/certs/micronator-101.com/

total 64
4 drwx------ 2 root root 4096  4 oct.  12:38 .
4 drwx------ 3 root root 4096  4 oct.  00:47 ..
4 -rw------- 1 root root 1838  4 oct.  09:44 cert-1538660683.csr
0 -rw------- 1 root root    0  4 oct.  09:44 cert-1538660683.pem
4 -rw------- 1 root root 1838  4 oct.  09:51 cert-1538661090.csr
4 -rw------- 1 root root 2679  4 oct.  09:54 cert-1538661090.pem
4 -rw------- 1 root root 1838  4 oct.  12:30 cert-1538670628.csr
4 -rw------- 1 root root 2679  4 oct.  12:32 cert-1538670628.pem
0 lrwxrwxrwx 1 root root   19  4 oct.  12:32 cert.csr -> cert-1538670628.csr
0 lrwxrwxrwx 1 root root   19  4 oct.  12:32 cert.pem -> cert-1538670628.pem
4 -rw------- 1 root root 1684  4 oct.  09:54 chain-1538661090.pem
4 -rw------- 1 root root 1684  4 oct.  12:32 chain-1538670628.pem
0 lrwxrwxrwx 1 root root   20  4 oct.  12:32 chain.pem -> chain-1538670628.pem
8 -rw------- 1 root root 4363  4 oct.  09:54 fullchain-1538661090.pem
8 -rw------- 1 root root 4363  4 oct.  12:32 fullchain-1538670628.pem
0 lrwxrwxrwx 1 root root   24  4 oct.  12:32 fullchain.pem -> fullchain-1538670628.pem
4 -rw------- 1 root root 3247  4 oct.  09:44 privkey-1538660683.pem
4 -rw------- 1 root root 3243  4 oct.  09:51 privkey-1538661090.pem
4 -rw------- 1 root root 3247  4 oct.  12:30 privkey-1538670628.pem
0 lrwxrwxrwx 1 root root   22  4 oct.  12:32 privkey.pem -> privkey-1538670628.pem

1. Nouvelle requête: cert-1538670628.csr.
2. Nouveau certificat: cert-1538670628 .pem.
3. Nouvelle chaîne de certification: chain-1538670628 .pem.
4. La nouvelle clé privée: privkey-1538670628 .pem.
5. Les pointeurs ont tous été ajustés vers *-1538670628*.

  Les propriétés de modSSL ont été modifiées mais vu que dehydrated utilise des pointeurs qui ne changent jamais de noms, il semble que les pointeurs soient demeurés les mêmes.

Ce sont les pointeurs des cibles destinataires que dehydrated a modifiées. Si, précédemment, nous avions eu un certificat d'une autre CA, nous aurions vu les modifications apportées aux propriétés de modSSL.

# config show modSSL

modSSL=service
    CertificateChainFile=/etc/dehydrated/certs/micronator-101.com/chain.pem
    TCPPort=443
    access=public
    crt=/etc/dehydrated/certs/micronator-101.com/cert.pem
    key=/etc/dehydrated/certs/micronator-101.com/privkey.pem
    status=enabled

Courriel de notification

Réception d'un courriel par admin.

À tous les jours, l'usager, spécifié par CONTACT_EMAIL=admin@micronator.org au paragraphe #Ajout d'une adresse courriel, recevra un courriel de notification pour le renseigner si le certificat a été renouvelé ou non.

# INFO: Using main config file /etc/dehydrated/config Processing micronator-101.com with alternative names: ftp.micronator-101.com mail.micronator-101.com proxy.micronator-101.com wpad.micronator-101.com www.micronator-101.com + Checking domain name(s) of existing cert... unchanged. + Checking expire date of existing cert... + Valid till Jan 2 12:54:21 2019 GMT (Longer than 30 days). Skipping renew!

Pour le message du premier renouvellement, il n'y a pas eu de nouveaux certificats d'émis car, le certificat était encore valide pour plus de 30 jours, le renouvellement a donc été outrepassé.

Fichier pem

On affiche la date de création du fichier pem après le renouvellement forcé.

# ls -ls /home/e-smith/ssl.pem/sme-9.micronator-101.com.pem

8 -rw-r--r-- 1 root root 7991  4 oct.  12:32 /home/e-smith/ssl.pem/sme-9.micronator-101.com.pem

  Le fichier pem vient tout juste d'être installé, après la réception du certificat du renouvellement forcé et en même temps que privkey.pem. Le nouveau certificat est fonctionnel.

Navigateur Web

Firefox

  La CA "Let’s Encrypt Authority X3" étant dans la chaîne des CA et de ce fait reconnue, le certificat est automatiquement accepté.

• - Site: https://www.micronator-101.com/.
  - Le cadenas est vert, on le clique.
  - On voit que la connexion est sécurisée.
  - On clique l'icône ">" à droite.
• Plus d'informations.

• Afficher le certificat.
• - Onglet Général.
  - "Émis pour micronator-101.com".
  - Émis par "Let's Encrypt Authority X3".
  - On clique l'onglet Détails.

• - Émetteur.
  - Les détails de Let's Encrypt Authority X3 sont affichés.
• - Validité   >   Pas avant.
  - La date et l'heure de l'émission sont affichées.

• - Nom alternatif du sujet du certificat.
  - Tous les domaines couverts sont affichés.
  - On ferme toutes les fenêtres.

Internet Explorer

• - Site: https://www.micronator-101.com/.
  - Il semble que c'est Avast! qui a émis le certificat?
  - On clique Afficher le certificat.
• C'est bien Avast! qui a émis le certificat.
    Les résultats qu'on voit ici sont dûs au module de l'antivirus Avast! pour IE. Ce module d'Avast! en est un du genre homme-du-milieu (man in the middle) qui intercepte toutes les requêtes https et qui émet son propre certificat.

•   La protection Courriel/Web d'Avast! doit être capable de balayer le 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. C'est uniquement de cette façon qu'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!.

Contournement du problème

• On se rend à une connexion sécurisée quelconque. Exemple: https://www.google.ca

• - On arrête les agents Avast!.
  - Clac (clic droit) sur l'icône Avast! sur la barre de notification   >   Gestion des agents Avast   >   Désactiver pour 10 minutes.
• À l'écran qui s'affiche, on clique Oui pour l'Arrêt d'un composant.

• - On se rend à: https://www.micronator-101.com/.
  - On clique le cadenas.
  - Afficher les certificats.
• - L'émetteur du certificat est affiché: "Let's Encrypt Authority X3".
  - On ferme toutes les fenêtres.

•   Il faut réactiver les agents Avast.
  Clac sur l'icône Avast! sur la barre de notifications  >  Gestion des agents Avast  >  Activer tous les Agents (3 désactivés).
• On ferme Internet Explorer, on le relance et on se rend encore une fois à https://www.micronator-101.com/; le certificat retourne à celui d'Avast!.
    Vu que chez Micronator, il est formellement interdit d'utiliser un navigateur Microsoft, de quelle que version que ce soit, on n'a pas de tels problèmes.

TOR

Le navigateur TOR est très utile pour vérifier les certificats, car il envoie la requête HTTP à Privoxy et non à votre serveur passerelle, il agit comme un fureteur provenant directement de l'Internet et non de votre réseau LOCAL. TOR fonctionne exactement comme Firefox.

Site de téléchargement: https://www.torproject.org/download/download.html.en.

  Il faut absolument télécharger TOR du site original seulement.

• Même si nous avons lancé TOR sur notre station de travail, la requête pour notre site a passé par la France, les États-Unis et l'Ukraine.
• - Le cadenas est vert, on le clique.
  - On voit que la "connexion est sécurisée".
  - On clique l'icône ">" à droite.

• More Information.
• - Onglet Security.
  - "Verified by: Let's Encrypt" est affiché.
  - View Certificate.

• Onglet General.
  Le certificat est bien "Émis pour micronator-101.com" et "Émis par Let's Encrypt Authority X3".

Conclusion

Le client dehydrated fonctionne correctement pour un demande de certificat officiel. Il en va de même pour tous les fichiers de configuration. Les propriétés de modSSL ont été modifiées, les changements signalés et le certificat installé.

Révocation

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

Affichage des certificats actuels

# ls -ls /etc/dehydrated/certs/micronator-101.com/

total 56
4 -rw------- 1 root root 1838  4 oct.  09:44 cert-1538660683.csr
0 -rw------- 1 root root    0  4 oct.  09:44 cert-1538660683.pem
4 -rw------- 1 root root 1838  4 oct.  09:51 cert-1538661090.csr
4 -rw------- 1 root root 2679  4 oct.  09:54 cert-1538661090.pem
4 -rw------- 1 root root 1838  4 oct.  12:30 cert-1538670628.csr
4 -rw------- 1 root root 2679  4 oct.  12:32 cert-1538670628.pem
0 lrwxrwxrwx 1 root root   19  4 oct.  12:32 cert.csr -> cert-1538670628.csr
0 lrwxrwxrwx 1 root root   19  4 oct.  12:32 cert.pem -> cert-1538670628.pem
4 -rw------- 1 root root 1684  4 oct.  09:54 chain-1538661090.pem
4 -rw------- 1 root root 1684  4 oct.  12:32 chain-1538670628.pem
0 lrwxrwxrwx 1 root root   20  4 oct.  12:32 chain.pem -> chain-1538670628.pem
8 -rw------- 1 root root 4363  4 oct.  09:54 fullchain-1538661090.pem
8 -rw------- 1 root root 4363  4 oct.  12:32 fullchain-1538670628.pem
0 lrwxrwxrwx 1 root root   24  4 oct.  12:32 fullchain.pem -> fullchain-1538670628.pem
4 -rw------- 1 root root 3247  4 oct.  09:44 privkey-1538660683.pem
4 -rw------- 1 root root 3243  4 oct.  09:51 privkey-1538661090.pem
4 -rw------- 1 root root 3247  4 oct.  12:30 privkey-1538670628.pem
0 lrwxrwxrwx 1 root root   22  4 oct.  12:32 privkey.pem -> privkey-1538670628.pem

Certificat de TEST

Basculement du mode OFFICIEL au mode TEST

Avant de manipuler un certificat de TEST, il faut basculer en mode TEST.

On active le mode TEST.

# config setprop letsencrypt status test

On signale les changements. (Peut prendre plusieurs secondes.)

# signal-event console-save

Vérification

On vérifie si on est bien en mode TEST.

# cat /etc/dehydrated/config | grep CA

CA="https://acme-staging.api.letsencrypt.org/directory"

Révocation

La commande générale pour la révocation d'un certificat.

dehydrated  --revoke  /chemin/du/cert-numéro.pem

  On peut révoquer notre premier certificat de TEST: cert-1538660683.pem qui est datée 4 oct. 09:44.

# dehydrated --revoke /etc/dehydrated/certs/micronator-101.com/cert-1538660683.pem

# INFO: Using main config file /etc/dehydrated/config
Revoking /etc/dehydrated/certs/micronator-101.com/cert-1538660683.pem
+ Done.
+ Renaming certificate to /etc/dehydrated/certs/micronator-101.com/cert-1538660683.pem-revoked

Basculement du mode TEST au mode OFFICIEL

  Après une manipulation en mode TEST, il devrait toujours revenir au mode OFFICIEL.

# config setprop letsencrypt status enabled

On signale les changements. (Peut prendre plusieurs secondes.)

# signal-event console-save

On vérifie.

[root@sme-9 ~]# cat /etc/dehydrated/config | grep http

CA="https://acme-staging.api.letsencrypt.org/directory"
[root@sme-9 ~]#

Nous sommes bien en mode Officiel.

Certificat officiel

Prérequis

On a décidé de retirer notre serveur pour le mettre au rancart et au lieu d'attendre la fin de vie du certificat, on choisit de le révoquer immédiatement.

Nous allons révoquer le dernier certificat obtenu, cert-1538670628.pem. Ce certificat est Officiel.

  On vérifie toujours le mode de fonctionnement avant de faire quoi que ce soit.

# cat /etc/dehydrated/config | grep http

CA="https://acme-v01.api.letsencrypt.org/directory"

Nous sommes bien en mode Officiel car, la CA est acme-v01.

Commande de révocation

On vérifie le chemin du certificat.

# ls -als /etc/dehydrated/certs/micronator-101.com/cert-1538670628.pem

4 -rw------- 1 root root 2679  4 oct.  12:32 /etc/dehydrated/certs/micronator-101.com/cert-1538670628.pem

On révoque le certificat.

# dehydrated --revoke /etc/dehydrated/certs/micronator-101.com/cert-1538670628.pem

# INFO: Using main config file /etc/dehydrated/config
Revoking /etc/dehydrated/certs/www.micronator-101.com/cert-1538670628.pem
 + Done.
 + Renaming certificate to /etc/dehydrated/certs/micronator-101.com/cert-1538670628.pem-revoked

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

Vérification

On affiche tous les certificats.

# ls -ls /etc/dehydrated/certs/micronator-101.com/

total 56
4 -rw------- 1 root root 1838  4 oct.  09:44 cert-1538660683.csr
0 -rw------- 1 root root    0  4 oct.  09:44 cert-1538660683.pem-revoked
4 -rw------- 1 root root 1838  4 oct.  09:51 cert-1538661090.csr
4 -rw------- 1 root root 2679  4 oct.  09:54 cert-1538661090.pem
4 -rw------- 1 root root 1838  4 oct.  12:30 cert-1538670628.csr
4 -rw------- 1 root root 2679  4 oct.  12:32 cert-1538670628.pem-revoked
0 lrwxrwxrwx 1 root root   19  4 oct.  12:32 cert.csr -> cert-1538670628.csr
0 lrwxrwxrwx 1 root root   19  4 oct.  12:32 cert.pem -> cert-1538670628.pem
4 -rw------- 1 root root 1684  4 oct.  09:54 chain-1538661090.pem
4 -rw------- 1 root root 1684  4 oct.  12:32 chain-1538670628.pem
0 lrwxrwxrwx 1 root root   20  4 oct.  12:32 chain.pem -> chain-1538670628.pem
8 -rw------- 1 root root 4363  4 oct.  09:54 fullchain-1538661090.pem
8 -rw------- 1 root root 4363  4 oct.  12:32 fullchain-1538670628.pem
0 lrwxrwxrwx 1 root root   24  4 oct.  12:32 fullchain.pem -> fullchain-1538670628.pem
4 -rw------- 1 root root 3247  4 oct.  09:44 privkey-1538660683.pem
4 -rw------- 1 root root 3243  4 oct.  09:51 privkey-1538661090.pem
4 -rw------- 1 root root 3247  4 oct.  12:30 privkey-1538670628.pem
0 lrwxrwxrwx 1 root root   22  4 oct.  12:32 privkey.pem -> privkey-1538670628.pem

On essaie d'afficher le certificat révoqué.

# cat /etc/dehydrated/certs/micronator-101.com/cert-1538670628.pem

cat: /etc/dehydrated/certs/micronator-101.com/cert-1538670628.pem: Aucun fichier ou dossier de ce type

  Le système nous informe que le fichier n'existe plus. La cible du lien a été renommée cert-1538670628.pem-revoked donc, le lien pointe vers une cible qui n'existe plus.

Paramètres de modSSL

Les paramètres de modSSL n'ont pas été changés; le script du point d'entrée n'a pas été utilisé pour les modifier.

Le serveur utilise donc toujours les même paramètres.

# config show modSSL

modSSL=service
    CertificateChainFile=/etc/dehydrated/certs/micronator-101.com/chain.pem
    TCPPort=443
    access=public
    crt=/etc/dehydrated/certs/micronator-101.com/cert.pem
    key=/etc/dehydrated/certs/micronator-101.com/privkey.pem
    status=enabled

Chaîne

On vérifie le fichier de la chaîne.

# cat /etc/dehydrated/certs/micronator-101.com/chain.pem

http://cert.int-x3.letsencrypt.org/
-----BEGIN CERTIFICATE-----
MIIEkjCCA3qgAwIBAgIQCgFBQgAAAVOFc2oLheynCDANBgkqhkiG9w0BAQsFADA/
...
PfZ+G6Z6h7mjem0Y+iWlkYcV4PIWL1iwBi8saCbGS5jN2p8M+X+Q7UNKEkROb3N6
KOqkqm57TH2H3eDJAkSnh6/DNFu0Qg==
-----END CERTIFICATE-----

La chaîne est toujours présente.

Clé privée du serveur

On vérifie la clé privée du serveur.

# cat /etc/dehydrated/certs/micronator-101.com/privkey.pem

-----BEGIN RSA PRIVATE KEY-----
MIIJKgIBAAKCAgEAuDz2EIb5/Q4nbXay28kym1H16hWbRuc0Acy6M+VAgQTw/8Zc
...
+JMD06yC4qyKHehSYxqUcrRPrggDwtmD6MHUvM7y+nKw03/kqzQIV/eTXnzfMdAg
feFu6GRQJNtHwQt29YFRYerKN/UA6ES+SAaXW8BKA4ByzNEpvENqGmLR0e5itg==
-----END RSA PRIVATE KEY-----

La clé privée du serveur est toujours présente.

Réamorçage du serveur

Si on réamorce le serveur, il va réamorcer mais, la console bouclera sur un message affichant que le fichier du certificat n'existe pas ou qu'il est vide.

Gestionnaire Server Manager

On ne peut plus accéder au gestionnaire Server Manager.

PuTTY

  Tout n'est pas perdu, on peut se loguer en ouvrant une session PuTTY.

login as: root

root@192.168.1.1's password:
Last login: Thu Oct  4 19:01:22 2018 from pc-00081.micronator-101.com
************ Welcome to SME Server 9.2 *************

Before editing configuration files, familiarise
yourself with the automated events and templates
systems.

Please take the time to read the documentation
http://wiki.contribs.org/Main_Page

Remember that SME Server is free to download
and use, but it is not free to build

Please help the project :
http://wiki.contribs.org/Donate

****************************************************

  Pour rétablir toutes les communications, il nous faut régénérer un certificat standard émis par le Serveur SME lui-même. Voir le chapitre #Certificat standard SME.

Obtention d'un certificat pour un serveur local

Référence: https://wiki.contribs.org/Letsencrypt#Obtaining_certificates_for_a_private_SME_Server.

Votre Serveur SME doit normalement être accessible depuis l'Internet afin que les serveurs Let's Encrypt puissent valider votre contrôle sur celui-ci. Toutefois, si votre Serveur SME n'est pas accessible depuis l'Internet, le contrib smeserver-letsencrypt fournit une méthode permettant de valider votre contrôle sur ce domaine intranet. Pour utiliser cette méthode, les conditions suivantes doivent être remplies:

• Le domaine de votre hôte interne (dev.micronator-101.com), lorsque résolu par le DNS de l'Internet, pointe vers une adresse IP publique valide.
• Le domaine vers lequel dev.micronator-101.com pointe depuis l'Internet, c.-à-d. vers micronator-101.com, dispose d'un serveur Web actif sur le port 80.
• L'utilisateur root de dev.micronator-101.com peut se connecter au serveur principal sme-9.micronator-101.com via SSH sans devoir utiliser un mot de passe (c'est-à-dire que vous avez configuré l'authentification par clé publique SSH).

Cette méthode utilise un script simple, inclus dans la contribution smeserver-letsencrypt mais, il requiert obligatoirement la définition de quatre entrées supplémentaires dans la base de données letsencrypt:

# config setprop letsencrypt hookScript enabled # config setprop letsencrypt host external.mydomain.tld # config setprop letsencrypt user root # config setprop letsencrypt path /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge

Après avoir défini ces entrées, il faut en signaler les changements.

# signal-event console-save

Les paramètres des variables soulignées ci-dessus doivent être modifiées pour correspondre à votre situation. la variable path devrait être l'emplacement du répertoire dans lequel le serveur principal sme-9.micronator-101.com sauvegarde les défis: c.-à-d. le répertoire .well-known/acme-challenge/. Lorsque le script dehydrated crée les fichiers de défis, il les transfère via SCP vers user@host:path puis, demande au serveur Let's Encrypt de les valider. Une fois la validation effectuée, le script dehydrated supprime le contenu du répertoire des défis: user@host:path.

Prérequis

Chez le registraire du domaine micronator-101.com, il faut définir les entrées pour le sous domaine dev.micronator-101.com:

dev, ftp.dev, mail.dev, proxy.dev, wpad.dev et www.dev.

Résolution Internet pour le domaine du serveur local

Nous avons ajouté les CNAME du paragraphe précédent pour le sous-domaine dev.micronator-101.com chez le régistraire du domaine micronator-101.com.

  On ne peut vérifier les CNAME du serveur à sa console car il répondra lui-même, il faut demander à un autre serveur de les vérifier.

On va envoyer une commande au serveur principal (192.168.1.1) pour qu'il lance trois ping vers le domaine dev.micronator-101.com. Le premier ping du serveur principal va débuter en demandant au serveur DNS de son FAI (Fournisseur d'Accès Internet) de résoudre le nom dev.micronator-101.com puis, il va compléter les pings vers l'adresse IP retournée par le DNS du FAI.

# ssh -p 2222 root@192.168.1.1 "ping -c3 dev.micronator-101.com"

Authentification par clé publique SSH

Il faut générer une clé SSH dont la partie publique devra être envoyée au serveur passerelle (serveur principal - 192.168.1.1) afin que l'usager root puisse se connecter sans devoir utiliser un mot de passe.

Génération de la clé SSH

Il faut être l'usager root pour générer la clé SSH de celui-ci.

# whoami

root

On génère une clé SSH de type RSA et de 2048 bits.

• On accepte le nom du fichier par défaut en tapant la touche [Entrée].
• On n'utilise pas de phrase de passe en tapant la touche [Entrée].
• On confirme en tapant encore la touche [Entrée].

# ssh-keygen -t rsa -b 2048

Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): [Entrée]
Enter passphrase (empty for no passphrase): [Entrée]
Enter same passphrase again: [Entrée]
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
4b:d5:f0:31:8b:56:c0:68:f3:7c:89:a3:be:ea:c7:7e root@dev
The key's randomart image is:
+--[ RSA 2048]----+
|   .....         |
|   ...o.         |
| o....  .        |
|ooD      .       |
|++++    S        |
|+*oo             |
|.D=              |
|.  .             |
|                 |
+-----------------+

On vérifie.

# ls -ls .ssh/

total 8
4 -rw------- 1 root root 1675  4 oct.  20:33 id_rsa
4 -rw-r--r-- 1 root root  390  4 oct.  20:33 id_rsa.pub
0 -rw-r--r-- 1 root root    0  4 oct.  20:32 known_hosts

  La clé id_rsa est la clé privée qui doit toujours être cachée et n'être divulguée à absolument personne.

La clé id_rsa.pub est la clé publique et peut être partagée avec n'importe qui. Elle sert à chiffrer un message qui vous est destiné et que seule votre clé privée peut déchiffrer.

Différence entre les jeux de clés SSH de l'utilisateur root et ceux du Serveur SME

  Ce jeu de clés SSH servira uniquement à l'utilisateur root pour ses communications SSH entre le serveur intranet et le serveur principal.

  Ce jeu de clés SSH est différent du jeu standard d'un Serveur SME qui se trouve dans le répertoire /etc/ssh/ et qui comprend: ssh_host_rsa_key et ssh_host_rsa_key.pub.

# ls -als /etc/ssh/ssh_host_rsa*

4 -rw------- 1 root root 1675 16 juil. 10:04 /etc/ssh/ssh_host_rsa_key
4 -rw-r--r-- 1 root root  382 16 juil. 10:04 /etc/ssh/ssh_host_rsa_key.pub

Port SSHD

Le port standard utilisé par le démon SSHD est 22. Pour déjouer un peu plus les pirates malveillants, lors de l'installation de nos Serveurs SME, nous configurons toujours le port 2222 comme port par défaut pour SSHD.

La contribution smeserver-letsencrypt utilise le port standard 22 pour les communications (ssh et scp) entre le serveur local et le serveur principal.

Nous allons forcer cette communication à utiliser le port 2222 en créant un fichier de configuration pour le démon SSHD. Ce fichier, config, doit être créé dans le répertoire .ssh de l'usager root.

  Les paramètres dans le fichier de configuration SSH de root auront préséance sur tous les autres paramètres spécifiant le port SSH pour cet utilisateur seulement.

Spécification du port SSH pour l'utilisateur root

Il existe plusieurs façons de spécifier ce port mais, la plus efficace est celle ci-dessous.

Host *     Port 2222

Pour plus d'information, voir: https://www.digitalocean.com/community/tutorials/how-to-configure-custom-connection-options-for-your-ssh-client.

Nous aurions pu utiliser l'expression suivante pour spécifier uniquement le nom d'un hôte particulier.

Host 192.168.1.1     Port 2222

Ou celle-ci pour spécifier tous les serveur sur le réseau 192.168.1.0.

Host 192.168.1.0/24     Port 2222

On peut aussi spécifier des hôtes utilisant des ports différents.

Host 192.168.1.1     Port 2222    Host 192.168.1.11     Port 3333

    Il faut que le mot "Port" soit à au moins un espace de la marge de gauche.

On spécifie le port à utiliser pour communiquer avec notre serveur passerelle à l'adresse 192.168.1.1.

  Prendre tout le contenu de l'encadré pour la commande.

cat > /root/.ssh/config <<'EOT'

Host 192.168.1.1
     Port 2222

EOT

On vérifie le contenu.

# cat /root/.ssh/config

Host 192.168.1.1
     Port 2222

  Il peut y avoir une ligne vide avant la ligne Host 192.168.1.1.

Téléversement de la clé SSH publique de root

Sommes-nous toujours l'usager root?

# whoami

root

On téléverse la clé publique de root sur notre serveur passerelle (192.168.1.1) afin qu'il puisse entrer en communication SSH avec ce serveur sans devoir utiliser un mot de passe.

  La commande est sur trois lignes.

# cat .ssh/id_rsa.pub \
      | ssh root@192.168.1.1 \
      "cat >> /root/.ssh/authorized_keys2"

The authenticity of host '[192.168.1.1]:2222 ([192.168.1.1]:2222)' can't be established.
RSA key fingerprint is be:a1:2f:cf:c1:5f:05:53:1a:12:c8:75:c7:a4:1c:6f.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[192.168.1.1]:2222' (RSA) to the list of known hosts.
root@192.168.1.1's password: mot-de-passe-de-root-du_serveur-passerelle

• Première ligne: cat .ssh/id_rsa.pub \ indique d'afficher la clé publique id_rsa.pub. Le caractère "\" à la fin de la ligne indique que la commande se poursuit sur la ligne suivante.
• Deuxième ligne: le caractère de pipe "|" au début de la ligne indique de passer le résultat de la commande précédente cat à la commande suivante ssh. Le paramètre -p 2222 n'est pas utilisé car, il l'est dans le fichier config. Le paramètre root@192.168.1.1 indique de se connecter en tant que root à l'adresse 192.168.1.1.
• Troisième ligne, qui est entre guillemets "...", indique au serveur de destination c.-à-d. sme-9 (le serveur principal - passerelle) d'exécuter la commande qui se trouve entre ces guillemets. Donc, le serveur sme-9 va afficher avec cat ce qu'il reçoit et va l'ajouter >> à son fichier: /root/.ssh/authorized_keys2.

Vérification de la connexion

On vérifie la connexion ssh sans port et sans mot de passe.

# ssh root@192.168.1.1

Last login: Wed Oct  3 18:01:07 2018 from 192.168.1.81
************ Welcome to SME Server 9.2 *************

Before editing configuration files, familiarise
yourself with the automated events and templates
systems.

Please take the time to read the documentation
http://wiki.contribs.org/Main_Page

Remember that SME Server is free to download
and use, but it is not free to build

Please help the project :
http://wiki.contribs.org/Donate

****************************************************
[root@sme-9 ~]#

Nous sommes à la console du serveur passerelle sme-9. La connexion sans mot de passe fonctionne.

On se désengage de la connexion sans mot de passe.

# exit

logout
Connection to 192.168.1.1 closed.
[root@dev ~]#

Nous sommes de retour à la console du serveur LOCAL dev.

Entrées supplémentaires dans la base de données letsencrypt

hookScript

Activation du script qui s'occupe de récupérer le certificat Let's Encrypt pour un serveur inttranet.

# config setprop letsencrypt hookScript enabled

host

On indique l'adresse IP de la passerelle.

# config setprop letsencrypt host 192.168.1.1

user

L'usager qui récupérera le certificat.

# config setprop letsencrypt user root

path

Le chemin du répertoire de stockage des défis sur le serveur passerelle.

# config setprop letsencrypt path /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge

On signale les changements (peut prendre plusieurs secondes).

# signal-event console-save

On vérifie les quatre entrées ajoutées dans la BD letsencrypt.

# config show letsencrypt

letsencrypt=service
    ACCEPT_TERMS=yes
    configure=none
    email=admin@micronator.org
    hookScript=enabled
    host=192.168.1.1
    path=/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge
    status=test
    user=root

Choix des domaines et des hôtes

On affiche les nom d'hôtes sur notre Serveur SME.

# db hosts show | grep .com

dev.micronator-101.com=host
ftp.micronator-101.com=host
mail.micronator-101.com=host
proxy.micronator-101.com=host
wpad.micronator-101.com=host
www.micronator-101.com=host

  Si certains de vos défis sont renvoyés sans erreur, mais que certains échouent, il est possible que vous n'ayez pas d'enregistrements DNS A, MX ou CNAME pour tous les noms d'hôtes que vous avez ajoutés à votre certificat. Lorsque Let's Encrypt lance les défis pour une liste de noms d'hôtes et qu'un de ceux-ci ne répond pas, le défi échoue et le certificat n'est pas généré.

La cause principale des défis non relevés est qu'il n'existe pas d'enregistrements DNS pour tous les noms d'hôtes ajoutés au certificat. La plupart des administrateurs de systèmes ne créent pas tous les enregistrements DNS nécessaires et le certificat n'est pas généré.

Si on veut obtenir un certificat pour tous all les domaines et tous les noms d'hôtes.

# config setprop letsencrypt configure all

  La commande config setprop letsencrypt configure all est susceptible de provoquer une erreur de défi.

  Nous voulons tous les noms d'hôtes affichés avec la commande db hosts show | grep .org sauf celui du nom du serveur: dev.micronator-101.com car, ce dernier ne répond pas au défis de Let's Encrypt.

Pour utiliser des hôtes ou des domaines activés individuellement, on active le paramètre configure à none et ensuite on ajoute les domaines et les noms d'hôtes désirés.

# config setprop letsencrypt configure none

Domaines

On inclut micronator-101.com.

# db domains setprop micronator-101.com letsencryptSSLcert enabled

On vérifie.

# db domains show

micronator-101.com=domain
    Content=Primary
    Description=Primary domain
    Nameservers=localhost
    Removable=no
    SystemPrimaryDomain=yes
    letsencryptSSLcert=enabled

Hôtes

On inclut tous les hôtes suivants.

On inclut tous les hôtes suivants.

# db hosts setprop ftp.micronator-101.com letsencryptSSLcert enabled

# db hosts setprop mail.micronator-101.com letsencryptSSLcert enabled

# db hosts setprop proxy.micronator-101.com letsencryptSSLcert enabled

# db hosts setprop wpad.micronator-101.com letsencryptSSLcert enabled

# db hosts setprop www.micronator-101.com letsencryptSSLcert enabled

Autres propriétés de configuration

Aucun autre paramètre n'est obligatoire; cependant, il est recommandé de configurer une adresse courriel. Si un problème est rencontré lors du renouvellement de votre certificat, les serveurs de Let's Encrypt vous en informeront.

Ajout d'une adresse courriel

Le domaine de messagerie spécifié n'a nul besoin de correspondre à l'un des domaines pour lesquels vous demandez un certificat.

# config setprop letsencrypt email admin@micronator.org

Longueur de la clé privée

Si vous ne voulez pas la valeur par défaut de 4096 bits, vous pouvez définir la longueur de la clé privée de votre certificat,. Ceci ne devrait pas être nécessaire dans la plupart des cas mais; si vous le souhaitiez, il faudrait utiliser la commande ci-dessous pour ce faire.

# config setprop letsencrypt keysize LONGUEUR-EN-BITS

Termes et conditions

  Veuillez d'abord lire les conditions d'utilisation de Let's Encrypt: https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf.

  Si vous acceptez les termes et conditions de Let's Encrypt, lancez la commande ci-dessous.

# config setprop letsencrypt ACCEPT_TERMS yes

Activation du mode TEST

L'étape suivante consiste à activer le mode TEST. Ce mode va obtenir des certificats du serveur de TEST de Let's Encrypt. Les limites 5/7 (5 certificats par 7 jours) ne s'appliqueront pas. Toutes erreurs ou autres problèmes rencontrés ne vous empêchera pas, plus tard, d'obtenir votre certificat de Production.

On active le mode TEST.

# config setprop letsencrypt status test

On signale les changements. (Peut prendre plusieurs secondes.)

# signal-event console-save

Vérification

On vérifie si on est bien en mode TEST.

# cat /etc/dehydrated/config | grep CA

CA="https://acme-staging.api.letsencrypt.org/directory"

On vérifie l'adresse courriel.

# cat /etc/dehydrated/config | grep CONTACT

CONTACT_EMAIL=admin@micronator.org

On vérifie les domaines et les hôtes.

# cat /etc/dehydrated/domains.txt

micronator-101.com ftp.micronator-101.com mail.micronator-101.com proxy.micronator-101.com wpad.micronator-101.com www.micronator-101.com

  Tout le contenu du fichier domains.txt doit être entièrement sur une seule ligne sinon, vous aurez autant de certificats que de lignes et vous atteindrez la limite 5/7 de Let's Encrypt.

  Le certificat sera émis au nom du premier domaine de la ligne; ici, ce sera micronator-101.com.

Lancement du script dehydrated

On lance le script dehydrated pour une demande de certificat de TEST.

# dehydrated -c

# INFO: Using main config file /etc/dehydrated/config
Processing micronator-101.com with alternative names: ftp.micronator-101.com mail.micronator-101.com proxy.micronator-101.com wpad.micronator-101.com www.micronator-101.com
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting challenge for micronator-101.com...
 + Requesting challenge for ftp.micronator-101.com...
 + Requesting challenge for mail.micronator-101.com...
 + Requesting challenge for proxy.micronator-101.com...
 + Requesting challenge for wpad.micronator-101.com...
 + Requesting challenge for www.micronator-101.com...
RdLqObJEtSTsoRN5MCTm_z1_BmlChO8iujvnlSTeDWE               100%   87     0.1KB/s   00:00
 + Responding to challenge for micronator-101.com...
 + Challenge is valid!
w2FjC7gHl7QIPtcsANXxNW_HuW2y63WJQVT7fGobVM8               100%   87     0.1KB/s   00:00
 + Responding to challenge for ftp.micronator-101.com...
 + Challenge is valid!
diMmotJJNeA1-FHvfynw0acXqtsYXbW7Gf3rur7qTRs               100%   87     0.1KB/s   00:00
 + Responding to challenge for mail.micronator-101.com...
 + Challenge is valid!
fqFcnfB7aS5sqQ38UeOBeaur_zwyjKnglbLeOmDOvGo               100%   87     0.1KB/s   00:00
 + Responding to challenge for proxy.micronator-101.com...
 + Challenge is valid!
aoTY6BOoSW-sayKX400sAjhyXGBqZluI7cCizMfWlKo               100%   87     0.1KB/s   00:00
 + Responding to challenge for wpad.micronator-101.com...
 + Challenge is valid!
xLu4S7Xl-8Hm8hIchEXKmYicpywf6cp5DQjAuN2F-gY               100%   87     0.1KB/s   00:00
 + Responding to challenge for www.micronator-101.com...
 + Challenge is valid!
 + Requesting certificate...
 + Checking certificate...
 + Done!
 + Creating fullchain.pem...
 + Walking chain...
Set up modSSL db keys
Signal events
All complete
 + Done!

ERREUR

  Si vous recevez l'erreur ci-dessous, simplement relancer la demande. Il se peut que vous ayez à le faire plusieurs fois.

# dehydrated -c   # INFO: Using main config file /etc/dehydrated/config ERROR: Problem connecting to server (get for https://acme-v01.api.letsencrypt.org/directory; curl returned with 6)

Si les serveurs Let's Encrypt sont très occupés, ils peuvent retourner l'erreur ci-dessous. Simplement relancer la demande. Il se peut que vous ayez à le faire plusieurs fois.

... + Requesting challenge for micronator-101.com... ERROR: Problem connecting to server (post for https://acme-v01.api.api.letsencrypt.org/acme/new-authz; curl returned with 35) ...

Référence: https://community.letsencrypt.org/t/curl-returned-with-35-anti-replay-nonce-seems-ipv6-related/21026.

On peut vérifier le temps de réponse pour IPv4.

# date;time curl -s4 https://acme-v01.api.letsencrypt.org/acme/new-authz >/dev/null    jeu. oct. 4 09:48:54 EDT 2018    real 0m5.264s user 0m0.058s sys 0m0.046s

On peut vérifier le temps de réponse pour IPv6.

# date;time curl -s6 https://acme-v01.api.letsencrypt.org/acme/new-authz >/dev/null    jeu. oct. 4 09:52:35 EDT 2018    real 0m47.367s user 0m0.061s sys 0m0.042s

Normalement le temps de réponse devrait être très court.

# date;time curl -s4 https:https://acme-v01.api.letsencrypt.org/acme/new-authz >/dev/null   jeu. oct. 4 09:53:29 EDT 2018   real 0m0.004s user 0m0.002s sys 0m0.000s

Vérification du certificat

Si la commande fonctionne sans erreur, essayez de vous connecter à la page du gestionnaire Server Manager. Vous devriez voir une erreur indiquant que le certificat de sécurité n'a pas été émis par une autorité de certification approuvée. C'est parfaitement normal. Cependant, il devrait incorporer tous les noms d'hôtes que vous avez inclus et être valide pour les quatre-vingt-dix prochains jours.

  Avec un Serveur SME branché directement à l'Internet, on peut utiliser le FQDN du domaine mais, nous somme sur un réseau LOCAL.

Fichier hosts

Nous sommes sur un réseau LOCAL qui ne possède pas de serveur DNS. Normalement, on ne pourrait pas utiliser le FQDN du domaine local pour rejoindre notre serveur intranet.

On peut utiliser une "passe croche" pour simuler un serveur DNS sur notre réseau LOCAL.

Référence: https://fr.wikipedia.org/wiki/Hosts.

Le fichier hosts est un fichier utilisé par le système d'exploitation d'un ordinateur lors de l'accès à un réseau, comme Internet par exemple. Son rôle est d'associer des noms d'hôtes à des adresses IP. Lors de l'accès à une ressource réseau par nom de domaine, ce fichier est consulté avant l'accès au serveur DNS et permet au système de connaître l'adresse IP associée au nom de domaine sans avoir recours à une requête DNS.

  Pour "simuler" un serveur DNS, on peut faire des entrées dans le fichier hosts de la station de travail et y indiquer l'adresse IP de notre Serveur SME local.

Sur une station Windows, le fichier hosts se trouve dans le répertoire:

C:\Windows\System32\drivers\etc\.

Clac (clic droit) sur le fichier > Propriétés.

Le fichier est en Lecture seule, on décoche ce paramètre > OK.

  Pour une station Linux, le fichier hosts réside dans le répertoire /etc.

On édite le fichier hosts et on entre les noms et l'adresse IP de notre Serveur SME intranet après les lignes localhost.

...
# localhost name resolution is handled within DNS itself.
#    127.0.0.1       localhost
#    ::1             localhost

# Serveur SME sur le réseau local

192.168.1.11    dev.micronator-101.com
192.168.1.11    www.dev.micronator-101.com
...

  On remet le fichier en Lecture seule.
Vidange du cache DNS

Sur la station de travail, on ouvre un écran de commande et on vide le cache DNS de la station.

C:\Users\michelandre> ipconfig /flushdns

Configuration IP de Windows

Cache de résolution DNS vidé.

C:\Users\michelandre>

Vidange de l'historique

  On vidange l'historique de notre navigateur.

Vérification du certificat

  Il faut autoriser java script et les témoins dans notre fureteur.

Essayez de vous connecter à la page du gestionnaire Server Manager https://www.dev.micronator-101.com/server-manager. Vous devriez voir une erreur indiquant que le certificat de sécurité n'a pas été émis par une autorité de certification approuvée. C'est parfaitement normal. Cependant, il devrait incorporer tous les noms d'hôtes que nous avons inclus et être valide pour les quatre-vingt-dix prochains jours.

Avec Firefox, on se connecte au gestionnaire Server Manager.  

• Après avoir accepté le certificat, on clique le cadenas puis, l'icône ">".
  
• Plus d'informations.
• Afficher le certificat.

• - Certificat de test car, émis par "Fake LE Intermediate XI".
  - Détails.
• - Nom alternatif du sujet du cer­tificat.
  - Nos noms d'hôtes sont présents.
• - Pas après.
  Valide pour 90 jours.
  - Fermer.

Mode Production

Tout fonctionne correctement, on peut passer en mode Production et demander un certificat officiel.

Activation du mode Production.

# config setprop letsencrypt status enabled

On signale les changements. (Peut prendre plusieurs secondes.)

# signal-event console-save

On vérifie.

# cat /etc/dehydrated/config | grep CA

CA="https://acme-v01.api.letsencrypt.org/directory"

Demande d'un certificat officiel

On fait la demande d'un certificat officiel. Le paramètre -x est nécessaire pour forcer un nouveau certificat

# dehydrated -c -x

# INFO: Using main config file /etc/dehydrated/config
+ Generating account key...
+ Registering account key with ACME server...
Processing micronator-101.com with alternative names: ftp.micronator-101.com mail.micronator-101.com proxy.micronator-101.com wpad.micronator-101.com www.micronator-101.com
 + Checking domain name(s) of existing cert... unchanged.
 + Checking expire date of existing cert...
 + Valid till JJan  2 23:41:04 2019 GMT (Longer than 30 days). Ignoring because renew was forced!
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting challenge for dev.micronator-101.com...
 ...
hI3Yhd8hdrdAGdP4F42TKbVr_lpE1Yig0xvGhxqT87s               100%   87     0.1KB/s   00:00
 + Responding to challenge for dev.micronator-101.com...
 + Challenge is valid!
 + Requesting certificate...
 + Checking certificate...
 + Done!
 + Creating fullchain.pem...
 + Walking chain...
Set up modSSL db keys
Signal events
All complete
 + Done!

  Si vous recevez l'erreur ci-dessous, simplement relancer la demande. Il se peut que vous ayez à le faire plusieurs fois.

# dehydrated -c   # INFO: Using main config file /etc/dehydrated/config ERROR: Problem connecting to server (get for https://acme-v01.api.letsencrypt.org/directory; curl returned with 6)

Vérification du certificat

On se rend à: https://www.dev.micronator-101.com/.

• Le cadenas est vert.
• Émis par: "Let's Encrypt Authority X3".
• Tous les noms d'hôtes sont présents   >   Fermer.

Sauvegarde du répertoire /etc/dehydrated

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, dans la sauvegarde standard, le répertoire /etc/dehydrated.

Référence: https://wiki.contribs.org/Backup_with_dar#Adding.2FExcluding_Directories_and_Files_from_the_backup_list.

Création du gabarit personnalisé

On crée le répertoire pour le gabarit personnalisé.

# 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 vérifie.

# ls -lsd /etc/e-smith/templates-custom/etc/dar/DailyBackup.dcf

4 drw------- 2 root root 4096  2 mars  21:50 /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/dehydrated et les scripts s'y rapportant.

  Prendre tout le contenu de l'encadré pour la commande.

cat > /etc/e-smith/templates-custom/etc/dar/DailyBackup.dcf/41go-into <<'EOT'
# 
# Indique à la sauvegarde d'inclure le répertoire /etc/dehydrated et tous ses 
# sous-répertoires dans la sauvegarde standard.
--go-into etc/dehydrated
--go-into usr/bin/dehydrated
--go-into usr/bin/dehydrated_hooks
--go-into usr/bin/dehydrated_revoke

EOT

  Il n'y a pas de caractère "/" avant au début des chemins.

  Contrairement à ce qui est décrit dans la Contrib, il faut aussi utiliser --go-into pour les fichiers.

On vérifie.

# cat /etc/e-smith/templates-custom/etc/dar/DailyBackup.dcf/41go-into

#
# Indique à la sauvegarde d'inclure le répertoire /etc/dehydrated et tous ses
# sous-répertoires dans la sauvegarde standard.
--go-into etc/dehydrated
--go-into usr/bin/dehydrated
--go-into usr/bin/dehydrated_hooks
--go-into usr/bin/dehydrated_revoke

On développe le gabarit personnalisé.

# expand-template /etc/dar/DailyBackup.dcf

On vérifie que le fichier 41go-into a bien été incorporé dans DailyBackup.dcf.

# cat /etc/dar/DailyBackup.dcf | grep dehydrated

# Indique à la sauvegarde d'inclure le répertoire /etc/dehydrated et tous ses
--go-into etc/dehydrated
--go-into usr/bin/dehydrated
--go-into usr/bin/dehydrated_hooks
--go-into usr/bin/dehydrated_revoke

Vérification

Le lendemain de ces procédures, avec VirtualBox, nous avons créé un serveur virtuel et nous y avons restauré la sauvegarde de la nuit précédente.

# date

ven. mars  3 15:59:53 EST 2017

Dans le gestionnaire Server Manager, on examine l'écran lors de la restauration.

...
Restoring file's data: /etc/dehydrated/certs
Restoring file's data: /etc/dehydrated/certs/micronator-101.com
...
Restoring file's data: /etc/dehydrated/certs/micronator-101.com/privkey-1488421520.pem
Restoring file's data: /etc/dehydrated/certs/micronator-101.com/privkey-1488505534.pem
Restoring file's data: /etc/dehydrated/certs/micronator-101.com/privkey.pem
Restoring file's data: /etc/dehydrated/certs/micronator-101.com/fullchain.pem
Restoring file's data: /etc/dehydrated/certs/micronator-101.com/cert-1488421520.csr
Restoring file's data: /etc/dehydrated/certs/micronator-101.com/cert-1488421520.pem
Restoring file's data: /etc/dehydrated/certs/micronator-101.com/chain-1488463899.pem
Restoring file's data: /etc/dehydrated/domains.txt
Restoring file's data: /etc/dehydrated/config
...
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/41go-into
...

Nous voyons que l'inclusion du répertoire et des sous-répertoires de /etc/dehydrated a bien fonctionnée.

Gabarit personnalisé httpd.conf

Précédemment, au paragraphe #Gabarit personnalisé, nous avons créé un gabarit personnalisé contenant le fichier VirtualHosts40ACME pour indiquer à Apache un alias pour le répertoire acme-challenge.

On vérifie si ce gabarit a bien été inclus dans la sauvegarde standard du Serveur SME.

À la console du nouveau serveur virtuel restauré, on affiche le répertoire de ce gabarit pour vérifier s'il a été restauré.

# ls -ls /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf

total 4
4 -rw-r--r-- 1 root root 129  1 mars  19:35 VirtualHosts40ACME

  Le gabarit personnalisé httpd.conf a été sauvegardé et restauré car, il faisait partie des répertoires de la sauvegarde standard du Serveurs SME.

Certificat standard SME

On veut recréer un certificat original émis et certifié par le Serveur SME-9.x lui-même.

Login

Après s'être logué avec l'utilisateur root, on devrait être dans le répertoire personnel de ce dernier.

On vérifie.

# pwd

/root

Création d'un répertoire de sauvegarde

On crée un répertoire de sauvegarde.

# mkdir dehydrated

On vérifie.

# ls -alsd dehydrated/

4 drwxr-xr-x 2 root root 4096 3 mars  17:22 dehydrated/

On se rend dans le répertoire de sauvegarde.

# cd dehydrated/

On vérifie.

# pwd

/root/dehydrated

Sauvegarde des fichiers du certificat actuel

Recherche des chemins des fichiers du certificat présentement actif.

# cat /etc/httpd/conf/httpd.conf  | grep SSLCertificate

SSLCertificateChainFile /etc/dehydrated/certs/micronator-101.com/chain.pem
SSLCertificateFile /etc/dehydrated/certs/micronator-101.com/cert.pem
SSLCertificateKeyFile /etc/dehydrated/certs/micronator-101.com /privkey.pem

On sauvegarde le fichier de la chaîne de certification.

# cp /etc/dehydrated/certs/micronator-101.com /chain.pem .

On sauvegarde le fichier du certificat.

# cp /etc/dehydrated/certs/micronator-101.com /cert.pem .

On sauvegarde le fichier de la clé privée.

# cp /etc/dehydrated/certs/micronator-101.com /privkey.pem .

On vérifie le fichier pem.

# ls -ls /home/e-smith/ssl.pem/

total 8
8 -rw-r--r-- 1 root root 7637  2 mars  20:46 sme-9.micronator-101.com.pem

On sauvegarde le fichier pem.

# cp /home/e-smith/ssl.pem/sme-9.micronator-101.com.pem .

On vérifie les sauvegardes.

ls -ls

total 20
4 -rw------- 1 root root 2329  3 mars  17:23 cert.pem
4 -rw------- 1 root root 1684  3 mars  17:23 chain.pem
4 -rw------- 1 root root 3243  3 mars  17:23 privkey.pem
8 -rw-r--r-- 1 root root 7637  3 mars  17:25 sme-9.micronator-101.com.pem

Suppression de certaines propriétés de modSSL

On affiche les propriétés de modSSL.

# config show modSSL

modSSL=service
    CertificateChainFile=/etc/dehydrated/certs/micronator-101.com/chain.pem
    TCPPort=443
    access=public
    crt=/etc/dehydrated/certs/micronator-101.com /cert.pem
    key=/etc/dehydrated/certs/micronator-101.com /privkey.pem
    status=enabled

On supprime la propriété CertificateChainFile.

# config delprop modSSL CertificateChainFile

On supprime la propriété crt.

# config delprop modSSL crt

On supprime la propriété key.

# config delprop modSSL key

On vérifie les propriétés de modSSL.

# config show modSSL

modSSL=service
    TCPPort=443
    access=public
    status=enabled

Paramètres de tous les anciens certificats standards

  On utilise la très dangereuse commande rm -rf pour supprimer tous les anciens: .crt, .key et .pem du Serveur SME.

.crt

# rm -rf /home/e-smith/ssl.crt/*

On vérifie.

# ls -als /home/e-smith/ssl.crt/

total 8
4 drwx------  2 root  root  4096  3 mars  18:13 .
4 drwxr-xr-x 10 admin admin 4096  3 mars  17:55 ..

.key

# rm -rf /home/e-smith/ssl.key/*

On vérifie.

# ls -als /home/e-smith/ssl.key/

total 8
4 drwx------  2 root  root  4096  3 mars  18:14 .
4 drwxr-xr-x 10 admin admin 4096  3 mars  17:55 ..

.pem

# rm -rf /home/e-smith/ssl.pem/*

On vérifie.

# ls -als  /home/e-smith/ssl.pem/

total 8
4 drwx------  2 root  root  4096  3 mars  18:14 .
4 drwxr-xr-x 10 admin admin 4096  3 mars  17:55 ..

Signalisation des changements

Il faut signaler les changements avec un des blocs de commandes ci-dessous:

• Si on ne veut pas réamorcer, on lance le bloc de commandes suivant.

  Sans réamorçage, le serveur ne prendra que quelques secondes pour effectuer les modifications nécessaires.

# signal-event domain-modify ; signal-event email-update ; signal-event ibay-modify

• Si on veut réamorcer, on applique les changements en signalant une mise à jour et un réamorçage.

# signal-event post-upgrade ; signal-event reboot

Si on choisit le bloc de commandes avec réamorçage, la commande signal-event post-upgrade mettra à jour les paramètres de configuration de modSSL, le serveur réamorcera pour activer tous les nouveaux paramètres et prendra environ une minute pour redevenir actif.

Vérification

Console du serveur

On affiche la date.

# date

ven. mars  3 18:30:02 EST 2017

Fichier pem.

# ls -ls /home/e-smith/ssl.pem/

total 4
4 -rw-r--r-- 1 root root 3564  3 mars  18:23 sme-9.micronator-101.com.pem

Le fichier pem vient tout juste d'être recréé depuis quelques minutes seulement.

Navigateur Web

On se rend au site: https://micronator-101.com.

• Firefox affiche un écran d'avertissement. Avancé  >  Ajouter une exception...  >  On clique le cadenas puis, l'icône ">".  >  Plus d'informations.  >  Afficher le certificat.  >  Onglet Détails.  >  Validité   >  Pas avant.

Le certificat est au nom de: sme-9.micronator-101.com.

On voit qu’il vient d'être émis 3 mars 2017 18:23:01 en même temps que la création du fichier pem (lors du réamorçage).

Fermer toutes les fenêtres.

Le nouveau certificat, émis et certifié par le Serveur sme-9 lui-même, est fonctionnel.

  Victoire totale, hissons la bannière de la victoire.

---