Changes

From SME Server

153,327 bytes added , 03:27, 7 October 2018

RC-001

__TOC__
 

= Description générale =

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

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

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

'''Serveurs SME sme-9 et dev'''

[[Image:SME-101.04-001-ButFinal.png|top|center|700px]]

=== Marche à suivre ===
Utilisant un Serveur SME-9.2 physique - 206.248.138.152 nous allons décrire l'installation du client <code>dehydrated</code> de Let's Encrypt.

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

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

'''Remarques'''

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

Particularités du nouveau Serveur SME:

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

Configuration des cartes réseau du nouveau Serveur SME.
# ifconfig

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

eth1 Link encap:Ethernet HWaddr EC:08:6B:04:BF:7E
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:343 errors:0 dropped:0 overruns:0 frame:0
TX packets:361 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:100096 (97.7 KiB) TX bytes:62490 (61.0 KiB)

lo Link encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:161 errors:0 dropped:0 overruns:0 frame:0
TX packets:161 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:12722 (12.4 KiB) TX bytes:12722 (12.4 KiB)

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

'''But final'''

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

[[Image:SME-101-ButFinal.png|top|center|700px]]

'''Cours SME-101'''

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

* '''Cahier-00''': Les bases de Linux,  https://wiki.contribs.org/SME-101.00_Linux_de_base.
* '''Cahier-01''': Installation et configuration des logiciels prérequis sur le poste de travail de l'Étudiant de même que le téléchargement des fichiers qui seront installés sur le Serveur SME virtuel,  https://wiki.contribs.org/SME-101.01_Logiciels_de_la_station_de_travail.
* '''Cahier-02''': Description du parcours des paquets IP du Serveur SME vers l'Internet, création de la machine virtuelle, installation/configuration du serveur Linux SME et enfin, sauvegarde/restauration de ce dernier,  https://wiki.contribs.org/SME-101.02_Serveur_SME.
* '''Cahier-03''': Abonnement à un FAI, installation et configuration d'un modem ADSL/VDSL, création d'un domaine chez un fournisseur de Service DNS dynamique avec installation d'un script pour sa mise à jour et enfin la marche à suivre pour l'obtention et la configuration d'un domaine FQDN<ref name="ftn1"> '''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].'''</ref>,  https://wiki.contribs.org/SME-101.03_ADSL/VDSL,_DDNS_et_Domaine_FQDN
* '''Cahier-04''': Installation d'un certificat SSL de l'autorité de certification Let's Encrypt et script de mise à jour.
* '''Cahier-05A''': Installation et configuration de WordPress.
* '''Cahier-05B''': Installation et configuration de l'extension de sécurité Wordfence.
* '''Cahier-06''': Installation et configuration de l'extension de vente en ligne WooCommerce, création de comptes chez Stripe et PayPal pour les paiements en ligne.
* '''Cahier-07''': Sauvegarde/restauration ou migration d'un site avec l'extension Duplicator.
* '''Cahier-08''': Serveur mandataire inversé,  https://wiki.contribs.org/Mandataire_invers%C3%A9.
* '''Cahier-09''': Supplément: SME & BackupPC-4.2,  https://wiki.contribs.org/BackupPC-4.2.

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

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

'''''Notes au lecteur'''''

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

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

'''''Conventions'''''

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

# ping 192.168.1.149

192.168.1.149 is alive

Les liens de référence Internet sont en bleu de même que ceux intra document.

[[Image:Icone-SeTirerDembarrasAPT.png|20px]]  Manipulation, truc ou ruse pour se tirer d’embarras.

[[Image:Icone-AstuceAPT.png|25px]]  Une recommandation ou astuce.

[[Image:Icone-NoteAPT.png|25px]]  Une note.

[[Image:Icone-AsurveillerAPT.png|25px]]  Une étape, note ou procédure à surveiller.

[[Image:Icone-DangerAPT.png|25px]]  Danger pour la sécurité du système.

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

{| class="wikitable" style="width: 80%; background-color:#F0FFFF;"
|- style="vertical-align:top;font-family: Courier New;"
|Commande à exécuter si ce n'est déjà fait.
|}

{| class="wikitable" style="width: 80%; background-color:#FFEED9;"
|- style="vertical-align:top;font-family: Courier New;"
|Commande indiquée à titre d'information seulement.
|}

= Glossaire =

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

'''Cryptographie asymétrique'''

''Référence'': [https://fr.wikipedia.org/wiki/Cryptographie_asymé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'''

L'un des rôles de la clé publique est de permettre le [https://fr.wikipedia.org/wiki/Chiffrement chiffrement]<nowiki>; 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.</nowiki>

'''Échange de clés Diffie-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].

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

'''Certificat'''

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

'''Certificats à Validation de Domaine (DV)'''

Référence: [https://www.networking4all.com/fr/certificats+ssl/produits/par+validation/de+nom+de+domaine/ https://www.networking4all.com/fr/certificats+ssl/produits/par+validation/de+nom+de+domaine/].

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

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

'''''Avantages'''''

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

'''''Bon à savoir'''''

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

'''''Pour qui?'''''

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

'''SAN et Wildcard'''

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

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

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

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

'''''Pourquoi ai-je besoin d'un SAN?'''''

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

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

* www.macompagnie.com
* mail.macompagnie.com
* macompagnie.com
* www.toto.net
* mail.toto.net
* toto.net

'''''Certificat SAN vs certificat Wildcard'''''

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

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

'''''Certificats SSL Wildcard'''''

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

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

'''CNAME'''

Référence: [http://www.networking4all.com/fr/support/noms+de+domaine/dns/archives+cname/ http://www.networking4all.com/fr/support/noms+de+domaine/dns/archives+cname/].

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:

[[Image:SME-101.04-003-CNAMEexemple.png|top|right|400px|border]]
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.

[[Image:Icone-AstuceAPT.png|25px]]  Micronator a un serveur privé ''(sur le réseau LOCAL)'' qui fait partie du domaine principal et dont le nom est coquille. Nous pouvons alors insérer un CNAME coquille pour ce serveur.
 

= Let's Encrypt =

=== Principe de fonctionnement de Letsencrypt ===
Référence: [https://linuxfr.org/news/reparlons-de-let-s-encrypt https://linuxfr.org/news/reparlons-de-let-s-encrypt].

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

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

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

Pour obtenir un certificat, le client dehydrated:

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

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

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

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

=== Courriels du certificat ===

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

=== Transparence des certificats ===

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

=== Limites ===

'''''90 jours'''''

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

'''''5/7'''''

En date du 2018-10-05:

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

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

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

[[Image:Icone-NoteAPT.png|25px]]  '''''Note importante sur le fichier domains.txt'''''

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

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

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

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

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

[[Image:Icone-AsurveillerAPT.png|25px]]  Le résultat d'une telle énumération des domaines pourrait facilement atteindre ou dépasser la limite décrite 5/7.

=== Mode Officiel vs TEST (Staging) ===

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

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

'''Autorité de certification (CA)'''

'''''CA officielle'''''

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

'''''CA de TEST'''''

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

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

[[Image:Icone-SeTirerDembarrasAPT.png|20px]]  Il est fortement recommandé de débuter en demandant un certificat de test.

'''Fichier de configuration'''

'''Certificat officiel'''

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

[[Image:Icone-AstuceAPT.png|25px]]  Pour une demande de certificat, il est inutile de spécifier un fichier de configuration car, par défaut, c'est le fichier <code>config</code> qui est utilisé.

Fichier <code>config</code> de la configuration standard.

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

PARAM_ACCEPT_TERMS="yes"

'''Certificat de TEST'''

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

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

PARAM_ACCEPT_TERMS="yes"

=== Clé de compte Let's Encrypt ===

[[Image:Icone-NoteAPT.png|25px]]  La clé de compte Let's Encrypt est différente de la clé <code>privkey-nnnnnnnnn.pem</code> utilisée par le Serveur SME. Cette dernière est stockée dans le répertoire <code>/etc/dehydrated/certs/nom-du-domaine/</code>.

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

* Si on demande un certificat de TEST, un sous-répertoire y est créé pour stocker la clé de compte de TEST.
* Si on demande un certificat OFFICIEL, un autre sous-répertoire y est créé pour stocker la clé de compte OFFICIEL.
* Le sous-répertoire de la clé de compte de TEST est créé lors de la première demande d'un certificat de TEST et celui de la clé de compte OFFICIEL est créé lors de la première demande d'un certificat officiel.
* [[Image:Icone-AsurveillerAPT.png|25px]]  Le sous-répertoire et la clé utilisée dépendent de la ligne <code>CA="https://...</code> dans le fichier de configuration <code>config</code>.

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

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

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

[[Image:Icone-NoteAPT.png|25px]]  Une clé SSL est toujours constituée d'une partie publique et d'une partie privée.

=== Aide ===

Pour afficher l'aide du client dehydrated.

dehydrated --help

=== En cas de trouble majeur avec un certificat ===

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

= À savoir =

'''Conditions préalables'''

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

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

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

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

[[Image:Icone-AsurveillerAPT.png|25px]]  Assurez-vous que tout est correctement en place avant de continuer.

[[Image:Icone-SeTirerDembarrasAPT.png|20px]]  Avant de commencer l'installation, vérifiez si vous, ou une CONTRIB précédemment installée, avez configuré des valeurs personnalisées pour votre certificat TLS/SSL présentement actif.

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

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

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

= Certificat Let's Encrypt =

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

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

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

Let's Encrypt est une autorité de certification ''(CA)'' lancée le 3 décembre 2015 ''(Bêta Version Publique)''. Cette autorité fournit des certificats gratuits X.509 pour le protocole cryptographique TLS/SSL au moyen d'un mécanisme automatisé destiné à se passer du processus complexe actuel impliquant: la création manuelle, la validation, la signature, l'installation et le renouvellement des certificats pour la sécurisation des sites Internet.

=== Installation ===

On installe la Contrib <code>smeserver-letsencrypt</code>.
# yum install -y --enablerepo=smecontribs smeserver-letsencrypt

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

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

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

Terminé !

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

signal-event post-upgrade; signal-event reboot

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

'''Signalisation des changements'''

On applique les changements en signalant une mise à jour et un réamorçage.
# signal-event post-upgrade ; signal-event reboot

[[Image:Icone-AsurveillerAPT.png|25px]]  Ne pas signaler les changements pourrait empêcher la Contrib de fonctionner correctement et vos certificats ne seront pas renouvelés.

=== Mise à jour de la Contrib ===

[[Image:Icone-AstuceAPT.png|25px]]  Vous pouvez manuellement mettre à jour la Contrib i.e. <code>smeserver-letsencrypt</code> et <code>dehydrated</code> en utilisant la commande ci-dessous.
# yum update -y --enablerepo=smecontribs smeserver-letsencrypt dehydrated

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

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

'''''Signalisation des changements'''''

Si vous aviez fait une mise à jour, vous devriez signaler les changements.
# signal-event post-upgrade <nowiki>; </nowiki> signal-event reboot

=== Création des fichiers et répertoires requis ===

'''Répertoire des défis'''

Le greffon <code>webroot</code> fonctionne en créant un fichier temporaire incluant chacun des domaines demandés dans <code>${webroot-path}/.well-known/acme-challenge/</code>. Le serveur de validation de Let's Encrypt fera des requêtes HTTP pour valider que tous les noms de domaines/CNAME contenus dans le fichier <code>domains.txt</code> pointent vers le serveur exécutant <code>dehydrated</code>.

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

/root

On crée le répertoire des défis ''(challenge)''.
# mkdir -p /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge

On ajuste '''R'''écursivement le propriétaire et le groupe de ces répertoires.
# chown -R admin:shared /home/e-smith/files/ibays/Primary/html/.well-known/

On ajuste '''R'''écursivement les droits.
# chmod -R 2750 /home/e-smith/files/ibays/Primary/html/.well-known/

On vérifie le répertoire <code>.well-known</code>.
# ls -alsd /home/e-smith/files/ibays/Primary/html/.well-known/

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

On vérifie le répertoire <code>acme-challenge</code>.
# ls -alsd /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge

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


'''Gabarit personnalisé'''

Nous avons besoin d'un gabarit personnalisé ''(custom template)'' pour indiquer à Apache, le répertoire <code>acme-challenge</code>.

On crée le répertoire pour le gabarit personnalisé.
# mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf

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

[[Image:Icone-AsurveillerAPT.png|25px]]  Prendre tout le contenu de l'encadré pour la commande.

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

EOT

On vérifie.
# cat /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts40ACME

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

[[Image:Icone-AsurveillerAPT.png|25px]]  Il n'y a pas de ligne vide avant la ligne <code># Alias for letsencrypt</code>. Ci-dessus, nous avons inséré une ligne vide pour faciliter la copie de la commande.

On développe le gabarit personnalisé.
# expand-template /etc/httpd/conf/httpd.conf

'''''Redémarrage du service httpd-e-smith'''''
# service httpd-e-smith restart

Restarting httpd-e-smith [ OK ]

=== Choix des domaines et des hôtes ===

On affiche les nom d'hôtes sur notre Serveur SME.
# db hosts show | grep .com

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

[[Image:SME-101.04-004-CNAME101.png|450px|thumb|<center>'''''CNAME: pour micronator-101.com'''''</center>]][[Image:Icone-AsurveillerAPT.png|25px]]  Si certains de vos défis sont renvoyés sans erreur, mais que certains échouent, il est possible que vous n'ayez pas d'enregistrements DNS A, MX ou CNAME pour tous les noms d'hôtes que vous avez ajoutés à votre certificat. Lorsque Let's Encrypt lance les défis pour une liste de noms d'hôtes et qu'un de ceux-ci ne répond pas, le défi échoue et le certificat n'est pas généré.

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

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

{| class="wikitable" style="width: 55%; background-color:#FFEED9;"
|- style="vertical-align:top;font-family: Courier New;"
|
<nowiki>#</nowiki> config setprop letsencrypt configure all
|}

[[Image:Icone-NoteAPT.png|25px]]  La commande <code>config setprop letsencrypt configure all</code> est susceptible de provoquer une erreur de défi.

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

Pour utiliser des hôtes ou des domaines activés individuellement, on active le paramètre configure à <code>none</code> et ensuite on ajoute les domaines et les noms d'hôtes désirés.
# config setprop letsencrypt configure none

'''''Domaines'''''

On inclut micronator-101.com.
# db domains setprop micronator-101.com letsencryptSSLcert enabled

On vérifie.
# db domains show

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

'''''Hôtes'''''

On inclut tous les hôtes suivants.

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

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

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

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

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

=== Autres propriétés de configuration ===

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


'''Ajout d'une adresse courriel'''

[[Image:Icone-NoteAPT.png|25px]]  Le '''domaine''' de messagerie spécifié n'a nul besoin de correspondre à l'un des domaines pour lesquels vous demandez un certificat.
# config setprop letsencrypt email admin@'''micronator.org'''

'''Longueur de la clé privée'''

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

{| class="wikitable" style="width: 80%; background-color:#FFEED9;"
|- style="vertical-align:top;font-family: Courier New;"
|
<nowiki>#</nowiki> config setprop letsencrypt keysize LONGUEUR-EN-BITS
|}

=== Termes et conditions ===

[[Image:Icone-AsurveillerAPT.png|25px]]  Veuillez d'abord lire les conditions d'utilisation de Let's Encrypt:  [https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf]

[[Image:Icone-AsurveillerAPT.png|25px]]  Seulement si vous acceptez les termes et conditions de Let's Encrypt, lancez la commande ci-dessous.
# config setprop letsencrypt ACCEPT_TERMS yes

=== Activation du mode TEST ===

''Référence'': [https://github.com/lukas2511/letsencrypt.sh https://github.com/lukas2511/dehydrated].

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

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

On active le mode TEST.
# config setprop letsencrypt status test

On signale les changements. ''(Peut prendre plusieurs secondes.)''
# signal-event console-save

=== Vérification ===

On vérifie si on est bien en mode TEST.
# cat /etc/dehydrated/config | grep CA

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

On vérifie l'adresse courriel.
# cat /etc/dehydrated/config | grep CONTACT

CONTACT_EMAIL=admin@'''micronator.org'''

On vérifie les domaines et les hôtes.
# cat /etc/dehydrated/domains.txt

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

[[Image:Icone-SeTirerDembarrasAPT.png|20px]]  Tout le contenu du fichier <code>domains.txt</code> doit être entièrement sur une seule ligne sinon, vous aurez autant de certificats que de lignes et vous atteindrez la limite 5/7 de Let's Encrypt.

[[Image:Icone-AstuceAPT.png|25px]]  Le certificat sera émis au nom du premier domaine de la ligne; ici, ce sera micronator-101.com.

=== Affichage de l'aide sur la commande dehydrated ===
# dehydrated --help

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

Default command: help

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

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

=== Lancement du script dehydrated ===

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

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

Aucune erreur, tout a bien fonctionné.

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

'''ERREUR'''

[[Image:Icone-SeTirerDembarrasAPT.png|20px]]  Si vous recevez l'erreur ci-dessous, simplement relancer la demande. Il se peut que vous ayez à le faire plusieurs fois.

{| class="wikitable" style="width: 80%; background-color:#FFEED9;"
|- style="vertical-align:top;font-family: Courier New;"
|
<nowiki>#</nowiki> '''dehydrated -c''' 
<nowiki> </nowiki> 
<nowiki># INFO: Using main config file /etc/dehydrated/config</nowiki> 
<nowiki>ERROR: Problem connecting to server (get for https://acme-v01.api.letsencrypt.org/directory; curl returned with 6)</nowiki>
|}

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

{| class="wikitable" style="width: 80%; background-color:#FFEED9;"
|- style="vertical-align:top;font-family: Courier New;"
|
<nowiki>...</nowiki> 
<nowiki>+ Requesting challenge for micronator-101.com...</nowiki> 
<nowiki>ERROR: Problem connecting to server (post for https://acme-v01.api.api.letsencrypt.org/acme/new-authz; curl returned with 35)</nowiki> 
<nowiki>...</nowiki>
|}

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

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

{| class="wikitable" style="width: 80%; background-color:#FFEED9;"
|- style="vertical-align:top;font-family: Courier New;"
|
<nowiki>#</nowiki> '''date;time curl -s4 https://acme-v01.api.letsencrypt.org/acme/new-authz >/dev/null''' 
<nowiki>  </nowiki> 
<nowiki>jeu. oct. 4 09:48:54 EDT 2018</nowiki> 
<nowiki>  </nowiki> 
<nowiki>real 0m5.264s</nowiki> 
<nowiki>user 0m0.058s</nowiki> 
<nowiki>sys 0m0.046s</nowiki>
|}

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

{| class="wikitable" style="width: 80%; background-color:#FFEED9;"
|- style="vertical-align:top;font-family: Courier New;"
|
<nowiki>#</nowiki> '''date;time curl -s6 https://acme-v01.api.letsencrypt.org/acme/new-authz >/dev/null''' 
<nowiki>  </nowiki> 
<nowiki>jeu. oct. 4 09:52:35 EDT 2018</nowiki> 
<nowiki>  </nowiki> 
<nowiki>real 0m47.367s</nowiki> 
<nowiki>user 0m0.061s</nowiki> 
<nowiki>sys 0m0.042s</nowiki>
|}

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

{| class="wikitable" style="width: 80%; background-color:#FFEED9;"
|- style="vertical-align:top;font-family: Courier New;"
|
<nowiki>#</nowiki> '''date;time curl -s4 https:https://acme-v01.api.letsencrypt.org/acme/new-authz >/dev/null''' 
<nowiki> </nowiki> 
<nowiki>jeu. oct. 4 09:53:29 EDT 2018</nowiki> 
<nowiki> </nowiki> 
<nowiki>real 0m0.004s</nowiki> 
<nowiki>user 0m0.002s</nowiki> 
<nowiki>sys 0m0.000s</nowiki> 
|}

=== Vérification du certificat ===

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

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

Avec Firefox, on se connecte au gestionnaire Server Manager.  [[Image:SME-101.04-005-Verif-0A.png|middle|500px|border]]
 
 


{| style="float: right; margin-left:0.5em ;margin-right:40px;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-006-Verif-B.png|400px|border]]
|}
{| style="float: right; margin-left:0.5em; margin-right:0.5em;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-005-Verif-A.png|400px|border]]
|}
* Après avoir accepté le certificat, on clique le ''cadenas'' puis, on clique >.
* ''Plus d'informations''.
 



{| style="float: right; margin-left:0.5em ;margin-right:40px;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-008-Verif-D.png|400px|border]]
|}
{| style="float: right; margin-left:0.5em; margin-right:0.5em;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-007-Verif-C.png|400px|border]]
|}
* ''Afficher le certificat''.
* - Certificat de test car, émis par "Fake LE Intermediate XI". - ''Détails''.
 



{| style="float: right; margin-left:0.5em ;margin-right:40px;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-010-Verif-F.png|400px|border]]
|}
{| style="float: right; margin-left:0.5em; margin-right:0.5em;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-009-Verif-E.png|400px|border]]
|}
* - ''Nom alternatif du sujet du certificat''. - Nos noms d'hôtes sont présents.
* - ''Pas après''. - Valide pour 90 jours > ''Fermer''.
 


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

Activation du mode Production.
# config setprop letsencrypt status enabled

On signale les changements. Peut prendre plusieurs secondes.
# signal-event console-save

'''Demande d'un certificat OFFICIEL'''

On fait la demande d'un certificat OFFICIEL. Le paramètre <code>-x</code> est nécessaire pour forcer un nouveau certificat.
# dehydrated -c -x

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

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

=== Vérification avec le gestionnaire Server Manager ===

Avec Firefox, on se connecte au gestionnaire Server Manager.


{| style="float: right; margin-left:0.5em ;margin-right:40px;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-012-VerifSM-B.png|400px|border]]
|}
{| style="float: right; margin-left:0.5em; margin-right:0.5em;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-011-VerifSM-A.png|400px|border]]
|}
* Après avoir accepté le certificat, on clique le cadenas  >  >.
* ''Plus d'informations''.
 



{| style="float: right; margin-left:0.5em ;margin-right:40px;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-014-VerifSM-D.png|400px|border]]
|}
{| style="float: right; margin-left:0.5em; margin-right:0.5em;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-013-VerifSM-C.png|400px|border]]
|}
* ''Afficher le certificat''.
* - Certificat Officiel car, émis par Let's Encrypt Authority X3. - ''Détails''.
 



{| style="float: right; margin-left:0.5em ;margin-right:40px;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-016-VerifSM-F.png|400px|border]]
|}
{| style="float: right; margin-left:0.5em; margin-right:0.5em;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-015-VerifSM-E.png|400px|border]]
|}
* - ''Nom alternatif du sujet du certificat''.
- Nos noms d'hôtes sont présents.
* - Pas après. 
- Valide pour 90 jours   >   ''Fermer''.
 



{| style="float: right; margin-left:0.5em ;margin-right:455px;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-017-VerifSM-G.png|400px|border]]
|}
* Le certificat SAN a été émis pour le premier domaine de la ligne du fichier <code>/etc/dehydrated/domains.txt</code>. Ici le certificat a été émis pour le site micronator-101.com.
 


On affiche le fichier les domaines.
# cat /etc/dehydrated/domains.txt

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

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


{| style="float: right; margin-left:0.5em ;margin-right:40px;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-019-Qualsys-B.png|400px|border]]
|}
{| style="float: right; margin-left:0.5em; margin-right:0.5em;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-018-Qualsys-A.png|400px|border]]
|}
* ''micronator-101.com''  >  ''Submit''.
* La remarque: 
{| class="wikitable" style="width: 27%; background-color:#FFEED9;"
|- style="vertical-align:top;font-family: Courier New;"
|
This server does not support Forward Secrecy with the reference browsers. Grade capped to B.
|}
peut être ignorée car, le Serveur SME ne supporte pas Forward Secrecy.
 


=== Vérification des fichiers et répertoires ===

On vérifie le répertoire <code>/etc/dehydrated/</code>.
# ls -als /etc/dehydrated/

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

On vérifie le répertoire <code>/etc/dehydrated/certs/</code>.
# ls -als /etc/dehydrated/certs/

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

[[Image:Icone-NoteAPT.png|25px]]  Le script a créé un répertoire de stockage pour notre domaine micronator-101.com ''(le premier de la ligne de notre fichier /etc/dehydrated/domains.txt)''.

On vérifie le répertoire <code>micronator-101.com/</code>.
# ls -als /etc/dehydrated/certs/micronator-101.com/

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

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

'''modSSL'''

Les paramètres de <code>modSSL</code> ont été modifiés.
# config show modSSL

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

=== Conclusion ===

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

= Renouvellement =

=== Manuel ===

'''Situation actuelle'''

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

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

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

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

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

=== Manuel forcé ===

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

* Attendre la fin du certificat.
* Révoquer le certificat.
* Modifier un domaine du fichier domains.txt.
* Ajouter/enlever un domaine au fichier <code>domains.txt</code>.
* Utiliser l'option <code>--force</code> lors du lancement de la commande dehydrated.

On choisit de lancer le client <code>dehydrated</code> avec l'option <code>--force</code> pour imposer un renouvellement.
# dehydrated -c --force 

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

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

Pour ce renouvellement, le client <code>dehydrated</code>:

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

Tous les répertoires existaient, la ligne ci-dessous est donc manquante avec ce renouvellement.
+ Creating new directory /etc/dehydrated/certs/micronator-101.com ...

=== Vérification ===

On vérifie le répertoire <code>/etc/dehydrated/</code>.
# ls -als /etc/dehydrated/

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

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

On vérifie le répertoire <code>/etc/dehydrated/certs/</code>.
# ls -als /etc/dehydrated/certs/

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

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

On vérifie le répertoire <code>/etc/dehydrated/certs/micronator-101.com/</code>.
# ls -als /etc/dehydrated/certs/micronator-101.com/

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

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

[[Image:Icone-NoteAPT.png|25px]]  Les propriétés de <code>modSSL</code> ont été modifiées mais vu que <code>dehydrated</code> utilise des pointeurs qui ne changent jamais de noms, il semble que les pointeurs soient demeurés les mêmes.

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

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

'''Courriel de notification'''

Réception d'un courriel par admin.

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

{| class="wikitable" style="width: 80%; background-color:#FFEED9;"
|- style="vertical-align:top;font-family: Courier New;"
|
<nowiki># INFO: Using main config file /etc/dehydrated/config</nowiki> 
Processing micronator-101.com with alternative names: ftp.micronator-101.com mail.micronator-101.com proxy.micronator-101.com wpad.micronator-101.com www.micronator-101.com 
<nowiki>+ Checking domain name(s) of existing cert... unchanged.</nowiki> 
<nowiki>+ Checking expire date of existing cert...</nowiki> 
<nowiki>+ Valid till Jan 2 12:54:21 2019 GMT (Longer than 30 days). Skipping renew!</nowiki>
|}

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

'''Fichier pem'''

On affiche la date de création du fichier <code>pem</code> après le renouvellement forcé.
# ls -ls /home/e-smith/ssl.pem/sme-9.micronator-101.com.pem

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

[[Image:Icone-NoteAPT.png|25px]]  Le fichier pem vient tout juste d'être installé, après la réception du certificat du renouvellement forcé et en même temps que <code>privkey.pem</code>. Le nouveau certificat est fonctionnel.

'''Navigateur Web'''

'''''Firefox'''''

[[Image:Icone-NoteAPT.png|25px]]  La CA "Let’s Encrypt Authority X3" étant dans la chaîne des CA et de ce fait reconnue, le certificat est automatiquement accepté.


{| style="float: right; margin-left:0.5em ;margin-right:40px;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-021-VerifFF-B.png|400px|border]]
|}
{| style="float: right; margin-left:0.5em; margin-right:0.5em;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-020-VerifFF-A.png|400px|border]]
|}
* - Site: https://www.micronator-101.com/. - Le ''cadenas'' est '''vert''', on le clique. - On voit que la connexion est sécurisée. - On clique l'icône ">" à droite.
* ''Plus d'informations''.
 



{| style="float: right; margin-left:0.5em ;margin-right:40px;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-023-VerifFF-D.png|400px|border]]
|}
{| style="float: right; margin-left:0.5em; margin-right:0.5em;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-022-VerifFF-C.png|400px|border]]
|}
* ''Afficher le certificat''.
* - Onglet ''Général''. - "Émis pour micronator-101.com". - Émis par "Let's Encrypt Authority X3". - On clique l'onglet ''Détails''.
 



{| style="float: right; margin-left:0.5em ;margin-right:40px;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-025-VerifFF-F.png|400px|border]]
|}
{| style="float: right; margin-left:0.5em; margin-right:0.5em;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-024-VerifFF-E.png|400px|border]]
|}
* - ''Émetteur''. - Les détails de Let's Encrypt Authority X3 sont affichés.
* - ''Validité''   >   ''Pas avant''. - La date et l'heure de l'émission sont affichées.
 



{| style="float: right; margin-left:0.5em ;margin-right:455px;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-026-VerifFF-G.png|400px|border]]
|}
* - ''Nom alternatif du sujet du certificat''. - Tous les domaines couverts sont affichés. - On ferme toutes les fenêtres.
 


'''''Internet Explorer'''''


{| style="float: right; margin-left:0.5em ;margin-right:40px;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-028-VerifIE-B.png|400px|border]]
|}
{| style="float: right; margin-left:0.5em; margin-right:0.5em;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-027-VerifIE-A.png|400px|border]]
|}
* - Site: https://www.micronator-101.com/. - Il semble que c'est Avast! qui a émis le certificat? - On clique Afficher le certificat.
* C'est bien Avast! qui a émis le certificat. [[Image:Icone-NoteAPT.png|25px]]  Les résultats qu'on voit ici sont dûs au module de l'antivirus Avast! pour IE. Ce module d'Avast! en est un du genre homme-du-milieu ''(man in the middle)'' qui intercepte toutes les requêtes https et qui émet son propre certificat.
 



{| style="float: right; margin-left:0.5em ;margin-right:40px;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-030-VerifIE-D.png|400px|border]]
|}
{| style="float: right; margin-left:0.5em; margin-right:0.5em;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-029-VerifIE-C.png|400px|border]]
|}
* [[Image:Icone-NoteAPT.png|25px]]  La protection Courriel/Web d'Avast! doit être capable de balayer le trafic Web avant de l'envoyer au fureteur. Le balayage d'un connecteur logiciel ''(socket)'' chiffré TLS exige qu'Avast! puisse déchiffrer la connexion. Il n'y a pas d'autre moyen pour Avast! de déchiffrer la connexion que de générer son propre certificat et de le signer avec un certificat racine d'Avast déjà installé sur le système. C'est uniquement de cette façon qu'Avast! peut vérifier la connexion. [[Image:Icone-NoteAPT.png|25px]]  Même si on importe le fichier du certificat de Let's Encrypt dans IE, ce dernier persiste à utiliser celui d'Avast!.

''Contournement du problème''

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


{| style="float: right; margin-left:0.5em ;margin-right:40px;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-032-VerifIE-F.png|400px|border]]
|}
{| style="float: right; margin-left:0.5em; margin-right:0.5em;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-031-VerifIE-E.png|400px|border]]
|}
* - On arrête les agents Avast!. - Clac ''(clic droit'') sur l'icône Avast! sur la barre de notification   >   ''Gestion des agents Avast''   >   ''Désactiver pour 10 minutes''.
* À l'écran qui s'affiche, on clique ''Oui'' pour l'Arrêt d'un composant.
 



{| style="float: right; margin-left:0.5em ;margin-right:40px;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-034-VerifIE-H.png|400px|border]]
|}
{| style="float: right; margin-left:0.5em; margin-right:0.5em;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-033-VerifIE-G.png|400px|border]]
|}
* - On se rend à: https://www.micronator-101.com/. - On clique le ''cadenas''. - ''Afficher les certificats''.
* - L'émetteur du certificat est affiché: "Let's Encrypt Authority X3". - On ferme toutes les fenêtres.
 



{| style="float: right; margin-left:0.5em ;margin-right:40px;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-036-VerifIE-J.png|400px|border]]
|}
{| style="float: right; margin-left:0.5em; margin-right:0.5em;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-035-VerifIE-I.png|400px|border]]
|}
* [[Image:Icone-AsurveillerAPT.png|25px]]  Il faut réactiver les agents Avast. Clac sur l'''icône Avast!'' sur la barre de notifications  >  ''Gestion des agents Avast''  >  ''Activer tous les Agents (3 désactivés)''.
* On ferme Internet Explorer, on le relance et on se rend encore une fois à https://www.micronator-101.com/; le certificat retourne à celui d'Avast!. [[Image:Icone-SeTirerDembarrasAPT.png|20px]]  Vu que chez Micronator, il est formellement interdit d'utiliser un navigateur Microsoft, de quelle que version que ce soit, on n'a pas de tels problèmes.
 


'''''TOR'''''

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

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

[[Image:Icone-AsurveillerAPT.png|25px]]  Il faut absolument télécharger TOR '''du site original seulement'''.



{| style="float: right; margin-left:0.5em ;margin-right:40px;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-038-VerifTOR-B.png|400px|border]]
|}
{| style="float: right; margin-left:0.5em; margin-right:0.5em;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-037-VerifTOR-A.png|400px|border]]
|}
* Même si nous avons lancé TOR sur notre station de travail, la requête pour notre site a passé par la France, les États-Unis et l'Ukraine.
* - Le cadenas est '''vert''', on le clique. - On voit que la "connexion est sécurisée". - On clique l'icône ">" à droite.
 



{| style="float: right; margin-left:0.5em ;margin-right:40px;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-040-VerifTOR-D.png|400px|border]]
|}
{| style="float: right; margin-left:0.5em; margin-right:0.5em;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-039-VerifTOR-C.png|400px|border]]
|}
* ''More Information''.
* - Onglet ''Security''. - "Verified by: Let's Encrypt" est affiché. - ''View Certificate''.
 



{| style="float: right; margin-left:0.5em ;margin-right:455px;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-041-VerifTOR-E.png|400px|border]]
|}
* ''Onglet General''. Le certificat est bien "Émis pour micronator-101.com" et "Émis par Let's Encrypt Authority X3".
 


=== Conclusion ===

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

= Révocation =

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

=== Affichage des certificats actuels ===
# ls -ls /etc/dehydrated/certs/micronator-101.com/

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

=== Certificat de TEST ===

'''Basculement du mode OFFICIEL au mode TEST'''

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

On active le mode TEST.
<nowiki># </nowiki>config setprop letsencrypt status test

On signale les changements. ''(Peut prendre plusieurs secondes.)''
<nowiki>#</nowiki> signal-event console-save

'''''Vérification'''''

On vérifie si on est bien en mode TEST.
<nowiki># </nowiki>cat /etc/dehydrated/config | grep CA

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

'''Révocation'''

La commande générale pour la révocation d'un certificat.
dehydrated --revoke /chemin/du/cert-numéro.pem

[[Image:Icone-AsurveillerAPT.png|25px]]  On peut révoquer notre premier certificat de TEST: cert-1538660683.pem qui est datée 4 oct. 09:44.
# dehydrated --revoke /etc/dehydrated/certs/micronator-101.com/cert-1538660683.pem

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

'''Basculement du mode TEST au mode OFFICIEL'''

[[Image:Icone-AsurveillerAPT.png|25px]]  Après une manipulation en mode TEST, il devrait toujours revenir au mode OFFICIEL.
# config setprop letsencrypt status enabled

On signale les changements. ''(Peut prendre plusieurs secondes.)''
# signal-event console-save

On vérifie.

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

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

Nous sommes bien en mode Officiel.

=== Certificat officiel ===

'''Prérequis'''

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

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

[[Image:Icone-SeTirerDembarrasAPT.png|20px]]  On vérifie toujours le mode de fonctionnement avant de faire quoi que ce soit.
# cat /etc/dehydrated/config | grep http

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

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

'''Commande de révocation'''

On vérifie le chemin du certificat.
# ls -als /etc/dehydrated/certs/micronator-101.com/cert-1538670628.pem

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

On révoque le certificat.
# dehydrated --revoke /etc/dehydrated/certs/micronator-101.com/cert-1538670628.pem

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

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

'''Vérification'''

On affiche tous les certificats.
# ls -ls /etc/dehydrated/certs/micronator-101.com/

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

On essaie d'afficher le certificat révoqué.
# cat /etc/dehydrated/certs/micronator-101.com/cert-1538670628.pem

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

[[Image:Icone-NoteAPT.png|25px]]  Le système nous informe que le fichier n'existe plus. La cible du lien a été renommée cert-1538670628.pem-revoked donc, le lien pointe vers une cible qui n'existe plus.

=== Paramètres de modSSL ===

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

Le serveur utilise donc toujours les même paramètres.
# config show modSSL

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

'''Chaîne'''

On vérifie le fichier de la chaîne.
# cat /etc/dehydrated/certs/micronator-101.com/chain.pem

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

La chaîne est toujours présente.

'''Clé privée du serveur'''

On vérifie la clé privée du serveur.
# cat /etc/dehydrated/certs/micronator-101.com/privkey.pem

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

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

=== Réamorçage du serveur ===

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

[[Image:SME-101.04-042-ReAmorcageServeur.png|top|center|600px|border]]

'''Gestionnaire Server Manager'''

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

'''PuTTY'''

[[Image:Icone-AstuceAPT.png|25px]]  Tout n'est pas perdu, on peut se loguer en ouvrant une session PuTTY.
login as: root

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

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

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

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

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

<nowiki>****************************************************</nowiki>

[[Image:Icone-SeTirerDembarrasAPT.png|20px]]  Pour rétablir toutes les communications, il nous faut régénérer un certificat standard émis par le Serveur SME lui-même. Voir le chapitre [[#Certificat standard SME]].

= Obtention d'un certificat pour un serveur local =

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

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

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

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

{| class="wikitable" style="width: 80%; background-color:#FFEED9;"
|- style="vertical-align:top;font-family: Courier New;"
|
<nowiki>#</nowiki> config setprop letsencrypt hookScript enabled 
<nowiki>#</nowiki> config setprop letsencrypt host external.mydomain.tld 
<nowiki>#</nowiki> config setprop letsencrypt user root 
<nowiki>#</nowiki> config setprop letsencrypt path /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge
|}

Après avoir défini ces entrées, il faut en signaler les changements.
{| class="wikitable" style="width: 80%; background-color:#FFEED9;"
|- style="vertical-align:top;font-family: Courier New;"
|
<nowiki>#</nowiki> signal-event console-save
|}

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

=== Prérequis ===

[[Image:SME-101.04-043-Prerequis.png|top|right|450px|border]]
Chez le registraire du domaine micronator-101.com, il faut définir les entrées pour le sous domaine dev.micronator-101.com:

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

=== Résolution Internet pour le domaine du serveur local ===

[[Image:SME-101.04-044-ServeurLocal.png|top|right|700px]]
Nous avons ajouté les CNAME du paragraphe précédent pour le sous-domaine dev.micronator-101.com chez le régistraire du domaine micronator-101.com.

[[Image:Icone-NoteAPT.png|25px]]  On ne peut vérifier les CNAME du serveur à sa console car il répondra lui-même, il faut demander à un autre serveur de les vérifier.

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

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

[[Image:SME-101.04-044-ServeurLocal-AA.png|top|center|800px|border]]

=== Authentification par clé publique SSH ===

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

'''Génération de la clé SSH'''

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

root

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

* On accepte le nom du fichier par défaut en tapant la touche [Entrée].
* On n'utilise pas de phrase de passe<ref name="ftn3">'''phrase de passe''': Groupe de mots et de caractères alphanumériques ou spéciaux, faisant office de mot de passe, connu de l'utilisateur seulement, qui sert à protéger sa clé privée et à l'identifier lors d'une connexion ou d'un transfert de fichier, tout en lui assurant une plus grande sécurité. '''Notes''': Les phrases de passe ne diffèrent des mots de passe que par la longueur. Les mots de passe sont généralement très courts - de 6 à 10 caractères -, alors que les phrases de passe peuvent comporter jusqu'à 100 caractères ''(et même plus)''. Leur longueur et la combinaison des mots et des caractères alphanumériques contribuent à les rendre plus difficiles à deviner que les mots de passe, et donc plus sûres. Une phrase de passe doit être: connue que de l'utilisateur, suffisamment longue pour être sûre, difficile à deviner, facile à retenir et à saisir sans erreur. Certains considèrent qu'elle devrait atteindre 80 à 100 caractères pour être vraiment efficace. ''Référence'': [http://www.granddictionnaire.com/ficheOqlf.aspx?Id_Fiche=8361195 http://www.granddictionnaire.com/ficheOqlf.aspx?Id_Fiche=8361195].</ref> en tapant la touche [Entrée].
* On confirme en tapant encore la touche [Entrée].

# ssh-keygen -t rsa -b 2048

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

On vérifie.
# ls -ls .ssh/

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

[[Image:Icone-AsurveillerAPT.png|25px]]  La clé id_rsa est la clé privée qui doit toujours être cachée et '''n'être divulguée à absolument personne'''.

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

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

[[Image:Icone-NoteAPT.png|25px]]  Ce jeu de clés SSH servira uniquement à l'utilisateur root pour ses communications SSH entre le serveur intranet et le serveur principal.

[[Image:Icone-AsurveillerAPT.png|25px]]  Ce jeu de clés SSH est différent du jeu standard d'un Serveur SME qui se trouve dans le répertoire <code>/etc/ssh/</code> et qui comprend: ssh_host_rsa_key et ssh_host_rsa_key.pub.
# ls -als /etc/ssh/ssh_host_rsa*

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

'''''Port SSHD'''''

[[Image:SME-101.04-045-PortSSHD.png|top|right|600px|border]]
Le port standard utilisé par le démon SSHD est 22. Pour déjouer un peu plus les pirates malveillants, lors de l'installation de nos Serveurs SME, nous configurons toujours le port 2222 comme port par défaut pour SSHD.

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

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

[[Image:Icone-AstuceAPT.png|25px]]  Les paramètres dans le fichier de configuration SSH de root auront préséance sur tous les autres paramètres spécifiant le port SSH pour cet utilisateur seulement.
 
 
'''''Spécification du port SSH pour l'utilisateur root'''''

Il existe plusieurs façons de spécifier ce port mais, la plus efficace est celle ci-dessous.
{| class="wikitable" style="width: 80%; background-color:#FFEED9;"
|- style="vertical-align:top;font-family: Courier New;"
|
Host * 
    Port 2222
|}

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

Nous aurions pu utiliser l'expression suivante pour spécifier uniquement le nom d'un hôte particulier.
{| class="wikitable" style="width: 80%; background-color:#FFEED9;"
|- style="vertical-align:top;font-family: Courier New;"
|
Host 192.168.1.1 
    Port 2222
|}

Ou celle-ci pour spécifier tous les serveur sur le réseau 192.168.1.0.
{| class="wikitable" style="width: 80%; background-color:#FFEED9;"
|- style="vertical-align:top;font-family: Courier New;"
|
Host 192.168.1.0/24 
    Port 2222
|}

On peut aussi spécifier des hôtes utilisant des ports différents.
{| class="wikitable" style="width: 80%; background-color:#FFEED9;"
|- style="vertical-align:top;font-family: Courier New;"
|
Host 192.168.1.1 
    Port 2222 
   
Host 192.168.1.11 
    Port 3333
|}

[[Image:Icone-AsurveillerAPT.png|25px]]  [[Image:Icone-AsurveillerAPT.png|25px]]  Il faut que le mot "Port" soit à au moins un espace de la marge de gauche.

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

[[Image:Icone-AsurveillerAPT.png|25px]]  Prendre tout le contenu de l'encadré pour la commande.
cat > /root/.ssh/config <<'EOT'

Host 192.168.1.1
Port 2222

EOT

On vérifie le contenu.
# cat /root/.ssh/config

Host 192.168.1.1
Port 2222

[[Image:Icone-AsurveillerAPT.png|25px]]  Il peut y avoir une ligne vide avant la ligne Host 192.168.1.1.

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

Sommes-nous toujours l'usager root?
# whoami

root

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

[[Image:Icone-AsurveillerAPT.png|25px]]  La commande est sur trois lignes.
# cat .ssh/id_rsa.pub \
| ssh root@192.168.1.1 \
"cat >> /root/.ssh/authorized_keys2"

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

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

'''''Vérification de la connexion'''''

On vérifie la connexion <code>ssh</code> sans port et sans mot de passe.
# ssh root@192.168.1.1

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

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

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

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

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

<nowiki>****************************************************</nowiki>
[root@sme-9 ~]#

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

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

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

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

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

'''''hookScript'''''

Activation du script qui s'occupe de récupérer le certificat Let's Encrypt pour un serveur inttranet.
# config setprop letsencrypt hookScript enabled

'''''host'''''

On indique l'adresse IP de la passerelle.
# config setprop letsencrypt host 192.168.1.1

'''''user'''''

L'usager qui récupérera le certificat.
# config setprop letsencrypt user root

'''''path'''''

Le chemin du répertoire de stockage des défis sur le serveur passerelle.
# config setprop letsencrypt path /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge

On signale les changements ''(peut prendre plusieurs secondes)''.
# signal-event console-save

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

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

=== Choix des domaines et des hôtes ===
On affiche les nom d'hôtes sur notre Serveur SME.
# db hosts show | grep .com

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

[[Image:SME-101.04-046-DomaineEtHotes.png|top|right|450px|border]]
[[Image:Icone-AsurveillerAPT.png|25px]]  Si certains de vos défis sont renvoyés sans erreur, mais que certains échouent, il est possible que vous n'ayez pas d'enregistrements DNS A, MX ou CNAME pour tous les noms d'hôtes que vous avez ajoutés à votre certificat. Lorsque Let's Encrypt lance les défis pour une liste de noms d'hôtes et qu'un de ceux-ci ne répond pas, le défi échoue et le certificat n'est pas généré.

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

Si on veut obtenir un certificat pour tous all les domaines et tous les noms d'hôtes.
{| class="wikitable" style="width: 80%; background-color:#FFEED9;"
|- style="vertical-align:top;font-family: Courier New;"
|
<nowiki>#</nowiki> config setprop letsencrypt configure all
|}

[[Image:Icone-NoteAPT.png|25px]]  La commande <code>config setprop letsencrypt configure all</code> est susceptible de provoquer une erreur de défi.

[[Image:Icone-AsurveillerAPT.png|25px]]  Nous voulons tous les noms d'hôtes affichés avec la commande <code>db hosts show | grep .org</code> sauf celui du nom du serveur: '''dev'''.micronator-101.com car, ce dernier ne répond pas au défis de Let's Encrypt.

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

'''Domaines'''

On inclut micronator-101.com.
# db domains setprop micronator-101.com letsencryptSSLcert enabled

On vérifie.
# db domains show

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

'''Hôtes'''

On inclut tous les hôtes suivants.

On inclut tous les hôtes suivants.

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

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

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

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

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

=== Autres propriétés de configuration ===

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

'''Ajout d'une adresse courriel'''

Le '''domaine''' de messagerie spécifié n'a nul besoin de correspondre à l'un des domaines pour lesquels vous demandez un certificat.
# config setprop letsencrypt email admin@'''micronator.org'''

'''Longueur de la clé privée'''

Si vous ne voulez pas la valeur par défaut de 4096 bits, vous pouvez définir la longueur de la clé privée de votre certificat,. Ceci ne devrait pas être nécessaire dans la plupart des cas mais; si vous le souhaitiez, il faudrait utiliser la commande ci-dessous pour ce faire.
{| class="wikitable" style="width: 80%; background-color:#FFEED9;"
|- style="vertical-align:top;font-family: Courier New;"
|
<nowiki>#</nowiki> config setprop letsencrypt keysize LONGUEUR-EN-BITS
|}

=== Termes et conditions ===

[[Image:Icone-AsurveillerAPT.png|25px]]  Veuillez d'abord lire les conditions d'utilisation de Let's Encrypt: https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf.

[[Image:Icone-AsurveillerAPT.png|25px]]  Si vous acceptez les termes et conditions de Let's Encrypt, lancez la commande ci-dessous.
# config setprop letsencrypt ACCEPT_TERMS yes

=== Activation du mode TEST ===

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

On active le mode TEST.
# config setprop letsencrypt status test

On signale les changements. ''(Peut prendre plusieurs secondes.)''
# signal-event console-save

=== Vérification ===
On vérifie si on est bien en mode TEST.
# cat /etc/dehydrated/config | grep CA

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

On vérifie l'adresse courriel.
# cat /etc/dehydrated/config | grep CONTACT

CONTACT_EMAIL=admin@'''micronator.org'''

On vérifie les domaines et les hôtes.
# cat /etc/dehydrated/domains.txt

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

[[Image:Icone-SeTirerDembarrasAPT.png|20px]]  Tout le contenu du fichier <code>domains.txt</code> doit être entièrement sur une seule ligne sinon, vous aurez autant de certificats que de lignes et vous atteindrez la limite 5/7 de Let's Encrypt.

[[Image:Icone-AstuceAPT.png|25px]]  Le certificat sera émis au nom du premier domaine de la ligne; ici, ce sera micronator-101.com.

=== Lancement du script dehydrated ===

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

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

'''ERREUR'''

[[Image:Icone-SeTirerDembarrasAPT.png|20px]]  Si vous recevez l'erreur ci-dessous, simplement relancer la demande. Il se peut que vous ayez à le faire plusieurs fois.

{| class="wikitable" style="width: 80%; background-color:#FFEED9;"
|- style="vertical-align:top;font-family: Courier New;"
|
<nowiki>#</nowiki> '''dehydrated -c''' 
<nowiki> </nowiki> 
<nowiki># INFO: Using main config file /etc/dehydrated/config</nowiki> 
<nowiki>ERROR: Problem connecting to server (get for https://acme-v01.api.letsencrypt.org/directory; curl returned with 6)</nowiki>
|}

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

{| class="wikitable" style="width: 80%; background-color:#FFEED9;"
|- style="vertical-align:top;font-family: Courier New;"
|
<nowiki>...</nowiki> 
<nowiki>+ Requesting challenge for micronator-101.com...</nowiki> 
<nowiki>ERROR: Problem connecting to server (post for https://acme-v01.api.api.letsencrypt.org/acme/new-authz; curl returned with 35)</nowiki> 
<nowiki>...</nowiki>
|}

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

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

{| class="wikitable" style="width: 80%; background-color:#FFEED9;"
|- style="vertical-align:top;font-family: Courier New;"
|
<nowiki>#</nowiki> '''date;time curl -s4 https://acme-v01.api.letsencrypt.org/acme/new-authz >/dev/null''' 
<nowiki>  </nowiki> 
<nowiki>jeu. oct. 4 09:48:54 EDT 2018</nowiki> 
<nowiki>  </nowiki> 
<nowiki>real 0m5.264s</nowiki> 
<nowiki>user 0m0.058s</nowiki> 
<nowiki>sys 0m0.046s</nowiki>
|}

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

{| class="wikitable" style="width: 80%; background-color:#FFEED9;"
|- style="vertical-align:top;font-family: Courier New;"
|
<nowiki>#</nowiki> '''date;time curl -s6 https://acme-v01.api.letsencrypt.org/acme/new-authz >/dev/null''' 
<nowiki>  </nowiki> 
<nowiki>jeu. oct. 4 09:52:35 EDT 2018</nowiki> 
<nowiki>  </nowiki> 
<nowiki>real 0m47.367s</nowiki> 
<nowiki>user 0m0.061s</nowiki> 
<nowiki>sys 0m0.042s</nowiki>
|}

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

{| class="wikitable" style="width: 80%; background-color:#FFEED9;"
|- style="vertical-align:top;font-family: Courier New;"
|
<nowiki>#</nowiki> '''date;time curl -s4 https:https://acme-v01.api.letsencrypt.org/acme/new-authz >/dev/null''' 
<nowiki> </nowiki> 
<nowiki>jeu. oct. 4 09:53:29 EDT 2018</nowiki> 
<nowiki> </nowiki> 
<nowiki>real 0m0.004s</nowiki> 
<nowiki>user 0m0.002s</nowiki> 
<nowiki>sys 0m0.000s</nowiki> 
|}

=== Vérification du certificat ===

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

[[Image:Icone-NoteAPT.png|25px]]  Avec un Serveur SME branché directement à l'Internet, on peut utiliser le FQDN du domaine mais, nous somme sur un réseau LOCAL.

'''Fichier hosts'''

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

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

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

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

[[Image:Icone-AstuceAPT.png|25px]]  Pour "simuler" un serveur DNS, on peut faire des entrées dans le fichier <code>hosts</code> de la station de travail et y indiquer l'adresse IP de notre Serveur SME local.

[[Image:SME-101.04-047-FichierHost-A.png|top|right|450px|border]]
Sur une station Windows, le fichier hosts se trouve dans le répertoire:

<code>C:\Windows\System32\drivers\etc\</code>.

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

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

[[Image:Icone-NoteAPT.png|25px]]  Pour une station Linux, le fichier hosts réside dans le répertoire <code>/etc</code>.
 
 
On édite le fichier <code>hosts</code> et on entre les noms et l'adresse IP de notre Serveur SME intranet après les lignes <code>localhost</code>.

...
<nowiki># localhost name resolution is handled within DNS itself.</nowiki>
<nowiki>#</nowiki> 127.0.0.1 localhost
<nowiki>#</nowiki> ::1 localhost

# Serveur SME sur le réseau local

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

[[Image:SME-101.04-048-FichierHost-B.png|top|right|450px|border]]
[[Image:Icone-AsurveillerAPT.png|25px]]  On remet le fichier en Lecture seule.
 
'''''Vidange du cache DNS'''''

Sur la station de travail, on ouvre un écran de commande et on vide le cache DNS de la station.
C:\Users\michelandre> '''ipconfig /flushdns'''

Configuration IP de Windows

Cache de résolution DNS vidé.

C:\Users\michelandre>


{| style="float: right; margin-left:0.5em ;margin-right:40px;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-050-FichierHost-D.png|400px|border]]
|}
{| style="float: right; margin-left:0.5em; margin-right:0.5em;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-049-FichierHost-C.png|400px|border]]
|}
'''''Vidange de l'historique'''''

[[Image:Icone-SeTirerDembarrasAPT.png|20px]]  On vidange l'historique de notre navigateur.
 


=== Vérification du certificat ===

[[Image:Icone-AsurveillerAPT.png|25px]]  Il faut autoriser java script et les témoins dans notre fureteur.

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

Avec Firefox, on se connecte au gestionnaire Server Manager.  [[Image:SME-101.04-051-FichierHost-E.png|middle|400px|border]]
 


{| style="float: right; margin-left:0.5em ;margin-right:40px;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-054-FichierHost-H.png|275px|border]]
|}
{| style="float: right; margin-left:0.5em; margin-right:0.5em;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-053-FichierHost-G.png|275px|border]]
|}
{| style="float: right; margin-left:0.5em; margin-right:0.5em;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-052-FichierHost-F.png|275px|border]]
|}
* Après avoir accepté le certificat, on clique le ''cadenas'' puis, l'icône ">". 
* ''Plus d'informations''.
* ''Afficher le certificat''.
 



{| style="float: right; margin-left:0.5em ;margin-right:40px;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-057-FichierHost-K.png|275px|border]]
|}
{| style="float: right; margin-left:0.5em; margin-right:0.5em;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-056-FichierHost-J.png|275px|border]]
|}
{| style="float: right; margin-left:0.5em; margin-right:0.5em;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-055-FichierHost-I.png|275px|border]]
|}
* - Certificat de test car, émis par "Fake LE Intermediate XI". - ''Détails''.
* - ''Nom alternatif du sujet du certificat''. - Nos noms d'hôtes sont présents.
* - ''Pas après''. Valide pour 90 jours. - ''Fermer''.
 


=== Mode Production ===

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

Activation du mode Production.
# config setprop letsencrypt status enabled

On signale les changements. ''(Peut prendre plusieurs secondes.)''
# signal-event console-save

On vérifie.
# cat /etc/dehydrated/config | grep CA

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

'''Demande d'un certificat officiel'''

On fait la demande d'un certificat officiel. Le paramètre <code>-x</code> est nécessaire pour forcer un nouveau certificat
# dehydrated -c -x

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

[[Image:Icone-SeTirerDembarrasAPT.png|20px]]  Si vous recevez l'erreur ci-dessous, simplement relancer la demande. Il se peut que vous ayez à le faire plusieurs fois.

{| class="wikitable" style="width: 80%; background-color:#FFEED9;"
|- style="vertical-align:top;font-family: Courier New;"
|
<nowiki>#</nowiki> '''dehydrated -c''' 
<nowiki> </nowiki> 
<nowiki># INFO: Using main config file /etc/dehydrated/config</nowiki> 
<nowiki>ERROR: Problem connecting to server (get for https://acme-v01.api.letsencrypt.org/directory; curl returned with 6)</nowiki>
|}

=== Vérification du certificat ===

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


{| style="float: right; margin-left:0.5em ;margin-right:40px;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-060-VerifLocal-C.png|275px|border]]
|}
{| style="float: right; margin-left:0.5em; margin-right:0.5em;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-059-VerifLocal-B.png|275px|border]]
|}
{| style="float: right; margin-left:0.5em; margin-right:0.5em;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-058-VerifLocal-A.png|275px|border]]
|}
* Le cadenas est '''vert'''.
* Émis par: "Let's Encrypt Authority X3".
* Tous les noms d'hôtes sont présents   >   ''Fermer''.
 


= Sauvegarde du répertoire /etc/dehydrated =

Le répertoire <code>/etc</code> et ses sous-répertoires ne sont pas tous inclus dans la sauvegarde standard.

Nous allons créer un gabarit personnalisé pour inclure, dans la sauvegarde standard, le répertoire <code>/etc/dehydrated</code>.

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

=== Création du gabarit personnalisé ===

On crée le répertoire pour le gabarit personnalisé.
# mkdir -p /etc/e-smith/templates-custom/etc/dar/DailyBackup.dcf

On sécurise.
# chmod 600 /etc/e-smith/templates-custom/etc/dar/DailyBackup.dcf

On vérifie.
# ls -lsd /etc/e-smith/templates-custom/etc/dar/DailyBackup.dcf

4 drw------- 2 root root 4096 2 mars 21:50 /etc/e-smith/templates-custom/etc/dar/DailyBackup.dcf

On crée le fichier <code>41go-into</code> et on y insère son contenu pour indiquer d'inclure le répertoire <code>/etc/dehydrated</code> et les scripts s'y rapportant.

[[Image:Icone-AsurveillerAPT.png|25px]]  Prendre tout le contenu de l'encadré pour la commande.

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

EOT

[[Image:Icone-AsurveillerAPT.png|25px]]  Il n'y a pas de caractère "/" avant au début des chemins.

[[Image:Icone-SeTirerDembarrasAPT.png|20px]]  Contrairement à ce qui est décrit dans la Contrib, il faut aussi utiliser <code>--go-into</code> pour les fichiers.

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

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

On développe le gabarit personnalisé.
# expand-template /etc/dar/DailyBackup.dcf

On vérifie que le fichier <code>41go-into</code> a bien été incorporé dans <code>DailyBackup.dcf</code>.
# cat /etc/dar/DailyBackup.dcf | grep dehydrated

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

=== Vérification ===

Le lendemain de ces procédures, avec [https://www.micronator.org/?page_id=97 VirtualBox], nous avons créé un serveur virtuel et nous y avons restauré la sauvegarde de la nuit précédente.
# date

ven. mars 3 15:59:53 EST 2017

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

...
Restoring file's data: /etc/dehydrated/certs
Restoring file's data: /etc/dehydrated/certs/micronator-101.com
...
Restoring file's data: /etc/dehydrated/certs/micronator-101.com/privkey-1488421520.pem
Restoring file's data: /etc/dehydrated/certs/micronator-101.com/privkey-1488505534.pem
Restoring file's data: /etc/dehydrated/certs/micronator-101.com/privkey.pem
Restoring file's data: /etc/dehydrated/certs/micronator-101.com/fullchain.pem
Restoring file's data: /etc/dehydrated/certs/micronator-101.com/cert-1488421520.csr
Restoring file's data: /etc/dehydrated/certs/micronator-101.com/cert-1488421520.pem
Restoring file's data: /etc/dehydrated/certs/micronator-101.com/chain-1488463899.pem
Restoring file's data: /etc/dehydrated/domains.txt
Restoring file's data: /etc/dehydrated/config
...
Restoring file's data: /etc/e-smith/templates-custom/etc/dar/DailyBackup.dcf
Restoring file's data: /etc/e-smith/templates-custom/etc/dar/DailyBackup.dcf/41go-into
...

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

'''Gabarit personnalisé httpd.conf'''

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

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

À la console du nouveau serveur virtuel restauré, on affiche le répertoire de ce gabarit pour vérifier s'il a été restauré.
# ls -ls /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf

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

[[Image:Icone-NoteAPT.png|25px]]  Le gabarit personnalisé <code>httpd.conf</code> a été sauvegardé et restauré car, il faisait partie des répertoires de la sauvegarde standard du Serveurs SME.


= Certificat standard SME =

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

=== Login ===

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

On vérifie.
# pwd

/root

=== Création d'un répertoire de sauvegarde ===

On crée un répertoire de sauvegarde.
# mkdir dehydrated

On vérifie.
# ls -alsd dehydrated/

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

On se rend dans le répertoire de sauvegarde.
# cd dehydrated/

On vérifie.
# pwd

/root/dehydrated


=== Sauvegarde des fichiers du certificat actuel ===

Recherche des chemins des fichiers du certificat présentement actif.
# cat /etc/httpd/conf/httpd.conf | grep SSLCertificate

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

On sauvegarde le fichier de la chaîne de certification.
# cp /etc/dehydrated/certs/micronator-101.com /chain.pem .

On sauvegarde le fichier du certificat.
# cp /etc/dehydrated/certs/micronator-101.com /cert.pem .

On sauvegarde le fichier de la clé privée.
# cp /etc/dehydrated/certs/micronator-101.com /privkey.pem .

On vérifie le fichier <code>pem</code>.
# ls -ls /home/e-smith/ssl.pem/

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

On sauvegarde le fichier <code>pem</code>.
# cp /home/e-smith/ssl.pem/sme-9.micronator-101.com.pem .

On vérifie les sauvegardes.
ls -ls

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

=== Suppression de certaines propriétés de modSSL ===

On affiche les propriétés de <code>modSSL</code>.
# config show modSSL

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

On supprime la propriété <code>CertificateChainFile</code>.
# config delprop modSSL CertificateChainFile

On supprime la propriété <code>crt</code>.
# config delprop modSSL crt

On supprime la propriété <code>key</code>.
# config delprop modSSL key

On vérifie les propriétés de <code>modSSL</code>.
# config show modSSL

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

'''Paramètres de tous les anciens certificats standards'''

[[Image:Icone-AsurveillerAPT.png|25px]]  On utilise la très dangereuse commande <code>rm -rf</code> pour supprimer tous les anciens: .crt, .key et .pem du Serveur SME.

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

On vérifie.
# ls -als /home/e-smith/ssl.crt/

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

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

On vérifie.
# ls -als /home/e-smith/ssl.key/

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

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

On vérifie.
# ls -als /home/e-smith/ssl.pem/

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

=== Signalisation des changements ===

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

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

[[Image:Icone-NoteAPT.png|25px]]  Sans réamorçage, le serveur ne prendra que quelques secondes pour effectuer les modifications nécessaires.
{| class="wikitable" style="width: 80%; background-color:#FFEED9;"
|- style="vertical-align:top;font-family: Courier New;"
|
<nowiki>#</nowiki> signal-event domain-modify ; signal-event email-update ; signal-event ibay-modify
|}

* Si on veut réamorcer, on applique les changements en signalant une mise à jour et un réamorçage.
# signal-event post-upgrade ; signal-event reboot

[[Image:SME-101.04-061-CertSME-A.png|top|right|400px|border]]
Si on choisit le bloc de commandes avec réamorçage, la commande <code>signal-event post-upgrade</code> mettra à jour les paramètres de configuration de modSSL, le serveur réamorcera pour activer tous les nouveaux paramètres et prendra environ une minute pour redevenir actif.
 
=== Vérification ===

'''Console du serveur'''

On affiche la date.
# date

ven. mars 3 18:30:02 EST 2017

Fichier <code>pem</code>.
# ls -ls /home/e-smith/ssl.pem/

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

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

'''Navigateur Web'''


{| style="float: right; margin-left:0.5em ;margin-right:200px;"
|-
| style="vertical-align: top;" |[[Image:SME-101.04-062-CertSME-B.png|400px|border]]
|}
On se rend au site: '''https://micronator-101.com'''.

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

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

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

Fermer toutes les fenêtres.

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


[[Image:Odoo-11-BanniereDeLaVictoire-APT.png|caption|36px]]  Victoire totale, hissons la bannière de la victoire.
 
 

----
<references/>

[[Category:Howto]] [[Category:Howto/fr]]

Michelandre

2,785

edits

Retrieved from "https://wiki.koozali.org/Special:MobileDiff/35878"

Changes

SME-101.04 Certificat Let's Encrypt (view source)

Revision as of 03:27, 7 October 2018

Navigation menu

Page actions

Page actions

Personal tools

Koozali SME Server

Recent activities

Koozali resources

Koozali SME Server wiki

Tools

Search