DokuWiki de Micronator

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
\\ 
[[cours_nethserver_101|{{ Images_Cahier-101-04-000.png?650 }}]]
\\ 
====== 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 =====

{{Images_Cahier-101-03-005.png?25}} Le serveur LOCAL peut être virtuel ou physique et accessible ou non depuis l'Internet.

==== Serveur virtuel ====

{{ Images_Cahier-101-04-001.png?550 }}
\\ 

=== Serveur physique ===

{{ Images_Cahier-101-04-002.png?550 }}
\\ 

===== 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:

  - [[nethserver_101_cahier_01_linux|Cahier-01]]: -> Les bases de Linux.
  - [[nethserver_101_cahier_02_installations_configurations_logiciels_prerequis|Cahier-02]]: -> Installation et configuration des logiciels prérequis sur le poste de travail.
  - [[nethserver_101_cahier_03_creation_un_serveur_virtuel|Cahier-03]]: -> Création d'un Serveur NethServer virtuel.
  - [[nethserver_101_cahier_04_local_certificat_let_encrypt|Cahier-04]]: -> Serveur NethServer LOCAL & Let's Encrypt.
  - [[nethserver_101_cahier_05_vdsl_fqdn_internet_et_nethserver|Cahier-05]]: -> FAI, modem VDSL, domaine FQDN(( **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|https://fr.wikipedia.org/wiki/Fully_qualified_domain_name]]. \\ \\ )) et Serveur NethServer physique.
  - [[nethserver_101_cahier_06_nethserver_wordPress|Cahier-06]]: -> Installation de WordPress.
  - [[nethserver_101_cahier_07_nethserver_wordPress_wordfence|Cahier-07]]: -> Installation de l'extension de sécurité Wordfence.
  - [[nethserver_101_cahier_08_woocommerce_paypal_stripe|Cahier-08]]: -> WooCommerce, comptes chez Stripe et   PayPal pour les paiements en ligne.
  - [[nethserver_101_cahier_09_duplicator_migration|Cahier-09]]: -> Sauvegarde/restauration ou migration d'un site avec l'extension Duplicator.
  - [[nethserver_101_cahier_10_mandataire_inverse|Cahier-10]]: -> Serveur mandataire inversé.
  - [[nethserver_101_cahier_11_nethserver_backuppc|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.

  - [[nethserver_201_cahier_01_nethserver_et_dolibarr|Cahier-201-01]]: -> Dolibarr.
  - [[nethserver_201_cahier_02_odoo_12|Cahier-201-02]]: -> Odoo-12.
  - [[nethserver_201_cahier_03_mediawiki|Cahier-201-03]]: -> MediaWiki.
  - [[nethserver_201_cahier_04_dokuwiki|Cahier-201-04]]: -> DokuWiki.
  - [[nethserver_201_cahier_05_moodle|Cahier-201-05]]: -> Moodle.
  - [[nethserver_201_cahier_06_proxmox|Cahier-201-06]]: -> Proxmox.
  - [[nethserver_201_cahier_07_flectra|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.

{{ NS-101_001_Diagramme.png?500 }}

===== Particularités de ce document =====

==== Notes au lecteur ====

<nowiki>*</nowiki> Les captures d'écrans ne sont que des références.\\
<nowiki>**</nowiki> 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.\\ 
<nowiki>***</nowiki> 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 ====

{{Images_icone-201-001_doigt.png?22}} Manipulation, truc ou ruse pour se tirer d'embarras.\\
{{Images_icone-201-002_Lumiere.png?25}} Une recommandation ou astuce.\\
{{Images_icone-201-003_Note.png?25}} Une note.\\
{{Images_icone-201-004_Triangle.png?25}} Une étape, note ou procédure à surveiller.\\
{{Images_icone-201-005_Non-termine.png?25}} Paragraphe non complété ou non vérifié.\\
{{Images_icone-201-006_Securite.png?25}} 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.

<file>
[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 ~]#
</file>

<WRAP box round>
<file>
Commande à exécuter si ce n'est déjà fait.
</file>
</WRAP>

<WRAP box>
<file>
Commande indiquée à titre d'information seulement.
</file>
</WRAP>
\\ 

====== 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étrique|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**

<WRAP indent>
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/|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.
</WRAP>

**Échange de clésDiffie-Hellman**

//Référence:// [[https://fr.wikipedia.org/wiki/Échange_de_clés_Diffie-Hellman|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ôle|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|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 "[[https://fr.wikipedia.org/wiki/Attaque_par_rejeu|Attaque par rejeu]]".

**Condensat**

//Référence:// [[http://gdt.oqlf.gouv.qc.ca/ficheOqlf.aspx?Id_Fiche=8371028|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|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|https://fr.wikipedia.org/wiki/Attaque_de_l'homme_du_milieu]].\\ 
{{ Images_Cahier-101-04-004.png?500}}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**

<WRAP indent>
//Référence:// [[https://fr.wikipedia.org/wiki/Certificat_électronique|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|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.
</WRAP>

**Certificats à Validation de Domaine //(DV)//**

<WRAP indent>
//Référence//: [[https://www.globalsign.fr/fr/centre-information-ssl/differencier-certificat-dv-et-ov/|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.
</WRAP>

**SAN et Wildcard**

<WRAP indent>
//Référence:// [[https://www.thawte.fr/ssl/san-uc-ssl-certificates/#|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.
</WRAP>

**CNAME**

<WRAP indent>
//Référence:// [[https://en.wikipedia.org/wiki/CNAME_record|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**//

<WRAP column 55%>
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.
</WRAP>
<WRAP column 35%>
|{{ Images_Cahier-101-04-005.png?400 }}|
</WRAP>
<WRAP clear></WRAP>

{{Images_Cahier-101-03-004.png?25}} 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|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/|https://letsencrypt.org/docs/rate-limits/]].\\
<nowiki>♦</nowiki> -> Limite de **5** certificats par domaine, dans une fenêtre de **7** jours.\\
<nowiki>♦</nowiki> -> Limite de **500** enregistrements par IP, toutes les **3** heures.


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

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

===== Mode Officiel vs TEST =====

Si vous voulez tester le script ''acme.sh'' //(mode Staging)//(( **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|https://en.wikipedia.org/wiki/Staging_site]]. 
 ))  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) ====

<WRAP indent>
== 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//.

{{Images_Cahier-101-03-003.png?22}} Il est fortement recommandé de débuter en demandant un certificat de test.
</WRAP>

===== 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:

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

{{Images_Cahier-101-03-006.png?25}} 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|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 [[nethserver_101_cahier_05_vdsl_fqdn_internet_et_nethserver|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 <wrap em>port 80</wrap>.

==== 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 //<nowiki>_acme-challenge.votre_fqdn</nowiki>//, 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|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/|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 [[https://github.com/Neilpang/acme.sh/wiki/dnsapi|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.

{{Images_Cahier-101-03-006.png?25}} 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|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|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.

{{ Images_Cahier-101-04-006.png?350}}
==== Connexion ====

On se rend à l'URL [[https://www.cloudflare.com/en-ca/|https://www.cloudflare.com/en-ca/]] et on clique **Sign Up**.
<WRAP clear></WRAP>

==== Configuration ====

<WRAP column 30%>
<nowiki>-</nowiki> On entre les informations demandées.\\ 
<nowiki>-</nowiki> **Create Account**.
|{{ Images_Cahier-101-04-007.png?400 }}|
</WRAP>
<WRAP column 30%>
<nowiki>-</nowiki> On ajoute le **FQDN** de notre site.\\ 
<nowiki>-</nowiki> **Add site**.
|{{ Images_Cahier-101-04-008.png?400 }}|
</WRAP>
<WRAP column 30%>
Dans le courriel reçu, on clique **Verify email**.
|{{ Images_Cahier-101-04-009.png?400 }}|
</WRAP>
<WRAP clear></WRAP>
\\

<WRAP column 30%>
\\ 
Continue to the dashboard.
|{{ Images_Cahier-101-04-010.png?400 }}|
</WRAP>
<WRAP column 30%>
Si notre FQDN n'est pas là, on l'insère  **->  Add a Site**.
|{{ Images_Cahier-101-04-011.png?400 }}|
</WRAP>
<WRAP column 30%>
\\ 
**Setup**.
|{{ Images_Cahier-101-04-012.png?400 }}|
</WRAP>
<WRAP clear></WRAP>
\\

<WRAP column 30%>
\\ 
**Next**.
|{{ Images_Cahier-101-04-013.png?400 }}|
</WRAP>
<WRAP column 30%>
<nowiki>-</nowiki> On sélectionne le cadre FREE.\\
<nowiki>-</nowiki> **Confirm Plan**.
|{{ Images_Cahier-101-04-014.png?400 }}|
</WRAP>
<WRAP column 30%>
__Si on accepte__ les //Termes d'utilisation de Cloudflare//, on clique **Confirm**.
|{{ Images_Cahier-101-04-015.png?400 }}|
</WRAP>
<WRAP clear></WRAP>
\\

<WRAP column 30%>
//Cloudflare// balaie les enregistrements chez notre régistraire, [[https://www.ionos.fr/|https://www.ionos.fr/]], et les insère dans sa propre liste d'enregistrements.
|{{ Images_Cahier-101-04-016.png?400 }}|
</WRAP>
<WRAP column 60%>
\\ 
\\ 
On insère les enregistrement CNAME que //Cloudflare// n'a pas copiés: **http**, **https** et **wpad**.
|{{ Images_Cahier-101-04-018.png?600 }}|

|{{ Images_Cahier-101-04-019.png?600 }}|

|{{ Images_Cahier-101-04-020.png?600 }}|
</WRAP>
<WRAP clear></WRAP>
\\ 

<WRAP center>
<WRAP column 45%>
<nowiki>-</nowiki> On choisit **SPF** et on entre **spf**.\\ 
<nowiki>-</nowiki> Dans l'écran surgissant on ajoute: **v=spf1 a mx -all**\\ 
<nowiki>-</nowiki> **Save**.\\ 
<nowiki>-</nowiki> **Add Record**.
|{{ Images_Cahier-101-04-022.png?400 }}|

|{{ Images_Cahier-101-04-023.png?400 }}|

|{{ Images_Cahier-101-04-026.png?400 }}|
</WRAP>
<WRAP column 45%>
\\ 
<nowiki>-</nowiki> Avec la souris, on survole l'//**icône orange**// pour faire apparaître le message.\\ 
<nowiki>-</nowiki> Ensuite, on clique l'**icône avec le nuage**.
|{{ Images_Cahier-101-04-024.png?400 }}|

**Continue**.
|{{ Images_Cahier-101-04-025-A.png?400 }}|
</WRAP>
</WRAP>
<WRAP clear></WRAP>
\\

<WRAP column 45%>
===== 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**

//À://\\ 
<nowiki>-</nowiki> **elinore.ns.cloudflare.com**\\
<nowiki>-</nowiki> **joel.ns.cloudflare.com**

Il nous indique aussi de supprimer, chez notre régistraire, les serveurs de noms suivant:\\
<nowiki>-</nowiki> //**ns1064.ui-dns.biz**//\\
<nowiki>-</nowiki> //**ns1036.ui-dns.org**//
</WRAP>
<WRAP column 45%>
|{{ Images_Cahier-101-04-027.png?400 }}|
</WRAP>
<WRAP clear></WRAP>
\\

==== Remplacement des serveurs de noms chez le régistraire de notre domaine ====

Le régistraire pour notre domaine //micronator-dev.org// est [[http://ionos.fr/|ionos.fr]].

{{Images_Cahier-101-03-005.png?25}} Le site [[http://ionos.ca/|ionos.ca]] offre un nom de domaine pour $10CDN la première année et $15CDN / année par la suite.

<WRAP center>
<WRAP column 45%>
<nowiki>-</nowiki> On se rend chez notre régistraire: //**ionos.fr**//.\\ 
<nowiki>-</nowiki> **Connexion**.\\ 
<nowiki>-</nowiki> On entre les informations demandées.\\ 
<nowiki>-</nowiki> **Connexion**.\\ 
|{{ Images_Cahier-101-04-028.png?400 }}|

|{{ Images_Cahier-101-04-029.png?400 }}|
</WRAP>
<WRAP column 45%>
\\ 
<nowiki>-</nowiki> On déroule l'icône de menus.\\ 
<nowiki>-</nowiki> **Serveur de noms**.\\ 
**Utiliser des serveurs de noms personnalisés**.
|{{ Images_Cahier-101-04-030.png?400 }}|

|{{ Images_Cahier-101-04-031.png?400 }}|
</WRAP>
</WRAP>
<WRAP clear></WRAP>
\\

<WRAP column 45%>
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//.
</WRAP>
<WRAP column 45%>
|{{ Images_Cahier-101-04-032.png?400 }}|
</WRAP>
<WRAP clear></WRAP>

L'opération a réussie.

{{ Images_Cahier-101-04-033.png?800 }}
\\

===== Retour chez Cloudflare =====

<WRAP center>
<WRAP column 45%>
**Continue**.
|{{ Images_Cahier-101-04-034.png?400 }}|
</WRAP>
<WRAP column 45%>
Tout s'est bien déroulé.
|{{ Images_Cahier-101-04-035.png?400 }}|
</WRAP>
</WRAP>
<WRAP clear></WRAP>
\\

**Overview**.

{{ Images_Cahier-101-04-036.png?800 }}
\\

===== Clé API =====

Il nous faut maintenant récupérer notre //clé API Globale//.\\ 

<WRAP center>
<WRAP column 30%>
\\
<nowiki>-</nowiki> Chez //Cloudflare//, on déroule le menu de l'usager.\\ 
<nowiki>-</nowiki> **My Profile**.
|{{ Images_Cahier-101-04-037.png?400 }}|
</WRAP>
<WRAP column 30%>
\\ 
\\ 
<nowiki>-</nowiki> Au bas de la page, vis-à-vis //**Global API key**//, on clique **View**,
|{{ Images_Cahier-101-04-038.png?400 }}|
</WRAP>
<WRAP column 30%>
<nowiki>-</nowiki> On entre notre mot de passe et on clique **I'm not a robot**.\\ 
<nowiki>-</nowiki> On sélectionne les images du Captcha.\\ 
<nowiki>-</nowiki> Au retour du Captcha, on clique **View**.
|{{ Images_Cahier-101-04-039.png?400 }}|
</WRAP>
</WRAP>
<WRAP clear></WRAP>
\\

<WRAP column 45%>
Notre //clé API Globale// apparaît.

{{Images_Cahier-101-03-008.png?25}} Cette clé est à garder précieusement et ne la divulguer à personne.

{{Images_Cahier-101-03-006.png?25}} On copie et on sauvegarde cette clé pour la prochaine étape.
</WRAP>
<WRAP column 45%>
|{{ Images_Cahier-101-04-040.png?400 }}|
</WRAP>
<WRAP clear></WRAP>
\\

===== 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>

{{Images_Cahier-101-03-006.png?25}} 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//.

{{Images_Cahier-101-03-003.png?22}} 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|https://github.com/Neilpang/acme.sh/blob/master/dnsapi/README.md]].

{{Images_Cahier-101-03-006.png?25}} 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>

{{Images_Cahier-101-03-003.png?22}} {{Images_Cahier-101-03-006.png?25}} <wrap em>Si vous réamorcez</wrap> 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 <wrap em>TEST</wrap> 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 <wrap em>Production</wrap>.

{{Images_Cahier-101-03-004.png?25}} 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__.

<WRAP centeralign>
{{Images_Cahier-101-03-006.png?25}} On clique le cadenas pour afficher les informations de la connexion, puis on clique l'icône "**<wrap em>></wrap>**".
</WRAP>

{{ Images_Cahier-101-04-041.png?700 }}
\\

<WRAP column 30%>
\\ 
\\ 
**Plus d'informations**.
|{{ Images_Cahier-101-04-042.png?400 }}|
</WRAP>
<WRAP column 30%>
\\ 
\\ 
Onglet **Sécurité  ->  Afficher le certificat**.
|{{ Images_Cahier-101-04-043.png?400 }}|
</WRAP>
<WRAP column 30%>
<nowiki>-</nowiki> Le certificat a été émis par //**Let's Encrypt Authority X3**//.\\ 
<nowiki>-</nowiki> On clique l'onglet **Détails**.
|{{ Images_Cahier-101-04-044.png?400 }}|
</WRAP>
<WRAP clear></WRAP>
\\

<WRAP column 40%>
<nowiki>-</nowiki> On clique **Nom alternatif du sujet du certificat**.

<nowiki>-</nowiki> Les CNAME sont présents.
</WRAP>
<WRAP column 45%>
|{{ Images_Cahier-101-04-045.png?400 }}|
</WRAP>
<WRAP clear></WRAP>
\\

===== 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>

{{Images_Cahier-101-03-005.png?25}} 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>

<WRAP centeralign>**Le certificat Let's Encrypt fonctionne correctement pour un Serveur NethServer LOCAL.**</WRAP> 
\\ 

===== Répertoire well-known =====

//Référence:// [[https://dev-notes.eu/2017/01/apache-directives-in-config-vs-htaccess/|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|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 [[nethserver_101_cahier_05_vdsl_fqdn_internet_et_nethserver|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 ====

{{Images_Cahier-101-03-006.png?25}} 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>

{{Images_Cahier-101-03-006.png?25}} 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.

{{Images_Cahier-101-03-006.png?25}} 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 //<nowiki>/etc/httpd/conf/z_well-known.conf</nowiki>//. 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>
\\ 
\\ 
{{NS-101_002_Banniere_Victoire.png?50}}  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: <nowiki>E:\000_DocPourRF232_general\RF-232_NethServer\RF-232_Cours_NethServer-101_Cahier-04_NethServer_LOCAL_LetsEncrypt_2019-08-05_10h40.odt</nowiki>.

===== 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**-10****1**.|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 branché 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 document 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 directs 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 ordinateur 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.
\\
\\