Difference between revisions of "SME-101.04 Certificat Let's Encrypt"
Michelandre (talk | contribs) (GA-0.0.4 // Ajout du modèle "ParticulariteDeCeDocument" avant "Cours SME-101" // 2018-11-20 @ 12h13 HNE) |
m |
||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 6: | Line 6: | ||
|} | |} | ||
<!-- ########################################################################### -->= Description générale = | <!-- ########################################################################### -->= Description générale = | ||
| + | |||
| + | {{Warning box| type= Attention !|Veuillez noter que ce tutoriel est obsolète par rapport aux mises à jour récentes de la contribution, en attendant les modifications pertinentes.}} | ||
| + | {{Warning box|Please be aware that this how to is out of date in relation to recent contrib updates, awaiting relevant changes.}} | ||
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. | 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. | + | 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 https://wiki.contribs.org/Letsencrypt]. | + | Ce cahier est inspiré de la Contribution Letsencrypt produite par Flep, Hfwang, DanB35 et Brianr. [https://wiki.contribs.org/Letsencrypt https://wiki.contribs.org/Letsencrypt/fr]. |
* ''Conventions'': [[#Particularités de ce document]]. | * ''Conventions'': [[#Particularités de ce document]]. | ||
Latest revision as of 15:37, 19 February 2020
|
|
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/fr.
- Conventions: #Particularités de ce document.
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)
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:
- obtenir un certificat pour le(s) domaine(s) souhaité(s), et
- 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 configurationconfig.
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
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
modSSLet 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 |
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.
|
... |
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 |
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 |
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 |
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/dehydratedfonctionne correctement de même que tous les fichiers de configuration. - Avec le script de point d'entrée
/usr/bin/dehydrated_hooksles propriétés demodSSLont é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:
- a examiné le fichier
/etc/dehydrated/configet n'a vu aucune modification des paramètres, - a examiné le fichier
/etc/dehydrated/domains.txtet vu qu'il n'avait pas été modifié par rapport au dernier certificat: unchanged, - a vérifié la validité du certificat et vu qu'il était encore valide pour plus de 30 jours: Longer than 30 days,
- a affiché la dernière ligne du message: Skipping renew!, et il s'est arrêté sans aller plus loin,
- arrêté, il ne s'est pas rendu au script de point d'entrée; les propriétés de
modSSLsont 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.
- Attendre la fin du certificat.
- Révoquer le certificat.
- Modifier un domaine du fichier domains.txt.
- Ajouter/enlever un domaine au fichier
domains.txt. - Utiliser l'option
--forcelors 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:
- a commencé par analyser le fichier de configuration
config, # INFO: Using main config file /etc/dehydrated/config. - n'a pas généré de nouvelle clé de compte Let's Encrypt.
- n'a vu aucune modification dans les noms de domaines + Checking domain name(s) of existing cert... unchanged.
- a vérifié la date d'expiration du certificat, + Checking expire date of existing cert...
- a ignoré le temps de validité restant, Ignoring because renew was forced!
- a signé les domaines + Signing domains...
- a généré une nouvelle clé privée pour le serveur: + Generating private key...
- n'a pas créé de nouveaux répertoires.
- a créé une nouvelle requête CSR, + Generating signing request...
- a requis les défis et vérifié leurs réponses, + Requesting challenge / + Already validated!.
- a fait la demande du certificat, + Requesting certificate...,
- une fois reçu, il a vérifié le certificat, + Checking certificate...,
- + Done!: le tout terminé,
- + Creating fullchain.pem... il a créé la chaîne de certification et ajusté les pointeurs.
- a alors appelé le script de point d'entrée et celui-ci a modifié les propriétés de
modSSLet 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
- Nouvelle requête: cert-1538670628.csr.
- Nouveau certificat: cert-1538670628 .pem.
- Nouvelle chaîne de certification: chain-1538670628 .pem.
- La nouvelle clé privée: privkey-1538670628 .pem.
- 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 |
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 |
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[1] 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 * |
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 |
Ou celle-ci pour spécifier tous les serveur sur le réseau 192.168.1.0.
|
Host 192.168.1.0/24 |
On peut aussi spécifier des hôtes utilisant des ports différents.
|
Host 192.168.1.1 |
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é publiqueid_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 suivantessh. Le paramètre-p 2222n'est pas utilisé car, il l'est dans le fichierconfig. Le paramètreroot@192.168.1.1indique de se connecter en tant que root à l'adresse192.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 aveccatce 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 |
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.
|
... |
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 |
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 |
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 |
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 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
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 |
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.
Particularités de ce document
Avertissement
Bien que nous utilisions ici un vocabulaire issu des sciences informatiques, nous ne prétendons nullement à la précision technique de tous nos propos dans ce domaine.
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. |
 |
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.
Tous les logiciels nécessaires sont du domaine public ou LIBRE sous licence GPL; ils ne coûtent pas un sou. 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.
Documentation
Se voulant une base solide pour la création d'un site de Commerce en ligne, le cours SME-101 comprend plusieurs cahiers :
|
- Cahier-00: "SME-101.00 Linux de base". 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, https://wiki.contribs.org/SME-101.01_Logiciels_de_la_station_de_travail 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[2], 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.
- Cahier-10: Supplément: Fail2ban, SME-101.09: SME-101.10: Supplément: Fail2ban.
 |
Cours SME-201
 |
* Cahier-01: Proxmox, SME-201.01: Proxmox-5.2.1. |
 |
* Cahier-02: MediaWiki, SME-201.02 MediaWiki-1.31.1. |
 |
* Cahier-03: Dolibarr (À venir). |
 |
* Cahier-04: OsTicket, SME-201.04: osTicket-1.10.4. |
Michel-André
Victoire totale, hissons la bannière de la victoire.
- ↑ phrase de passe: Groupe de mots et de caractères alphanumériques ou spéciaux, faisant office de mot de passe, connu de l'utilisateur seulement, qui sert à protéger sa clé privée et à l'identifier lors d'une connexion ou d'un transfert de fichier, tout en lui assurant une plus grande sécurité.
Notes: Les phrases de passe ne diffèrent des mots de passe que par la longueur. Les mots de passe sont généralement très courts - de 6 à 10 caractères -, alors que les phrases de passe peuvent comporter jusqu'à 100 caractères (et même plus). Leur longueur et la combinaison des mots et des caractères alphanumériques contribuent à les rendre plus difficiles à deviner que les mots de passe, et donc plus sûres.
Une phrase de passe doit être: connue que de l'utilisateur, suffisamment longue pour être sûre, difficile à deviner, facile à retenir et à saisir sans erreur. Certains considèrent qu'elle devrait atteindre 80 à 100 caractères pour être vraiment efficace.
Référence: http://www.granddictionnaire.com/ficheOqlf.aspx?Id_Fiche=8361195. - ↑ FQDN: Dans le DNS, un Fully Qualified Domain Name (FQDN, ou nom de domaine complètement qualifié) est un nom de domaine qui révèle la position absolue d'un nœud dans l'arborescence DNS en indiquant tous les domaines de niveau supérieur jusqu'à la racine. On parle également de domaine absolu, par opposition aux domaines relatifs. Par convention, le FQDN est ponctué par un point final.
Référence: https://fr.wikipedia.org/wiki/Fully_qualified_domain_name.
