Table des matières



Description générale

Introduction

Le Cahier-04 du cours NethServer-101 décrit la marche à suivre pour installer gratuitement, sur un serveur LOCAL, un certificat Let'sEncrypt.

Un certificat émis par l'autorité de certification Let's Encrypt vous permettra de chiffrer les communications de votre serveur avec une clé TLS/SSL reconnue mondialement.

But final de ce Cahier

Le serveur LOCAL peut être virtuel ou physique et accessible ou non depuis l'Internet.

Serveur virtuel


Serveur physique


Cours NethServer-101

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

  1. Cahier-01: → Les bases de Linux.
  2. Cahier-02: → Installation et configuration des logiciels prérequis sur le poste de travail.
  3. Cahier-03: → Création d'un Serveur NethServer virtuel.
  4. Cahier-04: → Serveur NethServer LOCAL & Let's Encrypt.
  5. Cahier-05: → FAI, modem VDSL, domaine FQDN1) et Serveur NethServer physique.
  6. Cahier-06: → Installation de WordPress.
  7. Cahier-07: → Installation de l'extension de sécurité Wordfence.
  8. Cahier-08: → WooCommerce, comptes chez Stripe et PayPal pour les paiements en ligne.
  9. Cahier-09: → Sauvegarde/restauration ou migration d'un site avec l'extension Duplicator.
  10. Cahier-10: → Serveur mandataire inversé.
  11. Cahier-11: → Sauvegarde/restauration avec BackupPC.

Cours NethServer-201

Le Cours NethServer-201 décrit l'installation et la configuration d'applications sur un serveur NethServer.

  1. Cahier-201-01: → Dolibarr.
  2. Cahier-201-02: → Odoo-12.
  3. Cahier-201-03: → MediaWiki.
  4. Cahier-201-04: → DokuWiki.
  5. Cahier-201-05: → Moodle.
  6. Cahier-201-06: → Proxmox.
  7. Cahier-201-07: → Flectra.

Logiciels

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 au prix initial de $15 CAD et son renouvellement annuel d'environ $30 CAD.

But final

Après avoir suivi le Cours NethServer-101, vous posséderez un site de Commerce en ligne fiable et hautement sécuritaire. De plus, vous pourrez utiliser un clone de votre site, sur un Serveur NethServer virtuel roulant sur votre poste de travail, pour tester de nouvelles extensions et applications sans compromettre la sécurité ou l'intégrité de votre site en ligne.

Particularités de ce document

Notes au lecteur

* Les captures d'écrans ne sont que des références.
** Les informations écrites ont préséance sur celles retrouvées dans les captures d'écrans. Veillez vous référer aux différents tableaux lorsque ceux-ci sont présents.
*** Une capture d'écran avec une accentuation en magenta indique qu'il faut remplacer cette distinction par vos propres paramètres ou implique un choix laissé à votre appréciation.

Conventions

Manipulation, truc ou ruse pour se tirer d'embarras.
Une recommandation ou astuce.
Une note.
Une étape, note ou procédure à surveiller.
Paragraphe non complété ou non vérifié.
Danger pour la sécurité du système.

Toutes les commandes à la console ou à travers PuTTY sont précédées d'une invite qui est toujours présente. 

[root@dorgee ~]# ping 10.10.10.75 -c1

PING 10.10.10.75 (10.10.10.75) 56(84) bytes of data.
64 bytes from 10.10.10.75: icmp_seq=1 ttl=64 time=1.63 ms

--- 10.10.10.75 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.639/1.639/1.639/0.000 ms
[root@dorgee ~]#
Commande à exécuter si ce n'est déjà fait.
Commande indiquée à titre d'information seulement.


Glossaire

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

Cryptographie asymétrique

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

Chiffrement

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

Chiffrement

Référence: https://chiffrer.info/.
Le chiffrement est un procédé de cryptographie grâce auquel on souhaite rendre la compréhension d’un document impossible à toute personne qui n’a pas la clé de (dé)chiffrement. Ce principe est généralement lié au principe d’accès conditionnel.

Chiffrer

L’action de procéder à un chiffrement Déchiffrer

En informatique et en télécommunications, déchiffrer consiste à retrouver le texte original (aussi appelé clair) d’un message chiffré dont on possède la clé de (dé)chiffrement.

Décrypter

Décrypter consiste à retrouver le texte original à partir d’un message chiffré sans posséder la clé de (dé)chiffrement. Décrypter ne peut accepter d’antonyme: il est en effet impossible de créer un message chiffré sans posséder de clé de chiffrement.

Crypter/Cryptage

Le terme “cryptage” et ses dérivés viennent du grec ancien κρυπτός, kruptos, “caché, secret”. Cependant, le Référentiel Général de Sécurité de l’ANSSI qualifie d’incorrect “cryptage”. En effet, la terminologie de cryptage reviendrait à coder un fichier sans en connaître la clé et donc sans pouvoir le décoder ensuite. Le terme n’est par ailleurs pas reconnu par le dictionnaire de l’Académie française.

Échange de clésDiffie-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çue 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.globalsign.fr/fr/centre-information-ssl/differencier-certificat-dv-et-ov/.
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:

  1. www.macompagnie.com
  2. mail.macompagnie.com
  3. macompagnie.com
  4. www.toto.net
  5. mail.toto.net
  6. 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: https://en.wikipedia.org/wiki/CNAME_record.
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.

Si Micronator possède un serveur qui fait partie du domaine principal et dont le nom est coquille, nous pouvons alors insérer un CNAME coquille pour ce serveur. </WRAP> ====== Let's Encrypt ====== ===== Principe de fonctionnement de Letsencrypt ===== Référence: https://linuxfr.org/news/reparlons-de-let-s-encrypt.
Dans ce document, la facilité d'utilisation promise par Let's Encrypt repose principalement sur le script acme.sh et sur l'automatisation qu'il propose. Le script acme.sh 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 script acme.sh: - génère une paire de clés et une demande de signature de certificat (Certificate Signing Request: CSR); - envoie la demande à un serveur ACME;
le serveur de noms Cloudflare 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 script acme.sh installe le certificat proprement dit, la clé 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). 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/SSL, avant d'oublier jusqu'à l'existence même du script acme.sh. ===== 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 acme.sh. ===== 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 Référence: https://letsencrypt.org/docs/rate-limits/.
♦ → Limite de 5 certificats par domaine, dans une fenêtre de 7 jours.
♦ → Limite de 500 enregistrements par IP, toutes les 3 heures. * 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. ===== Mode Officiel vs TEST ===== Si vous voulez tester le script acme.sh (mode Staging)2) et que vous n'êtes pas encore certain de vouloir l'adopter, vous pouvez utiliser le paramètre –test. 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 script acme.sh 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.

===== Conditions préalables ===== Le script acme.sh et le Serveur NethServer 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:

  1. 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 NethServer ou de sa passerelle – lorsqu'ils sont interrogés sur www.exemple.com//, les enregistrements DNS publiés doivent donner l'adresse IP du Serveur NethServer ou de sa passerelle. - Le Serveur NethServer est connecté directement à l'Internet ou si LOCAL, à travers une passerelle. - Les ports 80 et 443 sur le Serveur NethServer sont ouverts vers l'Internet – ils ne sont pas derrière un pare-feu ou un filtrage par le FAI qui bloquerait ces ports. Le script acme.sh é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. ====== Certificat pour un domaine LOCAL ====== ===== Description ===== Référence: https://wiki.nethserver.org/doku.php?id=userguide:let_s_encrypt_for_internal_servers.
    Obtention d'un certificat de confiance Let's Encrypt pour un Serveur NethServer LOCAL accessible ou non depuis l'Internet. ===== Serveur directement branché à l'Internet ===== Pour l'obtention d'un certificat Let's Encrypt pour un serveur branché directement à l'Internet, voir le chapitre Certificat Let's Encrypt dans le Cahier-05:     VDSL, FQDN, Internet et NethServer. ===== Prérequis ===== La prise en charge intégrée des certificats Let’s Encrypt nécessite que votre serveur soit accessible publiquement sur le port 80. ==== Contexte ==== Nethserver 7 inclut la possibilité d’obtenir et de renouveler automatiquement un certificat TLS approuvé auprès de Let’s Encrypt. Cette fonctionnalité est fort utile, mais en raison de la méthode utilisée pour valider votre contrôle sur votre nom de domaine, elle ne convient pas aux serveurs sur un réseau LOCAL qui ne peuvent pas être atteints depuis l'Internet. Heureusement, Let’s Encrypt prend en charge une autre méthode de validation bien adaptée à ce cas particulier. La prise en charge intégrée de Let’s Encrypt repose sur le mécanisme de validation HTTP-01. Pour le bon fonctionnement de ce dernier, les serveurs Let’s Encrypt doivent pouvoir se connecter à http://votre_fqdn/.well-known/acme-challenge/nomdefichierpseudoaleatoire et obtenir le contenu approprié à partir de cette URL. Si votre serveur n’est pas accessible depuis l'Internet par le port 80, cette prise en charge ne fonctionnera pas. Le mécanisme de validation alternatif est le validateur DNS-01. Avec cette méthode, un enregistrement DNS TXT est créé pour _acme-challenge.votre_fqdn, avec une longue chaîne pseudo-aléatoire comme contenu. Cette méthode est pratique uniquement pour une utilisation automatisée si votre hôte DNS fournit une API permettant au logiciel client de mettre à jour automatiquement vos enregistrements DNS. Bien que ce validateur soit supporté par le client officiel Certbot, il est mieux pris en charge par certains clients tiers. ==== La solution ==== Nous allons décrire l'utilisation du script acme.sh (https://github.com/Neilpang/acme.sh) pour l'obtention d'un certificat utilisant la validation DNS, en pré-supposant que votre DNS est hébergé sur Cloudflare (https://www.cloudflare.com/). Le site Cloudflare fournit un hébergement DNS sans frais et dispose d'une API robuste et bien prise en charge qui fonctionne très bien avec la validation DNS. Cependant, acme.sh prend aussi en charge les API d'un certain nombre d'hôtes DNS; la liste, ainsi que les instructions d'utilisation, se trouve dans la documentation du script acme.sh. Toutes les commandes ci-dessous seront exécutées en tant que root à partir du shell sur votre Serveur NethServer. Si votre DNS n’est pas hébergé avec Cloudflare, vous ne pouvez pas suivre ces instructions telles qu’elles sont décrites ici. Vous devez les adapter à votre solution d’hébergement DNS. Si votre fournisseur DNS ne dispose pas d'une API prise en charge, vous pouvez envisager d'utiliser acme-dns (https://wiki.nethserver.org/doku.php?id=userguide:let_s_encrypt_acme-dns). ===== Ouverture d'un compte chez Cloudflare ===== Référence: https://fr.wikipedia.org/wiki/Cloudflare.
    Cloudflare propose un serveur de noms de domaine gratuit (DNS) pour tous les clients qui fonctionnent sur un réseau anycast. Selon W3Cook, le service DNS de Cloudflare alimente actuellement plus de 35 % des domaines DNS gérés. SolveDNS a estimé que Cloudflare proposait l’une des vitesses de recherche DNS les plus rapides au monde, avec une vitesse de recherche signalée à 8,66 millisecondes en avril 2016. Depuis début 2018, Cloudflare a lancé un nouveau service DNS gratuit, rapide et qui se veut respectueux de la vie privée des utilisateurs, aux adresses 1.1.1.1 et 1.0.0.1. Cloudflare fournit des services DNS à 6 millions de sites Web, notamment: Uber, OKCupid et Fitbit. ==== Connexion ==== On se rend à l'URL https://www.cloudflare.com/en-ca/ et on clique Sign Up.

    ==== Configuration ====

    - On entre les informations de­mandées.
    - Create Account.

    - On ajoute le FQDN de notre site.
    - Add site.

    Dans le courriel reçu, on clique Verify email.



    Continue to the dashboard.

    Si notre FQDN n'est pas là, on l'insère → Add a Site.


    Setup.



    Next.

    - On sélectionne le cadre FREE.
    - Confirm Plan.

    Si on accepte les Termes d'utilisation de Cloudflare, on clique Confirm.


    Cloudflare balaie les enregistrements chez notre régistraire, https://www.ionos.fr/, et les insère dans sa propre liste d'enregistrements.



    On insère les enregistrement CNAME que Cloudflare n'a pas copiés: http, https et wpad.


    - On choisit SPF et on entre spf.
    - Dans l'écran surgissant on ajoute: v=spf1 a mx -all
    - Save.
    - Add Record.


    - Avec la souris, on survole l'icône orange pour faire apparaître le message.
    - Ensuite, on clique l'icône avec le nuage.

    Continue.


    Serveurs de noms

    Cloudflare nous indique de remplacer les serveurs de noms chez notre régistraire par ceux qu'il utilise lui-même:

    De:
    ns1052.ui-dns.de
    ns1085.ui-dns.com

    À:
    - elinore.ns.cloudflare.com
    - joel.ns.cloudflare.com

    Il nous indique aussi de supprimer, chez notre régistraire, les serveurs de noms suivant:
    - ns1064.ui-dns.biz
    - ns1036.ui-dns.org


    ==== Remplacement des serveurs de noms chez le régistraire de notre domaine ==== Le régistraire pour notre domaine     micronator-dev.org est ionos.fr. Le site ionos.ca offre un nom de domaine pour $10CDN la première année et $15CDN / année par la suite.

    - On se rend chez notre régistraire: ionos.fr.
    - Connexion.
    - On entre les informations demandées.
    - Connexion.


    - On déroule l'icône de menus.
    - Serveur de noms.
    Utiliser des serveurs de noms personnalisés.


    Dans l'écran surgissant, on entre les deux serveurs de noms utilisés par Cloudflare:

    elinore.ns.cloudflare.com
    joel.ns.cloudflare.com

    Enregistrer.

    Ce remplacement des serveurs de noms supprimera tous ceux utilisés par ionos.fr pour notre domaine micronator-dev.org.

    L'opération a réussie.
    ===== Retour chez Cloudflare =====

    Continue.

    Tout s'est bien déroulé.


    Overview.
    ===== Clé API ===== Il nous faut maintenant récupérer notre     clé API Globale.


    - Chez Cloudflare, on déroule le menu de l'usager.
    - My Profile.



    - Au bas de la page, vis-à-vis Global API key, on clique View,

    - On entre notre mot de passe et on clique I'm not a robot.
    - On sélectionne les images du Captcha.
    - Au retour du Captcha, on clique View.


    Notre clé API Globale apparaît.

    Cette clé est à garder précieusement et ne la divulguer à personne.

    On copie et on sauvegarde cette clé pour la prochaine étape.


    ===== Installation du script acme.sh ===== La commande ci-dessous téléchargera les fichiers accompagnant acme.sh, les stockera dans le répertoire ~/.acme.sh et mettra à jour votre variable d’environnement PATH pour inclure ce chemin. <file> [root@tchana ~]# curl https://get.acme.sh | sh % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 705 100 705 0 0 778 0 –:–:– –:–:– –:–:– 778 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 174k 100 174k 0 0 468k 0 –:–:– –:–:– –:–:– 468k [mer. mars 13 15:34:08 EDT 2019] Installing from online archive. [mer. mars 13 15:34:08 EDT 2019] Downloading https://github.com/Neilpang/acme.sh/archive/master.tar.gz [mer. mars 13 15:34:09 EDT 2019] Extracting master.tar.gz [mer. mars 13 15:34:09 EDT 2019] It is recommended to install socat first. [mer. mars 13 15:34:09 EDT 2019] We use socat for standalone server if you use standalone mode. [mer. mars 13 15:34:09 EDT 2019] If you don't use standalone mode, just ignore this warning. [mer. mars 13 15:34:09 EDT 2019] Installing to /root/.acme.sh [mer. mars 13 15:34:09 EDT 2019] Installed to /root/.acme.sh/acme.sh [mer. mars 13 15:34:09 EDT 2019] Installing alias to '/root/.bashrc' [mer. mars 13 15:34:09 EDT 2019] OK, Close and reopen your terminal to start using acme.sh [mer. mars 13 15:34:09 EDT 2019] Installing alias to '/root/.cshrc' [mer. mars 13 15:34:09 EDT 2019] Installing alias to '/root/.tcshrc' [mer. mars 13 15:34:09 EDT 2019] Installing cron job 56 0 * * * “/root/.acme.sh”/acme.sh –cron –home “/root/.acme.sh” > /dev/null [mer. mars 13 15:34:09 EDT 2019] Good, bash is found, so change the shebang to use bash as preferred. [mer. mars 13 15:34:10 EDT 2019] OK [mer. mars 13 15:34:10 EDT 2019] Install success! [root@tchana ~]# </file> Déconnectez-vous et reconnectez-vous pour activer le nouveau chemin. On vérifie le chemin du script acme.sh. <file> root@tchana ~]# which acme.sh alias acme.sh='/root/.acme.sh/acme.sh' /root/.acme.sh/acme.sh [root@tchana ~]# </file> ==== Configuration ==== === Chemin des fichiers du certificat === On doit définir certaines entrées de la base de données de configuration: Chemin de la     clé publique du certificat. <file> [root@tchana ~]# config setprop pki CrtFile /etc/pki/tls/certs/cert.pem [root@tchana ~]# </file> Chemin de la chaîne de certification. <file> [root@tchana ~]# config setprop pki ChainFile /etc/pki/tls/certs/chain.pem [root@tchana ~]# </file> Chemin de la clé privée du certificat. <file> [root@tchana ~]# config setprop pki KeyFile /etc/pki/tls/private/privkey.pem [root@tchana ~]# </file> === Variables d'environnement === On doit définir certaines variables d’environnement correspondant à nos informations d’identification et à notre validateur DNS c.-à-d. Cloudflare. C’est ici que vous devrez effectuer des ajustements nécessaires si vous utilisez un autre serveur de noms que Cloudflare - pour plus de détails, voir le lien de la documentation acme.sh: https://github.com/Neilpang/acme.sh/blob/master/dnsapi/README.md. L'exemple ci-dessous est celle d'une installation utilisant le serveur de noms Cloudflare. On exporte dans l'environnement présentement en mémoire sur notre Serveur NethServer, notre clé API Globale de Cloudflare. <file> [root@tchana ~]# export CF_Key=“VotreCléGlobaleDeCloudflare” [root@tchana ~]# </file> On exporte notre adresse courriel utilisé pour notre enregistrement chez Cloudflare. <file> [root@tchana ~]# export CF_Email=“VotreAdresseCourrielDEnregistrementChezCloudflare” [root@tchana ~]# </file> On vérifie les exportations. <file> [root@tchana ~]# env | grep -i CF_ CF_Email= VotreAdresseCourrielDEnregistrementChezCloudflare CF_Key= VotreCléGlobaleDeCloudflare [root@tchana ~]# </file> Si vous réamorcez le Serveur NethServer avant la demande d'un certificat, vous perdez ces exportations. Il vous faudra alors les refaire. === Vérification de la configuration PKI === <file> [root@tchana ~]# config show pki pki=configuration CertificateDuration=3650 ChainFile=/etc/pki/tls/certs/chain.pem CommonName=Micronator CountryCode=CA CrtFile=/etc/pki/tls/certs/cert.pem EmailAddress=VotreAdresseCourriel KeyFile=/etc/pki/tls/private/privkey.pem LetsEncrypt=disabled LetsEncryptDomains= LetsEncryptMail= LetsEncryptRenewDays=30 Locality=Montreal Organization=RF-232 OrganizationalUnitName=Service informatique State=Qc SubjectAltName=*.micronator-dev.org [root@tchana ~]# </file>
    ===== Demande d'un certificat ===== On lance une demande d'un certificat de TEST pour notre domaine     micronator-dev.org et trois de ses CNAME. <file> [root@tchana ~]# /root/.acme.sh/acme.sh \ –issue \ –dns dns_cf \ -d micronator-dev.org \ -d www.micronator-dev.org \ -d mail.micronator-dev.org \ -d wpad.micronator-dev.org \ –cert-file /etc/pki/tls/certs/cert.pem \ –ca-file /etc/pki/tls/certs/chain.pem \ –key-file /etc/pki/tls/private/privkey.pem \ –reloadcmd “/sbin/e-smith/signal-event certificate-update” \ –test … [mer. mars 13 17:22:51 EDT 2019] Multi domain='DNS:micronator-dev.org,DNS:www.micronator-dev.org,DNS:mail.micronator-dev.org,DNS:wpad.micronator-dev.org' [mer. mars 13 17:22:51 EDT 2019] Getting domain auth token for each domain … [mer. mars 13 17:22:53 EDT 2019] Found domain api file: /root/.acme.sh/dnsapi/dns_cf.sh [mer. mars 13 17:22:54 EDT 2019] Adding record [mer. mars 13 17:22:54 EDT 2019] Added, OK … [mer. mars 13 17:22:59 EDT 2019] Let's check each dns records now. Sleep 20 seconds first. [mer. mars 13 17:23:20 EDT 2019] Checking micronator-dev.org for _acme-challenge.micronator-dev.org [mer. mars 13 17:23:20 EDT 2019] Domain micronator-dev.org '_acme-challenge.micronator-dev.org' success. … [mer. mars 13 17:23:21 EDT 2019] All success, let's return [mer. mars 13 17:23:21 EDT 2019] Verifying: micronator-dev.org [mer. mars 13 17:23:24 EDT 2019] Success … [mer. mars 13 17:23:33 EDT 2019] Removing DNS records. [mer. mars 13 17:23:39 EDT 2019] Verify finished, start to sign. [mer. mars 13 17:23:39 EDT 2019] Lets finalize the order, Le_OrderFinalize: https://acme-staging-v02.api.letsencrypt.org/acme/finalize/8557612/26616770 [mer. mars 13 17:23:41 EDT 2019] Download cert, Le_LinkCert: https://acme-staging-v02.api.letsencrypt.org/acme/cert/fabf9295808e46dc2ec3ab8135d815ba066d [mer. mars 13 17:23:42 EDT 2019] Cert success. —–BEGIN CERTIFICATE—– … —–END CERTIFICATE—– [mer. mars 13 17:23:42 EDT 2019] Your cert is in /root/.acme.sh/micronator-dev.org/micronator-dev.org.cer [mer. mars 13 17:23:42 EDT 2019] Your cert key is in /root/.acme.sh/micronator-dev.org/micronator-dev.org.key [mer. mars 13 17:23:42 EDT 2019] The intermediate CA cert is in /root/.acme.sh/micronator-dev.org/ca.cer [mer. mars 13 17:23:42 EDT 2019] And the full chain certs is there: /root/.acme.sh/micronator-dev.org/fullchain.cer [mer. mars 13 17:23:42 EDT 2019] Installing cert to:/etc/pki/tls/certs/cert.pem [mer. mars 13 17:23:42 EDT 2019] Installing CA to:/etc/pki/tls/certs/chain.pem [mer. mars 13 17:23:42 EDT 2019] Installing key to:/etc/pki/tls/private/privkey.pem [mer. mars 13 17:23:42 EDT 2019] Run reload cmd: /sbin/e-smith/signal-event certificate-update [mer. mars 13 17:23:45 EDT 2019] Reload success [root@tchana ~]# </file> La demande d'un certificat de TEST a réussi, on peut faire une demande de certificat de Production. Si nous rencontrons des difficultés, on peut ajouter le paramètre –debug qui nous donnera plus d'informations. On lance une demande d'un certificat TLS de Production. Il faut ajouter le paramètre –force pour obliger un renouvellement, car le certificat actuel, même si c'en est un de TEST, est toujours valide pour plus de 30 jours. <file> [root@tchana ~]# /root/.acme.sh/acme.sh \ –issue \ –dns dns_cf \ -d micronator-dev.org \ -d www.micronator-dev.org \ -d mail.micronator-dev.org \ -d wpad.micronator-dev.org \ –cert-file /etc/pki/tls/certs/cert.pem \ –ca-file /etc/pki/tls/certs/chain.pem \ –key-file /etc/pki/tls/private/privkey.pem \ –reloadcmd “/sbin/e-smith/signal-event certificate-update” \ –force [mer. mars 13 18:25:33 EDT 2019] Multi domain='DNS:micronator-dev.org,DNS:www.micronator-dev.org,DNS:mail.micronator-dev.org,DNS:wpad.micronator-dev.org' [mer. mars 13 18:25:33 EDT 2019] Getting domain auth token for each domain … [mer. mars 13 18:25:36 EDT 2019] Adding record [mer. mars 13 18:25:37 EDT 2019] Added, OK … [mer. mars 13 18:25:39 EDT 2019] Let's check each dns records now. Sleep 20 seconds first. [mer. mars 13 18:26:01 EDT 2019] Checking micronator-dev.org for _acme-challenge.micronator-dev.org [mer. mars 13 18:26:01 EDT 2019] Domain micronator-dev.org '_acme-challenge.micronator-dev.org' success. … [mer. mars 13 18:26:01 EDT 2019] All success, let's return [mer. mars 13 18:26:01 EDT 2019] Verifying: micronator-dev.org [mer. mars 13 18:26:04 EDT 2019] Success … [mer. mars 13 18:26:10 EDT 2019] Removing DNS records. [mer. mars 13 18:26:14 EDT 2019] Verify finished, start to sign. [mer. mars 13 18:26:14 EDT 2019] Lets finalize the order, Le_OrderFinalize: https://acme-v02.api.letsencrypt.org/acme/finalize/53245520/354067975 [mer. mars 13 18:26:15 EDT 2019] Download cert, Le_LinkCert: https://acme-v02.api.letsencrypt.org/acme/cert/044dfeb233cae8467009adb8043142f44d45 [mer. mars 13 18:26:16 EDT 2019] Cert success. —–BEGIN CERTIFICATE—– … —–END CERTIFICATE—– [mer. mars 13 18:26:16 EDT 2019] Your cert is in /root/.acme.sh/micronator-dev.org/micronator-dev.org.cer [mer. mars 13 18:26:16 EDT 2019] Your cert key is in /root/.acme.sh/micronator-dev.org/micronator-dev.org.key [mer. mars 13 18:26:16 EDT 2019] The intermediate CA cert is in /root/.acme.sh/micronator-dev.org/ca.cer [mer. mars 13 18:26:16 EDT 2019] And the full chain certs is there: /root/.acme.sh/micronator-dev.org/fullchain.cer [mer. mars 13 18:26:16 EDT 2019] Installing cert to:/etc/pki/tls/certs/cert.pem [mer. mars 13 18:26:16 EDT 2019] Installing CA to:/etc/pki/tls/certs/chain.pem [mer. mars 13 18:26:16 EDT 2019] Installing key to:/etc/pki/tls/private/privkey.pem [mer. mars 13 18:26:16 EDT 2019] Run reload cmd: /sbin/e-smith/signal-event certificate-update [mer. mars 13 18:26:18 EDT 2019] Reload success [root@tchana ~]# </file> Victoire, nous avons un certificat TLS de Production.

    ===== Vérification ===== À la console du serveur     Certificat publique <file> [root@tchana ~]# ls -als /etc/pki/tls/certs/cert.pem 4 -rw-r–r– 1 root root 2021 13 mars 18:26 /etc/pki/tls/certs/cert.pem [root@tchana ~]# </file> Chaîne de certification <file> [root@tchana ~]# ls -als /etc/pki/tls/certs/chain.pem 4 -rw-r–r– 1 root root 1648 13 mars 18:26 /etc/pki/tls/certs/chain.pem [root@tchana ~]# </file> Clé privée <file> [root@tchana ~]# ls -als /etc/pki/tls/private/privkey.pem 4 -rw——- 1 root root 1675 13 mars 18:26 /etc/pki/tls/private/privkey.pem [root@tchana ~]# </file> Avec un navigateur On se rend à https://www.micronator-dev.org. Il n'est pas nécessaire d'ajouter une exception pour le certificat, car il a été émis par une autorité de certification reconnue. Le cadenas est vert.

    On clique le cadenas pour afficher les informations de la connexion, puis on clique l'icône “>”.




    Plus d'informations.



    Onglet Sécurité → Afficher le certificat.

    - Le certificat a été émis par Let's Encrypt Authority X3.
    - On clique l'onglet Détails.


    - On clique Nom alternatif du sujet du certificat.

    - Les CNAME sont présents.


    ===== Renouvellement ===== À chaque jour, une     tâche cron vérifie le nombre de jours restant pour la validité. <file> [root@tchana ~]# crontab -l 56 0 * * * “/root/.acme.sh”/acme.sh –cron–home “/root/.acme.sh” > /dev/null [root@tchana ~]# </file> Le renouvellement se fera automatiquement lorsqu'il ne restera que 30 jours de validité. On peut forcer le renouvellement en mode TEST. <file> [root@tchana ~]# acme.sh –renew \ -d micronator-dev.org \ -d www.micronator-dev.org \ -d mail.micronator-dev.org \ -d wpad.micronator-dev.org \ –force –test [root@tchana ~]# </file> On peut aussi forcer le renouvellement en mode Production. <file> [root@tchana ~]# acme.sh –renew \ -d micronator-dev.org \ -d www.micronator-dev.org \ -d mail.micronator-dev.org \ -d wpad.micronator-dev.org \ –force [root@tchana ~]# </file>

    Le certificat Let's Encrypt fonctionne correctement pour un Serveur NethServer LOCAL.


    ===== Répertoire well-known =====     Référence: https://dev-notes.eu/2017/01/apache-directives-in-config-vs-htaccess/
    Référence: http://httpd.apache.org/docs/current/howto/htaccess.html#page-header. Pour un serveur branché directement à l'Internet, lors d'une demande d'un certificat à Let's Encrypt, ce dernier doit pouvoir accéder au répertoire .well-known et à son sous-répertoire acme-challenge. On peut faire la demande de certificat à la page de l'interface Web: Configuration → Certificat du serveur → on déroule le menu et on choisit Requête de certificat Let's Encrypt. Pour plus de détails, voir le Cahier-05: VDSL, FQDN, Internet et NethServer. Pour ce genre de serveur (branché directement à l'Internet), nous devons créer un fichier /etc/httpd/conf.d/z_well-known.conf pour indiquer à Apache de rendre accessibles le répertoire .well-known et son sous-répertoire acme-challenge. ==== Création du fichier z_well-known.conf ==== Prendre tout le contenu de l'encadré pour la commande. <file> cat > /etc/httpd/conf.d/z_well-known.conf «'EOT' Alias “/.well-known/acme-challenge/” “/var/www/html/.well-known/acme-challenge/” <Directory “/var/www/html/.well-known/acme-challenge/”> Require all granted Options -Indexes +FollowSymLinks AllowOverride All </Directory> EOT </file> On vérifie. <file> [root@tchana ~]# ls -als /etc/httpd/conf.d/z_well-known.conf 4 -rw-r–r– 1 root root 231 10 juin 11:03 /etc/httpd/conf.d/z_well-known.conf [root@tchana ~]# </file> On affiche le contenu du fichier. <file> [root@tchana ~]# cat /etc/httpd/conf.d/z_well-known.conf Alias “/.well-known/acme-challenge/” “/var/www/html/.well-known/acme-challenge/” <Directory “/var/www/html/.well-known/acme-challenge/”> Require all granted Options -Indexes +FollowSymLinks AllowOverride All </Directory> [root@tchana ~]# </file> Il n'y a pas de ligne vide au dessus de Alias… Ci-dessus, Nous en avons inséré une afin de faciliter la copie de la commande. === Sauvegarde du fichier === On vérifie si le nom du fichier /etc/httpd/conf/z_well-known.conf est déjà inclus dans le fichier d'inclusion de la sauvegarde des données: /etc/backup-data.d/custom.include, sinon on l'insère. Prendre tout le contenu de l'encadré pour la commande. <file> NouvelleInclusion=“/etc/httpd/conf/z_well-known.conf” if grep -Fxq “$NouvelleInclusion” /etc/backup-data.d/custom.include then # L'entrée a été trouvée dans custom.include echo -e “\nLe fichier custom.include contient déjà l'entrée:\n$NouvelleInclusion \n” else # L'entrée n'a pas été trouvée dans custom.include echo -e “$NouvelleInclusion” » /etc/backup-data.d/custom.include echo -e “\nL'entrée: $NouvelleInclusion a été ajoutée\n” fi </file> On vérifie. <file> [root@tchana ~]# cat /etc/backup-data.d/custom.include | grep z_well-known.conf /etc/httpd/conf/z_well-known.conf [root@tchana ~]# </file> Ci-dessus, il n'y a pas de ligne vide avant /etc/httpd/conf/z_well-known.conf. Nous en avons inséré une afin de faciliter la copie de la commande. === Redémarrage du démon httpd === On redémarre le démon Apache afin qu'il relise ses fichiers de configuration. <file> [root@tchana ~]# systemctl restart httpd [root@tchana ~]# </file>

    Victoire totale, hissons la bannière de la victoire.
    —- ====== Crédits ====== © 2016-2017-2018-2019 RF-232.
    Auteur: Michel-André CLP.
    Remerciement: Tous les contributeurs GNU/GPL.
    Intégré par: Michel-André Robillard CLP.
    Contact: michelandre at micronator.org Répertoire de ce document: E:\000_DocPourRF232_general\RF-232_NethServer\RF-232_Cours_NethServer-101_Cahier-04_NethServer_LOCAL_LetsEncrypt_2019-08-05_10h40.odt. ===== Historique des modifications ===== ^Version^Date^Commentaire^Auteur| |0.0.1|2016-01-26|Début.|Michel-André| |0.0.2|2016-03-21|Ajustement de la tâche cron, pour qu’elle roule quotidiennement à 02h15, à cause de la possibilité d’un “effet de bord” du programme calculant le nombre de jours restants pour la validité du certificat.|Michel-André| |0.0.3|2016-04-03|Corrections orthographiques.|Michel-André| |0.1.0|2016-04-03| - Mise à jour à cause du changement du nom du fichier de configuration de config.sh à config.
    - La majorité des dates, heures et certificats sont ceux de la version 0.0.1 de ce document.|Michel-André| |0.1.1|2016-07-18| Correction pour le fichier /etc/e-smith/templates-custom/etc/dar/DailyBackup.dcf/41go-into.|Michel-André| |0.2.0|2016-09-14| Ajustement pour le changement de nom du client letsencrypt.sh pour dehydrated.|Michel-André| |1.0.0|2017-01-30| Mise à jour pour le cours Micronator-101.|Michel-André| |1.1.0|2018-03-24|Mise à jour de certaines figures et correction de quelques coquilles.|Michel-André| |2.0.0|2018-10-02|Mise à jour en utilisant la Contrib Let's Encrypt.|Michel-André| |2.0.1|2018-11-07|Corrections mineures.|Michel-André| |3.0.0|2019-03-09|Adaptation pour NethServer-7.6.1810.|Michel-André| |3.0.1|2019-05-06|Corrections mineures.|Michel-André| |3.0.2|2019-06-16|- Corrections mineures.
    - Ajout d'une section pour le répertoire .well-known d'un serveur bran­ché directement à l'Internet.|Michel-André| |3.1.0|2019-08-04|Corrections mineures pour DokuWiki.|Michel-André| |12345678901| | |12345678901| <html><hr style=“width:50%; margin: 0 auto;”></html> ===== AVIS DE NON-RESPONSABILITÉ ===== Ce document est uniquement destiné à informer. Les informations, ainsi que les contenus et fonctionnalités de ce do­cument sont fournis sans engagement et peuvent être modifiés à tout moment. RF‑232 n'offre aucune garantie quant à l'actualité, la conformité, l'exhaustivité, la qualité et la durabilité des informations, contenus et fonctionnalités de ce document. L'accès et l'utilisation de ce document se font sous la seule responsabilité du lecteur ou de l'utilisateur. RF‑232 ne peut être tenu pour responsable de dommages de quelque nature que ce soit, y compris des dommages di­rects ou indirects, ainsi que des dommages consécutifs résultant de l'accès ou de l'utilisation de ce document ou de son contenu. Chaque internaute doit prendre toutes les mesures appropriées     (mettre à jour régulièrement son logiciel antivirus, ne pas ouvrir des documents suspects de source douteuse ou non connue) de façon à protéger le contenu de son ordina­teur de la contamination d'éventuels virus circulant sur la Toile. Toute reproduction interdite Vous reconnaissez et acceptez que tout le contenu de ce document, incluant mais sans s’y limiter, le texte et les images, sont protégés par le droit d’auteur, les marques de commerce, les marques de service, les brevets, les secrets industriels et les autres droits de propriété intellectuelle. Sauf autorisation expresse de RF-232, vous acceptez de ne pas vendre, délivrer une licence, louer, modifier, distribuer, copier, reproduire, transmettre, afficher publiquement, exécuter en public, publier, adapter, éditer ou créer d’oeuvres dérivées de ce document et de son contenu. ==== Avertissement==== Bien que nous utilisions ici un vocabulaire issu des techniques informatiques, nous ne prétendons nullement à la précision technique de tous nos propos dans ce domaine.

1)
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.

2)
Staging:Un site Staging, dans la conception de sites Web, est un site utilisé pour assembler, tester et revoir une version plus récente avant de l'implanter en Production.
Référence: https://en.wikipedia.org/wiki/Staging_site.