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.

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.

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.

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.

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)²⁾ 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) ====

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