2,785
edits
Changes
From SME Server
Jump to navigationJump to searchRC-001
<!--__NOTOC__ -->
__TOC__
= Description générale =
Cette marche à suivre fait suite à celle sur SME-9.2 & Odoo-11 ''(https://wiki.contribs.org/Odoo-11)'' et décrit les étapes pour assurer une connexion sécuritaire à Odoo-11 roulant sur un Serveur SME.
<span style="font-size:125%">'''But final'''</span>
[[Image:odoo-11-HTTPS-001-ButFinal.png|top|right|700px]]
Pour le présent document, sur le serveur <span style="color:red">odoo-11.</span><span style="color:blue">micronator-101.org</span>, nous avons installé Fail2ban et suivi les mêmes procédures qu'auparavant pour une nouvelle installation d'Odoo-11.
[[Image:Icone-NoteAPT.png|25px]] Ce nouveau serveur est configuré en mode '''''Serveur et passerelle'''''.
L'installation de SME-9.2 sur le serveur branché directement à l'Internet est exactement telle que décrite dans les cahiers 2 et 3 du cours Micronator-101.
https://www.micronator.org/affaires/produit/micronator-101-cahier-2installation-dun-serveur-sme/.
https://www.micronator.org/affaires/produit/micronator-101-cahier-3adslvdsl-dns-dynamique-domaine-fqdn/.
L'installation de Fail2ban est décrite dans à la page: https://www.micronator.org/affaires/produit/sme-9-x8-x-fail2ban/.
L'installation du serveur BackupPC provient de: ''Micronator-101, Supplément: SME & BackupPC'': https://www.micronator.org/affaires/produit/micronator-101-supplementsme-backuppc/
= 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 ''(à l'aide de sa clé privée)'' peut décoder, garantissant la confidentialité du contenu.
'''Chiffrement'''
L'un des rôles de la clé publique est de permettre le chiffrement; c'est donc cette clé qu'utilisera Bob pour envoyer des messages chiffrés à Alice. L'autre clé — l'information secrète — sert à déchiffrer. Ainsi, Alice, et elle seule, peut prendre connaissance des messages de Bob. <u>La connaissance d'une clé ne permet pas de déduire l'autre</u>.
'''É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 ou "checksum" en anglais, 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:odoo-11-HTTPS-002-HommeDuMilieu.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 à l'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 HdM 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.
* '''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 par Domaine ''(DV)'''''
''Référence'': [https://www.leaderssl.fr/articles/236-la-diff-rence-entre-les-certificats-dv-et-ov https://www.leaderssl.fr/articles/236-la-diff-rence-entre-les-certificats-dv-et-ov].
Certificats DV ''(Domain Validation ou validation par domaine)'': la validation par domaine est le niveau le plus élémentaire de la validation SSL. L’autorité de certification ''(CA)'' vérifie uniquement que vous êtes bien le propriétaire d’un domaine donné à l’aide des informations figurant dans la base de données WHOIS. Ce type de certificat assure bien entendu le chiffrement des données sur votre site mais, il ne vérifie pas que vous êtes le propriétaire d’une entreprise légitime. Il apporte néanmoins une preuve de légitimité, et surtout, il vous permet de protéger très rapidement votre site en utilisant le protocole HTTPS. Les clients qui verront le cadenas dans leur navigateur auront davantage confiance dans votre site parce que le cadenas est une preuve de légitimité reconnue.
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. Le propriétaire ou le webmestre du nom de domaine doit confirmer la requête par courriel.
* ''Avantages'': Un certificat SSL DV est facile à obtenir. Vous obtenez ce certificat en quelques minutes.
* ''À 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'<u>identité du propriétaire du site Internet</u>.
* ''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 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:
<nowiki> </nowiki>'''*''' www.macompagnie.com
<nowiki> </nowiki>'''*''' mail.macompagnie.com
<nowiki> </nowiki>'''*''' macompagnie.com
<nowiki> </nowiki>'''*''' www.toto.net
<nowiki> </nowiki>'''*''' mail.toto.net
<nowiki> </nowiki>'''*''' 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 ''(<u>un astérisque et un point</u> 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/]. ''(Ce lien n'est plus valide.)''
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'enregistrements 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 pointant vers cet enregistrement suivent automatiquement la nouvelle adresse 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 augmentent 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.domain.com'' ou soit ''domain.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))''.
[[Image:odoo-11-HTTPS-003-CNAME-Coquille.png|top|right|300px|border]]
* '''Exemple'''
Vous avez un site Web avec le nom de domaine ''monsite.quebec''. Ce nom de domaine est connecté à un enregistrement A qui traduit le nom de domaine à l'adresse IP appropriée, par exemple: 11.22.33.44.
Vous avez aussi plusieurs sous-domaines, comme ''coquille.monsite.quebec'', ''email.monsite.quebec'', etc... et vous souhaitez que ces sous-domaines pointent à votre nom de domaine principal ''monsite.quebec''. Au lieu de créer des enregistrements A pour chaque sous-domaine et les lier à l'adresse IP de votre domaine principal, vous créez un alias ''(enregistrement CNAME)'' pour chacun d'eux pour obtenir la figure ci-contre. Dans le cas où votre adresse IP change, vous devez seulement éditer un enregistrement A et tous les sous-domaines suivent automatiquement du fait des CNAME pointant vers le domaine principal.
[[Image:Icone-AstuceAPT.png|25px]] Si nous avons un domaine intranet ''(sur le réseau LOCAL)'' qui fait partie du domaine principal et dont le nom est ''coquille.monsite.quebec'', nous pouvons alors insérer un CNAME ''coquille'' pour ce domaine.
= L'autorité de certification 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 <code>dehydrated</code> et sur l'automatisation qu'il propose.
Le client <code>dehydrated</code> 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 <code>dehydrated</code>:
* 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 <code>dehydrated</code> 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 ou Nginx, pour l'instant)''.
Le client <code>dehydrated</code> 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 <code>dehydrated</code>.
=== Courriel 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 <code>dehydrated</code>.
=== 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 ===
''Référence'': [https://letsencrypt.org/docs/rate-limits/ https://letsencrypt.org/docs/rate-limits/].
* '''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-03-12:
* Limite de 5 certificats par domaine, dans une fenêtre de 7 jours.
* Limite de 5 échecs de validation par compte, par nom d'hôte et par heure. Cette limite est plus élevée dans l'environnement de test
<nowiki></nowiki>'''*''' Certificats par domaine signifie 5 émissions de certificat et non pas combien de domaines au sein d'un certificat multi-domaines SAN.
<nowiki></nowiki>'''**''' Un certificat multi-domaines SAN ayant ''domaine1.com'', ''www.domaine1.com'', ''domaine2.com'', ''www.domaine2.com'', ''toto.info'' et ''titi.org'' est compté comme 1 certificat mais, on ne peut renouveler ce certificat multi-domaines plus de 5 fois par période de 7 jours?
<nowiki></nowiki>'''***''' Il n'y a pas de limites pour le nombre de domaines contenus dans un certificat multi-domaines SAN ou, plus précisément, jusqu'au maximum standard de 100. Let's Encrypt a choisi cette limite de 100 sur une base de prudence car, il semble que lorsqu'on en obtient plus de 100, certains navigateurs Web ont un comportement erratique. Let's Encrypt peut probablement augmenter cette limite si quelqu'un en fait la demande.
=== Mode Officiel vs TEST ''(staging''<ref name="ftn1">
'''Staging''' Un site Staging, dans la conception de sites Web, est un site utilisé pour assembler, tester et revoir une version plus récente avant de l'implanter en production. ''Référence'': https://en.wikipedia.org/wiki/Staging_site. </ref>'')'' ===
Lorsqu'on veut tester <code>dehydrated</code>, c'est l'option staging ''(défini par la ligne <code>CA="https://acme-staging.api.letsencrypt.org/directory"</code>)'' qui est utilisée dans le fichier de configuration <code>config</code>.
Le principal avantage de ce mode 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 <code>dehydrated</code> utilise la CA officielle, <code>Let’s Encrypt Authority X3</code>.
* '''''CA de TEST'''''
Un certificat de test ne sera pas signé directement par Let's Encrypt mais par sa CA de tests, <code>Fake LE Intermediate X1</code>. 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 <code>Fake LE Intermediate X1</code>.
[[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 ne spécifie pas la CA à utiliser car, par défaut, le client dehydrated utilise la CA officielle <code>Let’s Encrypt Authority X3</code>.
[[Image:Icone-NoteAPT.png|25px]] Toutefois, la contribution Let's Encrypt insère quand même, dans le fichier de configuration, la ligne:
{| class="wikitable" style="width: 80%; background-color:#FFEED9;"
|- style="vertical-align:top;font-family: Courier New;"
|CA="https://<span style="color:red">acme-v01</span>.api.letsencrypt.org/directory"
|}
[[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 Production.
{| class="wikitable" style="width: 80%; background-color:#FFEED9;"
|- style="vertical-align:top;font-family: Courier New;"
|#!/bin/bash<br>
WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"<br>
CA="https://<span style="color:red">acme-v01</span>.api.letsencrypt.org/directory"<br>
BASEDIR="/etc/dehydrated"<br>
CONTACT_EMAIL=admin@micronator.org<br>
HOOK="/usr/bin/hook-script.sh"<br><br>
PARAM_ACCEPT_TERMS="yes"
|}
* '''''Certificat de TEST'''''
Le fichier de configuration pour une demande certificat de test doit spécifier la CA <code><span style="color:red">acme-staging</span></code> qui seule, émet ces certificats de test pour Let's Encrypt.
{| class="wikitable" style="width: 80%; background-color:#FFEED9;"
|- style="vertical-align:top;font-family: Courier New;"
|#!/bin/bash<br>
WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"<br>
CA="https://<span style="color:red">acme-staging</span>.api.letsencrypt.org/directory"<br>
BASEDIR="/etc/dehydrated"<br>
CONTACT_EMAIL=admin@micronator.org<br>
HOOK="/usr/bin/hook-script.sh"<br><br>
PARAM_ACCEPT_TERMS="yes"
|}
=== Clé de compte Let's Encrypt ===
[[Image:Icone-NoteAPT.png|25px]] La clé de compte <code>privkey-1234567890.pem</code> 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>.
Contenu du répertoire <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 de certificat de TEST et celui de la clé de compte OFFICIEL est créé lors de la première demande de certificat OFFICIEL.
* Le sous-répertoire et la clé utilisée dépendent de la ligne <code>CA="https://acme...</code> dans le fichier de configuration <code>/etc/dehydrated/config</code>.
La clé de compte est utilisée exclusivement par le client <code>dehydrated</code> 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 une demande pour un certificat de TEST ou OFFICIEL, la clé de compte est toujours appelé <code>account_key.pem</code>.
[[Image:Icone-NoteAPT.png|25px]] Une clé SSL/TLS est toujours constituée d'une partie publique et d'une partie privée.
=== Aide ===
Pour afficher l'aide du client <code>dehydrated</code>.
# /usr/bin/dehydrated <span style="color:red">--help</span>
=== 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|Certificat standard SME]].
= Préparation du serveur =
=== Ajout d'un nouveau domaine ===
[[Image:odoo-11-HTTPS-000-NouveauDom.png|top|right|200px]]
Si nous redirigeons tous les accès de notre <u>serveur</u> <span style="color:red">odoo-11.</span><span style="color:blue">micronator-101.org</span> vers le port 8069 à l'aide d'un Gabarit personnalisé, le gestionnaire Server Manager sera lui aussi redirigé vers le port 8069 et il générera alors une erreur de connexion. C'est pour cette raison que nous allons créer le <u>domaine</u> <span style="color:blue"><span style="color:Blue">odoo.</span>micronator-101.org</span> et rediriger tous les accès ''(http et https)'', <u>pour ce domaine seulement</u>, en forçant une connexion sécurisée vers le port 8069.
[[Image:Icone-NoteAPT.png|25px]] On utilise <span style="color:Blue">odoo</span> pour le domaine et <span style="color:red">odoo-11</span> pour le serveur.
<br>
<br>
<br>
'''Création du domaine'''
<center>
{| class="wikitable" style="width: 80%; background-color:#ffffff;"
|- style="vertical-align:bottom;font-family: Courier New;text-align: left;"
|Server Manager > Domaines > Ajouter un domaine.
||<nowiki>-</nowiki> Entrer les informations telles que ci-dessous.
<nowiki>-</nowiki> Ajouter.
||On s'assure du succès de l'opération.
|- style="vertical-align:top;"
|[[Image:odoo-11-HTTPS-004-CreationDomaine.png|center|top|350px|border]]
||[[Image:odoo-11-HTTPS-005-CreationDomaine.png|center|top|350px|border]]
||[[Image:odoo-11-HTTPS-006-CreationDomaine.png|center|top|350px|border]]
|}
</center>
'''CNAME'''
[[Image:odoo-11-HTTPS-007-AjoutCNAME.png|top|right|350px|border]]
Nous avons créer un nouveau domaine, nous ajoutons donc les CNAME suivants chez le régistraire de notre domaine <span style="color:blue">micronator-101.org</span>: <code>odoo</code> , <code>ftp.odoo</code> , <code>mail.odoo</code> , <code>proxy.odoo</code> , <code>wpad.odoo</code> et <code>www.odoo</code>.
<br>
<br>
<br>
<br>
=== Fichier index de l'i-bay Primary ===
[[Image:odoo-11-HTTPS-008-PageDeLaSociete.png|top|right|350px|border]]
Vu que nous allons réglé la redirection, celle dans le fichier <code>index.html</code> dans l'i-bay Primary ne sera plus nécessaire et nous pouvons remplacer le contenu de ce fichier par une texte en HTML décrivant notre organisation et qui sera affiché lors d'une visite à la page: http://www.micronator-101.org ou https://www.micronator-101.org.
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
= 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 reconnue mondialement. Les usagers pourront utiliser http<u><span style="color:red">s</span></u> et, vu que le certificat a été émis par une autorité de certification reconnue, le cadenas sera <u><span style="color:DarkGreen">vert</span></u>.
Cette section est inspirée de la contribution Letsencrypt produite par: DanB35, Unnilennium, Mdo, Mercyh, RayMitchell et Gieres à l'URL: [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 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 contribution <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é:
<span style="color:red">smeserver-letsencrypt</span>.noarch 0:0.4-4
Dépendance(s) installée(s) :
<span style="color:red">dehydrated</span>.noarch 0:0.5.0-3.el6.sme
Terminé !
==============================================================
WARNING: You now need to run BOTH of the following commands
to ensure consistent system state:
<span style="color:red">signal-event post-upgrade; signal-event reboot</span>
You should run these commands unless you are certain that
yum made no changes to your system.
==============================================================
On signale les changements.
# signal-event post-upgrade ; signal-event reboot
[[Image:Icone-AsurveillerAPT.png|25px]] Ne pas signaler les changements pourrait empêcher la contribution de fonctionner correctement et vos certificats ne seront pas renouvelés.
=== Mise à jour de la Contrib ===
Vous devez manuellement mettre à jour la Contrib i.e. smeserver-letsencrypt et dehydrated en utilisant la commande ci-dessous.
{| class="wikitable" style="width: 80%; background-color:#FFEED9;"
|- style="vertical-align:top;font-family: Courier New;"
| # yum update -y --enablerepo=smecontribs smeserver-letsencrypt dehydrated<br><br>
Modules complémentaires chargés : fastestmirror, smeserver<br>
Configuration du processus de mise à jour<br>
Loading mirror speeds from cached hostfile<br>
<nowiki>*</nowiki> base: centos.ca-west.mirror.fullhost.io<br>
<nowiki>*</nowiki> smeaddons: mirror.canada.pialasse.com<br>
<nowiki>*</nowiki> smecontribs: mirror.canada.pialasse.com<br>
<nowiki>*</nowiki> smeextras: mirror.canada.pialasse.com<br>
<nowiki>*</nowiki> smeos: mirror.canada.pialasse.com<br>
<nowiki>*</nowiki> smeupdates: mirror.canada.pialasse.com<br>
<nowiki>*</nowiki> updates: centos.mirror.vexxhost.com<br>
<span style="color:red">Aucun paquet marqué pour mise à jour</span>
|}
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.
{| class="wikitable" style="width: 80%; background-color:#FFEED9;"
|- style="vertical-align:top;font-family: Courier New;"
|<nowiki>#</nowiki> signal-event post-upgrade ; signal-event reboot
|}
=== Choix des domaines et des hôtes ===
On affiche les nom d'hôtes sur notre Serveur SME.
# db hosts show | grep .org
<span style="color:red">ftp</span>.micronator-101.org=host
ftp.odoo.micronator-101.org=host
<span style="color:red">mail</span>.micronator-101.org=host
mail.<span style="color:DarkMagenta">odoo</span>.micronator-101.org=host
<span style="color:DarkGreen">odoo-11.micronator-101.org=host</span>
<span style="color:DarkGreen">odoo-11.odoo.micronator-101.org=host</span>
<span style="color:red">proxy</span>.micronator-101.org=host
proxy.<span style="color:DarkMagenta">odoo</span>.micronator-101.org=host
<span style="color:red">wpad</span>.micronator-101.org=host
wpad.<span style="color:DarkMagenta">odoo</span>.micronator-101.org=host
<span style="color:red">www</span>.micronator-101.org=host
www.<span style="color:DarkMagenta">odoo</span>.micronator-101.org=host
[[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é.
[[Image:odoo-11-HTTPS-007-AjoutCNAME.png|top|right|500px|border]]
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é.
Ci-contre, les noms d'hôtes pour le "sous-domaine" <span style="color:blue">odoo.micronator-101.org</span> chez le régistraire du domaine <span style="color:blue">micronator-101.org</span>.
<br>
<br>
<br>
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 <span style="color:red">all</span>
|}
[[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 par la commande <code>db hosts show | grep .org</code>, <u>sauf ceux des noms des serveurs</u>: <span style="color:DarkGreen">odoo-11.micronator-101.org</span> et <span style="color:DarkGreen">odoo-11.odoo.micronator-101.org</span> car, ces derniers ne répondront pas au défis de Let's Encrypt.
Pour utiliser des hôtes ou des domaines activés individuellement, on active le paramètre <code>configure</code> à <code>none</code> et ensuite on ajoute les domaines et les noms d'hôtes désirés.
# config setprop letsencrypt configure <span style="color:red">none</span>
'''Domaines'''
On inclut <span style="color:blue">micronator-101.org</span>.
# db domains setprop micronator-101.org letsencryptSSLcert enabled
On inclut <span style="color:blue">odoo.micronator-101.org</span>.
# db domains setprop odoo.micronator-101.org letsencryptSSLcert enabled
On vérifie.
# db domains show
<span style="color:blue">micronator-101.org</span>=domain
Content=Primary
Description=Primary domain
Nameservers=localhost
Removable=no
SystemPrimaryDomain=yes
<span style="color:red">letsencryptSSLcert=enabled</span>
<span style="color:blue">odoo.micronator-101.org</span>=domain
Content=Primary
Description=Pour odoo.mn-101.org
Nameservers=internet
<span style="color:red">letsencryptSSLcert=enabled</span>
On voit que ces deux domaines seront inclus dans la demande du certificat à Let's Encrypt car, leur définition contient la ligne: <code>letsencryptSSLcert=enabled</code>.
'''Hôtes'''
On inclut tous les hôtes suivants.
''ftp''
# db hosts setprop <span style="color:red">ftp</span>.micronator-101.org letsencryptSSLcert enabled
# db hosts setprop <span style="color:red">ftp.odoo</span>.micronator-101.org letsencryptSSLcert enabled
''mail''
# db hosts setprop <span style="color:red">mail</span>.micronator-101.org letsencryptSSLcert enabled
# db hosts setprop <span style="color:red">mail.odoo</span>.micronator-101.org letsencryptSSLcert enabled
''proxy''
# db hosts setprop <span style="color:red">proxy</span>.micronator-101.org letsencryptSSLcert enabled
# db hosts setprop <span style="color:red">proxy.odoo</span>.micronator-101.org letsencryptSSLcert enabled
''wpad''
# db hosts setprop <span style="color:red">wpad</span>.micronator-101.org letsencryptSSLcert enabled
# db hosts setprop <span style="color:red">wpad.odoo</span>.micronator-101.org letsencryptSSLcert enabled
''www''
# db hosts setprop <span style="color:red">www</span>.micronator-101.org letsencryptSSLcert enabled
# db hosts setprop <span style="color:red">www.odoo</span>.micronator-101.org 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@<span style="color:blue">micronator.org</span>
'''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]] <u>Seulement si vous acceptez les termes et conditions</u> de Let's Encrypt, lancez la commande ci-dessous.
# config setprop letsencrypt ACCEPT_TERMS <span style="color:red">yes</span>
=== 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://<span style="color:red">acme-staging</span>.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
<span style="color:blue">micronator-101.org</span> ftp.micronator-101.org mail.micronator-101.org proxy.micronator-101.org wpad.micronator-101.org www.micronator-101.org odoo.micronator-101.org ftp.odoo.micronator-101.org mail.odoo.micronator-101.org proxy.odoo.micronator-101.org wpad.odoo.micronator-101.org www.odoo.micronator-101.org
[[Image:Icone-SeTirerDembarrasAPT.png|25px]] 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 <span style="color:blue">micronator-101.org</span>.
'''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 que vous demandez, relever les défis et requérir le certificat.
# dehydrated -c
<span style="color:blue"># INFO: Using main config file /etc/dehydrated/config</span>
+ Generating account key...
+ Registering account key with ACME server...
Processing micronator-101.org with alternative names: ftp.micronator-101.org mail.micronator-101.org proxy.micronator-101.org wpad.micronator-101.org www.micronator-101.org odoo.micronator-101.org ftp.odoo.micronator-101.org mail.odoo.micronator-101.org proxy.odoo.micronator-101.org wpad.odoo.micronator-101.org www.odoo.micronator-101.org
+ <span style="color:red">Signing domains...</span>
+ <span style="color:red">Creating new directory /etc/dehydrated/certs/micronator-101.org ...</span>
+ <span style="color:red">Creating chain cache directory /etc/dehydrated/chains</span>
+ <span style="color:red">Generating private key...</span>
+ <span style="color:red">Generating signing request...</span>
+ Requesting challenge for <span style="color:blue">micronator-101.org</span>...
+ Requesting challenge for <span style="color:DarkGreen">ftp</span>.micronator-101.org...
+ Requesting challenge for <span style="color:DarkGreen">mail</span>.micronator-101.org...
+ Requesting challenge for <span style="color:DarkGreen">proxy</span>.micronator-101.org...
+ Requesting challenge for <span style="color:DarkGreen">wpad</span>.micronator-101.org...
+ Requesting challenge for <span style="color:DarkGreen">www</span>.micronator-101.org...
+ Requesting challenge for <span style="color:blue">odoo.micronator-101.org</span>...
+ Requesting challenge for <span style="color:DarkGreen">ftp.odoo</span>.micronator-101.org...
+ Requesting challenge for <span style="color:DarkGreen">mail.odoo</span>.micronator-101.org...
+ Requesting challenge for <span style="color:DarkGreen">proxy.odoo</span>.micronator-101.org...
+ Requesting challenge for <span style="color:DarkGreen">wpad.odoo</span>.micronator-101.org...
+ Requesting challenge for <span style="color:DarkGreen">www.odoo</span>.micronator-101.org...
+ Responding to challenge for micronator-101.org...
+ <span style="color:red">Challenge is valid!</span>
+ Responding to challenge for ftp.micronator-101.org...
+ Challenge is valid!
+ Responding to challenge for mail.micronator-101.org...
+ Challenge is valid!
+ Responding to challenge for proxy.micronator-101.org...
+ Challenge is valid!
+ Responding to challenge for wpad.micronator-101.org...
+ Challenge is valid!
+ Responding to challenge for www.micronator-101.org...
+ Challenge is valid!
+ Responding to challenge for odoo.micronator-101.org...
+ Challenge is valid!
+ Responding to challenge for ftp.odoo.micronator-101.org...
+ Challenge is valid!
+ Responding to challenge for mail.odoo.micronator-101.org...
+ Challenge is valid!
+ Responding to challenge for proxy.odoo.micronator-101.org...
+ Challenge is valid!
+ Responding to challenge for wpad.odoo.micronator-101.org...
+ Challenge is valid!
+ Responding to challenge for www.odoo.micronator-101.org...
+ Challenge is valid!
+ <span style="color:red">Requesting certificate</span>...
+ Checking certificate...
+ Done!
+ <span style="color:red">Creating fullchain.pem</span>...
+ Using cached chain!
Set up <span style="color:red">modSSL</span> db keys
<span style="color:red">Signal events</span>
All complete
+ <span style="color:Blue">Done!</span>
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.
'''Vérification du certificat'''
<center>
{| class="wikitable" style="width: 80%; background-color:#ffffff;"
|- style="vertical-align:bottom;font-family: Courier New;text-align: left;"
|Avec Firefox, on se connecte au gestionnaire Server Manager.
||Après avoir accepté le certificat, on clique le cadenas et >.
||Plus d'informations.
||Afficher le certificat.
|- style="vertical-align:top;"
|[[Image:odoo-11-HTTPS-009-Verif-URL.png|center|top|250px|border]]
||[[Image:odoo-11-HTTPS-010-VerifCadenas.png|center|top|250px|border]]
||[[Image:odoo-11-HTTPS-011-VerifPlusInfo.png|center|top|250px|border]]
||[[Image:odoo-11-HTTPS-012-VerifAfficherCert.png|center|top|250px|border]]
|}
</center>
<center>
{| class="wikitable" style="width: 80%; background-color:#ffffff;"
|- style="vertical-align:bottom;font-family: Courier New;text-align: left;"
|<nowiki>-</nowiki> Certificat de test car, émis par Fake LE Intermediate XI.
<nowiki>-</nowiki> Détails.
||<nowiki>-</nowiki> Nom alternatif du sujet du certificat.
<nowiki>-</nowiki> Nos noms d'hôtes sont présents.
||
Valide pour 90 jours.
|- style="vertical-align:top;"
|[[Image:odoo-11-HTTPS-013-VerifEmisPar.png|center|top|325px|border]]
||[[Image:odoo-11-HTTPS-014-VerifNomAlter.png|center|top|325px|border]]
||[[Image:odoo-11-HTTPS-015-Verif90Jours.png|center|top|325px|border]]
|}
</center>
<center><span style="font-size:115%">'''Tout fonctionne correctement, on peut passer en mode Production et demander un certificat officiel.'''</span></center>
=== 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
<span style="color:blue"># INFO: Using main config file /etc/dehydrated/config</span>
+ <span style="color:red">Generating account key</span>...
+ <span style="color:red">Registering account key with ACME server</span>...
Processing micronator-101.org with alternative names: ftp.micronator-101.org mail.micronator-101.org proxy.micronator-101.org wpad.micronator-101.org www.micronator-101.org odoo.micronator-101.org ftp.odoo.micronator-101.org mail.odoo.micronator-101.org proxy.odoo.micronator-101.org wpad.odoo.micronator-101.org www.odoo.micronator-101.org
+ Checking domain name(s) of existing cert... unchanged.
+ Checking expire date of existing cert...
+ Valid till Sep 27 18:18:24 2018 GMT <span style="color:red">(Longer than 30 days). Ignoring because renew was forced!</span>
+ Signing domains...
+ <span style="color:red">Generating private key</span>...
+ Generating signing request...
+ Requesting challenge for micronator-101.org...
...
+ <span style="color:red">Requesting certificate</span>...
+ Checking certificate...
+ Done!
+ <span style="color:red">Creating fullchain.pem</span>...
+ Using cached chain!
Set up <span style="color:red">modSSL</span> db keys
<span style="color:red">Signal events</span>
All complete
+ <span style="color:Blue">Done!</span>
Si cette demande a réussie, félicitations! Vous avez obtenu un certificat TLS officiel et valide qui se renouvellera automatiquement à perpétuité.
[[Image:Icone-SeTirerDembarrasAPT.png|25px]] Si vous recevez l'erreur ci-dessous, simplement relancer la demande.
{| class="wikitable" style="width: 80%; background-color:#FFEED9;"
|- style="vertical-align:top;font-family: Courier New;"
|<nowiki>#</nowiki> INFO: Using main config file /etc/dehydrated/config
<span style="color:red">ERROR: Problem connecting to server</span> (get for https://acme-v01.api.letsencrypt.org/directory; <span style="color:red">curl returned with 6</span>)
|}
=== 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/]. Soumettez votre nom de domaine pour vous assurer que le nouveau certificat fonctionne correctement.
Entrez le nom de votre domaine: '''micronator-101.org''' > Submit.
<center>
{| class="wikitable"
|- style="vertical-align:top;"
|[[Image:odoo-11-HTTPS-016-QualsysHome.png|center|top|450px|border]]
||[[Image:odoo-11-HTTPS-017-QualsysResultat.png|center|top|450px|border]]
|}
</center>
<center>
{| style="background: {{{color|#FFEED9}}}; border: 1px dashed; width:60%"
|<div style="text-align:center;">This server does not support Forward Secrecy with the reference browsers. Grade capped to B.</div>
|}
[[Image:Icone-NoteAPT.png|25px]] Cette remarque peut être ignorée car, le Serveur SME ne supporte pas <code>Forward Secrecy</code>.
</center>
= Connexion sécuritaire SSL (https) à Odoo =
Lorsqu'on se logue à '''Odoo''', sans utiliser une connexion sécuritaire '''TLS'''<ref name="ftn2">'''Transport Layer Security''' ''(TLS)'' ou Sécurité de la couche de transport et son prédécesseur, Secure Sockets Layer ''(SSL)'', sont des protocoles de sécurisation des échanges sur Internet. Le protocole SSL a été développé à l'origine par Netscape. L'IETF en a poursuivi le développement en le rebaptisant Transport Layer Security ''(TLS)''. On parle parfois de SSL/TLS pour désigner indifféremment SSL ou TLS.
''Référence'': https://fr.wikipedia.org/wiki/Transport_Layer_Security. </ref>, notre mot de passe est transmis en clair sur le réseau.
[[Image:odoo-11-HTTPS-000-NouveauDom.png|top|right|200px|border]]
Pour remédier à la situation:
# Nous avons déjà ajouté le sous-domaine <span style="color:Blue">odoo.micronator-101.org</span>.
# À l'aide d'un gabarit personnalisé, nous allons rediriger les accès à <span style="color:Blue">odoo.micronator-101.org</span> et les contraindre à utiliser une connexion sécurisée TLS vers le port 8069.
=== Redirection ===
'''Gabarit personnalisé'''
Vu qu'on ne doit pas modifier directement un fichier de configuration, nous allons créer un gabarit personnalisé pour accomplir les modifications nécessaires. Ainsi, lorsqu'on mettra le Serveur SME à jour, les modifications seront conservées.
'''Copie du fragment à modifier'''
Le fragment de la configuration d'Apache à modifier est le fichier: <code>25SSLDirectives</code>. Ce fichier se trouve dans le répertoire: <code>/etc/e-smith/<u>templates</u>/etc/httpd/conf/httpd.conf/VirtualHosts</code>.
Nous devons créer un répertoire qui contiendra la copie de ce fragment qu'on pourra ainsi modifier.
# mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts
On copie le fragment original vers le gabarit personnalisé.
# cp /etc/e-smith/<span style="color:red">templates</span>/etc/httpd/conf/httpd.conf/VirtualHosts/25SSLDirectives <span style="color:red">\</span>
/etc/e-smith/<span style="color:red">templates-custom</span>/etc/httpd/conf/httpd.conf/VirtualHosts
On vérifie.
# ls -ls /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts
total 4
4 -rw-r--r-- 1 root root 196 7 sept. 22:13 <span style="color:red">25SSLDirectives</span>
'''Modification du fichier du gabarit personnalisé'''
Fichier original.
{| class="wikitable" style="width: 80%; background-color:#FFEED9;"
|- style="vertical-align:top;font-family: Courier New;"
|
<nowiki>{</nowiki><br>
<nowiki> return " # skipping SSL directives\n" unless $port eq "443";</nowiki><br><br>
<nowiki> return "" unless $modSSL{'status'} eq 'enabled';</nowiki><br><br>
<nowiki> $OUT = <<SSL_END;</nowiki><br>
<nowiki> # SSL Directives</nowiki><br>
<nowiki> SSLEngine on</nowiki><br>
SSL_END</nowiki></nowiki><br>
<nowiki>}</nowiki>
|}
[[Image:Icone-NoteAPT.png|25px]] On peut modifier le contenu du fichier du gabarit personnalisé avec <code>vi</code> , <code>Notepad++</code> ... ou utiliser la commande ci-dessous.
[[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/VirtualHosts/25SSLDirectives <<'EOT'
{
if ( $port eq "80" && $virtualHost eq "odoo.micronator-101.org")
{
$OUT .= " \n";
$OUT .= " # Pour la redirection d'Odoo.\n";
$OUT .= " # Michel-André / 2018-09-08_14h05\n";
$OUT .= " Redirect / https://odoo.micronator-101.org/\n";
}
return " # skipping SSL directives\n" unless $port eq "443";
return "" unless $modSSL{'status'} eq 'enabled';
$OUT = <<SSL_END;
# SSL Directives
SSLEngine on
<span style="color:red">SSL_END</span>
if ( $virtualHost eq "odoo.micronator-101.org" )
{
$OUT .= " \n";
$OUT .= " # Pour la redirection vers le port 8069\n";
$OUT .= " # Michel-André / 2018-09-08_14h05\n";
$OUT .= " ProxyPass / http://localhost:8069/ retry=0\n";
$OUT .= " ProxyPassReverse / http://localhost:8069/\n";
}
}
EOT
[[fichier:015-IconeASurveiller.png|left|caption|32px]] La ligne <span style="color:red">SSL_END</span> doit obligatoirement débuter sur la première colonne.
On développe <code>httpd.conf</code> pour qu'il lise le gabarit personnalisé et qu'il l'intègre dans sa configuration.
# expand-template /etc/httpd/conf/httpd.conf
On vérifie le fichier de configuration de <code>httpd.conf</code> pour s'assurer que le gabarit personnalisé a bien été intégré.
# cat /etc/httpd/conf/httpd.conf | grep "Pour la redirection"
<span style="color:blue"># Pour la redirection d'Odoo.
# Pour la redirection vers le port 8069</span>
'''Redémarrage des démons'''
On redémarre le démon <code>httpd</code>.
# /etc/rc.d/init.d/httpd-e-smith restart
On redémarre le démon <code>odoo</code>.
# /etc/rc.d/init.d/odoo restart
=== Vérification ===
[[Image:Icone-AsurveillerAPT.png|25px]] On supprime l'historique de notre navigateur.
'''''Connexion à Server Manager'''''
On s'assure qu'on peut toujours accéder au gestionnaire Server Manager en allant à: https://www.micronator-101.org/server-manager.
<center>
{| class="wikitable"
|- style="vertical-align:top;"
|[[Image:odoo-11-HTTPS-018-SMlogin.png|center|top|250px|border]]
||[[Image:odoo-11-HTTPS-019-SMBienvenue.png|center|top|700px|border]]
|}
</center>
<center>'''La connexion vers le site <span style="color:blue">micronator-101.org</span> n'est pas redirigée et on peut accéder au gestionnaire du serveur.'''</center>
'''''Connexion à Odoo'''''
On se rend sur notre site Odoo en spécifiant toujours <span style="color:blue"><u>odoo.</u>micronator-101.org</span>:
<div style="font-family: Courier New;">
* http://<span style="color:blue"><u>odoo.</u>micronator-101.org</span>
* http://<span style="color:red">www</span>.<span style="color:blue"><u>odoo.</u>micronator-101.org</span>
* http<span style="color:red">s</span>://<span style="color:blue"><u>odoo.</u>micronator-101.org</span>
* http<span style="color:red">s</span>://<span style="color:red">www</span>.<span style="color:blue"><u>odoo.</u>micronator-101.org</span>
* <span style="color:blue"><u>odoo.</u>micronator-101.org</span>
</div>
Le résultat est toujours le même: https://odoo.micronator-101.org/web/login. On est automatiquement redirigé vers la page de connexion d'Odoo et le cadenas est <span style="color:DarkGreen"><u>'''vert'''</u></span>.
[[Image:Icone-NoteAPT.png|25px]] Vu que notre certificat a été émis par '''Let's Encrypt Authority X3''', une véritable autorité de certification reconnue, le serveur Web d'Odoo a accepté le certificat et a émis une connexion sécurisée.
<center>On se logue, la page d'accueil d'Odoo apparaît et le cadenas est toujours <span style="color:DarkGreen"><u>'''vert'''</u></span>.</center>
<center>
{| class="wikitable" style="width: 80%; background-color:#ffffff;"
|- style="vertical-align:top;"
|[[Image:odoo-11-HTTPS-020-OdooLogin.png|center|top|300px|border]]
||[[Image:odoo-11-HTTPS-021-OdooAccueil.png|center|top|700px|border]]
|}
</center>
<center><big>'''Notre connexion à Odoo est maintenant toujours sécurisée. (CQFD)'''</big></center>
'''''Certificat'''''
<center>
{| class="wikitable" style="width: 95%;"
|- style="vertical-align:bottom;font-family: Courier New;text-align: left;"
|
On clique le cadenas puis ">".
||
Plus d'informations.
||
Afficher le certificat.
||<nowiki>-</nowiki> Le certificat a été émis par Let's Encrypt Authority X3 qui est une autorité de certification reconnue.
<nowiki>-</nowiki> Détails.
|- style="vertical-align:top;"
|[[Image:odoo-11-HTTPS-022-CertifCadenas.png|center|top|200px|border]]
||[[Image:odoo-11-HTTPS-023-CertifPlusInfo.png|center|top|250px|border]]
||[[Image:odoo-11-HTTPS-024-CertifEmisPar.png|center|top|250px|border]]
||[[Image:odoo-11-HTTPS-025-CertifPasAvant.png|center|top|350px|border]]
|}
</center>
<center>
{| class="wikitable" style="width: 80%;"
|- style="vertical-align:bottom;font-family: Courier New;text-align: left;"
|Pas avant.
|Pas après ''(valide pour 90 jours)''.
|Nos CNAME sont tous là.
|- style="vertical-align:top;"
|[[Image:odoo-11-HTTPS-025-CertifPasAvant.png|center|top|350px|border]]
||[[Image:odoo-11-HTTPS-026-CertifPasApres.png|center|top|350px|border]]
||[[Image:odoo-11-HTTPS-027-CertifCNAME.png|center|top|350px|border]]
|}
</center>
'''''Fichier index de l'i-bay Primary'''''
On visite la page: http://www.micronator-101.org. On peut aussi utiliser https.
[[Image:odoo-11-HTTPS-008-PageDeLaSociete.png|center|top|400px|border]]
<center>''La page décrivant notre société''.</center>
=== Mise en garde ===
[[Image:Icone-AsurveillerAPT.png|25px]] Il ne faut plus spécifier le port <span style="color:red">''':8069'''</span> car, vous obtiendriez alors l'erreur de connexion suivante: <code>SSL_ERROR_RX_RECORD_TOO_LONG</code>.
<center>[[Image:Odoo-11-HTTPS-008A-ErreurDePort8069.png|top|center|700px|border]]</center>
<center><span style="font-size:115%">'''L'accès au gestionnaire Server Manager est toujours possible.'''</span></center>
<center><span style="font-size:115%">'''Les connexions vers Odoo sont redirigées vers des connexions SSL/TLS.'''</span></center>
<center><span style="font-size:115%">'''L'accès à micronator-101.org affiche une page décrivant notre société.'''</span></center>
= Certificat standard SME =
On veut recréer un certificat original émis et certifié par le Serveur SME-9.x lui-même.
Après s'être logué avec l'utilisateur <span style="color:red">root</span>, on devrait être dans le répertoire personnel de ce dernier.
# pwd
<span style="color:red">root</span>
'''Création d'un répertoire de sauvegarde'''
# mkdir dehydrated
On se rend dans le répertoire de sauvegarde.
# cd 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
<span style="color:Blue">SSLCertificateChainFile</span> /etc/dehydrated/certs/micronator-101.org/<span style="color:red">chain.pem</span>
<span style="color:Blue">SSLCertificateFile</span> /etc/dehydrated/certs/micronator-101.org /<span style="color:red">cert.pem</span>
<span style="color:Blue">SSLCertificateKeyFile</span> /etc/dehydrated/certs/micronator-101.org /<span style="color:red">privkey.pem</span>
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 <span style="color:blue">odoo-11.micronator-101.org.pem</span>
Il n'est pas nécessaire de le faire, mais on sauvegarde quand même le fichier <code>pem</code>.
# cp /home/e-smith/ssl.pem/odoo-11.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 odoo-11.micronator-101.org.pem
'''Suppression de certaines propriétés de modSSL'''
On affiche les propriétés de <code>modSSL</code>.
# config show modSSL
modSSL=service
<span style="color:red">CertificateChainFile</span>=/etc/dehydrated/certs/micronator-101.org/chain.pem
TCPPort=443
access=public
<span style="color:red">crt</span>=/etc/dehydrated/certs/micronator-101.org /cert.pem
<span style="color:red">key</span>=/etc/dehydrated/certs/micronator-101.org /privkey.pem
status=enabled
On supprime la propriété <code>CertificateChainFile</code>.
# config delprop modSSL CertificateChainFile
On supprime la propriété <code>CommonName</code>.
# config delprop modSSL CommonName
On supprime la propriété <code>crt</code>.
# config delprop modSSL crt
On supprime la propriété <code>key</code>.
# config delprop modSSL key
À nouveau, on vérifie les propriétés de <code>modSSL</code>.
# config show modSSL
<span style="color:blue">modSSL=service
TCPPort=443
access=public
status=enabled</span>
'''Suppression des paramètres de tous les anciens certificats'''
[[fichier:015-IconeASurveiller.png|left|caption|32px]]On utilise la très dangereuse commande <code>rm -rf</code> pour supprimer tous les anciens fichiers: <code>.crt</code>, <code>.key</code> et <code>.pem</code> du Serveur SME.
''.crt''
# rm -rf /home/e-smith/ssl.crt/*
''.key''
# rm -rf /home/e-smith/ssl.key/*
''.pem''
# rm -rf /home/e-smith/ssl.pem/*
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 ci-dessous. 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;"
|
signal-event domain-modify; \<br>
signal-event email-update; \<br>
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:odoo-11-HTTPS-029-CerttifSMEPostUpgrade.png|top|right|450px|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 <code>modSSL</code>, le serveur réamorcera pour activer tous les nouveaux paramètres et prendra environ une minute pour redevenir actif.
<br>
<br>
<br>
<br>
<br>
<br>
<br>
'''Vérification'''
'''''Console du serveur'''''
On affiche la date.
# date
ven. <span style="color:red">mars 3 18:30:02</span> EST 2017
Fichier <code>pem</code>.
# ls -ls /home/e-smith/ssl.pem/
total 4
4 -rw-r--r-- 1 root root 3564 <span style="color:red">3 mars 18:23</span> odoo-11.micronator-101.com.pem
Le fichier <code>pem</code> vient tout juste d'être recréé depuis quelques minutes seulement.
'''''Navigateur Web'''''
On se rend au site: https://www.micronator-101.com.
Firefox affiche un écran d'avertissement. Avancé > Ajouter une exception... > Voir... > onglet Détails > Validité > Pas avant.
[[Image:odoo-11-HTTPS-030-CerttifSMEDetails.png|top|left|300px|border]]
Le certificat est au nom de: ''odoo-11.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 les fenêtres et ajouter l'exception.
Le nouveau certificat, émis et certifié par le Serveur SME lui-même, est fonctionnel.
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<span style="font-size:120%">'''Mot de la fin'''</span>
[[Image:Icone-NoteAPT.png|25px]] La prochaine marche à suivre décrira les étapes pour créer un site de test/développement virtuel pour Odoo-11.
[[Image:Odoo-11-BanniereDeLaVictoire-APT.png|caption|36px]] Victoire totale, hissons la bannière de la victoire.
<br>
<br>
----
<references/>
[[Category:Howto]] [[Category:Howto/fr]]
__TOC__
= Description générale =
Cette marche à suivre fait suite à celle sur SME-9.2 & Odoo-11 ''(https://wiki.contribs.org/Odoo-11)'' et décrit les étapes pour assurer une connexion sécuritaire à Odoo-11 roulant sur un Serveur SME.
<span style="font-size:125%">'''But final'''</span>
[[Image:odoo-11-HTTPS-001-ButFinal.png|top|right|700px]]
Pour le présent document, sur le serveur <span style="color:red">odoo-11.</span><span style="color:blue">micronator-101.org</span>, nous avons installé Fail2ban et suivi les mêmes procédures qu'auparavant pour une nouvelle installation d'Odoo-11.
[[Image:Icone-NoteAPT.png|25px]] Ce nouveau serveur est configuré en mode '''''Serveur et passerelle'''''.
L'installation de SME-9.2 sur le serveur branché directement à l'Internet est exactement telle que décrite dans les cahiers 2 et 3 du cours Micronator-101.
https://www.micronator.org/affaires/produit/micronator-101-cahier-2installation-dun-serveur-sme/.
https://www.micronator.org/affaires/produit/micronator-101-cahier-3adslvdsl-dns-dynamique-domaine-fqdn/.
L'installation de Fail2ban est décrite dans à la page: https://www.micronator.org/affaires/produit/sme-9-x8-x-fail2ban/.
L'installation du serveur BackupPC provient de: ''Micronator-101, Supplément: SME & BackupPC'': https://www.micronator.org/affaires/produit/micronator-101-supplementsme-backuppc/
= 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 ''(à l'aide de sa clé privée)'' peut décoder, garantissant la confidentialité du contenu.
'''Chiffrement'''
L'un des rôles de la clé publique est de permettre le chiffrement; c'est donc cette clé qu'utilisera Bob pour envoyer des messages chiffrés à Alice. L'autre clé — l'information secrète — sert à déchiffrer. Ainsi, Alice, et elle seule, peut prendre connaissance des messages de Bob. <u>La connaissance d'une clé ne permet pas de déduire l'autre</u>.
'''É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 ou "checksum" en anglais, 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:odoo-11-HTTPS-002-HommeDuMilieu.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 à l'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 HdM 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.
* '''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 par Domaine ''(DV)'''''
''Référence'': [https://www.leaderssl.fr/articles/236-la-diff-rence-entre-les-certificats-dv-et-ov https://www.leaderssl.fr/articles/236-la-diff-rence-entre-les-certificats-dv-et-ov].
Certificats DV ''(Domain Validation ou validation par domaine)'': la validation par domaine est le niveau le plus élémentaire de la validation SSL. L’autorité de certification ''(CA)'' vérifie uniquement que vous êtes bien le propriétaire d’un domaine donné à l’aide des informations figurant dans la base de données WHOIS. Ce type de certificat assure bien entendu le chiffrement des données sur votre site mais, il ne vérifie pas que vous êtes le propriétaire d’une entreprise légitime. Il apporte néanmoins une preuve de légitimité, et surtout, il vous permet de protéger très rapidement votre site en utilisant le protocole HTTPS. Les clients qui verront le cadenas dans leur navigateur auront davantage confiance dans votre site parce que le cadenas est une preuve de légitimité reconnue.
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. Le propriétaire ou le webmestre du nom de domaine doit confirmer la requête par courriel.
* ''Avantages'': Un certificat SSL DV est facile à obtenir. Vous obtenez ce certificat en quelques minutes.
* ''À 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'<u>identité du propriétaire du site Internet</u>.
* ''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 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:
<nowiki> </nowiki>'''*''' www.macompagnie.com
<nowiki> </nowiki>'''*''' mail.macompagnie.com
<nowiki> </nowiki>'''*''' macompagnie.com
<nowiki> </nowiki>'''*''' www.toto.net
<nowiki> </nowiki>'''*''' mail.toto.net
<nowiki> </nowiki>'''*''' 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 ''(<u>un astérisque et un point</u> 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/]. ''(Ce lien n'est plus valide.)''
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'enregistrements 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 pointant vers cet enregistrement suivent automatiquement la nouvelle adresse 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 augmentent 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.domain.com'' ou soit ''domain.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))''.
[[Image:odoo-11-HTTPS-003-CNAME-Coquille.png|top|right|300px|border]]
* '''Exemple'''
Vous avez un site Web avec le nom de domaine ''monsite.quebec''. Ce nom de domaine est connecté à un enregistrement A qui traduit le nom de domaine à l'adresse IP appropriée, par exemple: 11.22.33.44.
Vous avez aussi plusieurs sous-domaines, comme ''coquille.monsite.quebec'', ''email.monsite.quebec'', etc... et vous souhaitez que ces sous-domaines pointent à votre nom de domaine principal ''monsite.quebec''. Au lieu de créer des enregistrements A pour chaque sous-domaine et les lier à l'adresse IP de votre domaine principal, vous créez un alias ''(enregistrement CNAME)'' pour chacun d'eux pour obtenir la figure ci-contre. Dans le cas où votre adresse IP change, vous devez seulement éditer un enregistrement A et tous les sous-domaines suivent automatiquement du fait des CNAME pointant vers le domaine principal.
[[Image:Icone-AstuceAPT.png|25px]] Si nous avons un domaine intranet ''(sur le réseau LOCAL)'' qui fait partie du domaine principal et dont le nom est ''coquille.monsite.quebec'', nous pouvons alors insérer un CNAME ''coquille'' pour ce domaine.
= L'autorité de certification 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 <code>dehydrated</code> et sur l'automatisation qu'il propose.
Le client <code>dehydrated</code> 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 <code>dehydrated</code>:
* 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 <code>dehydrated</code> 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 ou Nginx, pour l'instant)''.
Le client <code>dehydrated</code> 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 <code>dehydrated</code>.
=== Courriel 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 <code>dehydrated</code>.
=== 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 ===
''Référence'': [https://letsencrypt.org/docs/rate-limits/ https://letsencrypt.org/docs/rate-limits/].
* '''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-03-12:
* Limite de 5 certificats par domaine, dans une fenêtre de 7 jours.
* Limite de 5 échecs de validation par compte, par nom d'hôte et par heure. Cette limite est plus élevée dans l'environnement de test
<nowiki></nowiki>'''*''' Certificats par domaine signifie 5 émissions de certificat et non pas combien de domaines au sein d'un certificat multi-domaines SAN.
<nowiki></nowiki>'''**''' Un certificat multi-domaines SAN ayant ''domaine1.com'', ''www.domaine1.com'', ''domaine2.com'', ''www.domaine2.com'', ''toto.info'' et ''titi.org'' est compté comme 1 certificat mais, on ne peut renouveler ce certificat multi-domaines plus de 5 fois par période de 7 jours?
<nowiki></nowiki>'''***''' Il n'y a pas de limites pour le nombre de domaines contenus dans un certificat multi-domaines SAN ou, plus précisément, jusqu'au maximum standard de 100. Let's Encrypt a choisi cette limite de 100 sur une base de prudence car, il semble que lorsqu'on en obtient plus de 100, certains navigateurs Web ont un comportement erratique. Let's Encrypt peut probablement augmenter cette limite si quelqu'un en fait la demande.
=== Mode Officiel vs TEST ''(staging''<ref name="ftn1">
'''Staging''' Un site Staging, dans la conception de sites Web, est un site utilisé pour assembler, tester et revoir une version plus récente avant de l'implanter en production. ''Référence'': https://en.wikipedia.org/wiki/Staging_site. </ref>'')'' ===
Lorsqu'on veut tester <code>dehydrated</code>, c'est l'option staging ''(défini par la ligne <code>CA="https://acme-staging.api.letsencrypt.org/directory"</code>)'' qui est utilisée dans le fichier de configuration <code>config</code>.
Le principal avantage de ce mode 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 <code>dehydrated</code> utilise la CA officielle, <code>Let’s Encrypt Authority X3</code>.
* '''''CA de TEST'''''
Un certificat de test ne sera pas signé directement par Let's Encrypt mais par sa CA de tests, <code>Fake LE Intermediate X1</code>. 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 <code>Fake LE Intermediate X1</code>.
[[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 ne spécifie pas la CA à utiliser car, par défaut, le client dehydrated utilise la CA officielle <code>Let’s Encrypt Authority X3</code>.
[[Image:Icone-NoteAPT.png|25px]] Toutefois, la contribution Let's Encrypt insère quand même, dans le fichier de configuration, la ligne:
{| class="wikitable" style="width: 80%; background-color:#FFEED9;"
|- style="vertical-align:top;font-family: Courier New;"
|CA="https://<span style="color:red">acme-v01</span>.api.letsencrypt.org/directory"
|}
[[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 Production.
{| class="wikitable" style="width: 80%; background-color:#FFEED9;"
|- style="vertical-align:top;font-family: Courier New;"
|#!/bin/bash<br>
WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"<br>
CA="https://<span style="color:red">acme-v01</span>.api.letsencrypt.org/directory"<br>
BASEDIR="/etc/dehydrated"<br>
CONTACT_EMAIL=admin@micronator.org<br>
HOOK="/usr/bin/hook-script.sh"<br><br>
PARAM_ACCEPT_TERMS="yes"
|}
* '''''Certificat de TEST'''''
Le fichier de configuration pour une demande certificat de test doit spécifier la CA <code><span style="color:red">acme-staging</span></code> qui seule, émet ces certificats de test pour Let's Encrypt.
{| class="wikitable" style="width: 80%; background-color:#FFEED9;"
|- style="vertical-align:top;font-family: Courier New;"
|#!/bin/bash<br>
WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"<br>
CA="https://<span style="color:red">acme-staging</span>.api.letsencrypt.org/directory"<br>
BASEDIR="/etc/dehydrated"<br>
CONTACT_EMAIL=admin@micronator.org<br>
HOOK="/usr/bin/hook-script.sh"<br><br>
PARAM_ACCEPT_TERMS="yes"
|}
=== Clé de compte Let's Encrypt ===
[[Image:Icone-NoteAPT.png|25px]] La clé de compte <code>privkey-1234567890.pem</code> 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>.
Contenu du répertoire <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 de certificat de TEST et celui de la clé de compte OFFICIEL est créé lors de la première demande de certificat OFFICIEL.
* Le sous-répertoire et la clé utilisée dépendent de la ligne <code>CA="https://acme...</code> dans le fichier de configuration <code>/etc/dehydrated/config</code>.
La clé de compte est utilisée exclusivement par le client <code>dehydrated</code> 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 une demande pour un certificat de TEST ou OFFICIEL, la clé de compte est toujours appelé <code>account_key.pem</code>.
[[Image:Icone-NoteAPT.png|25px]] Une clé SSL/TLS est toujours constituée d'une partie publique et d'une partie privée.
=== Aide ===
Pour afficher l'aide du client <code>dehydrated</code>.
# /usr/bin/dehydrated <span style="color:red">--help</span>
=== 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|Certificat standard SME]].
= Préparation du serveur =
=== Ajout d'un nouveau domaine ===
[[Image:odoo-11-HTTPS-000-NouveauDom.png|top|right|200px]]
Si nous redirigeons tous les accès de notre <u>serveur</u> <span style="color:red">odoo-11.</span><span style="color:blue">micronator-101.org</span> vers le port 8069 à l'aide d'un Gabarit personnalisé, le gestionnaire Server Manager sera lui aussi redirigé vers le port 8069 et il générera alors une erreur de connexion. C'est pour cette raison que nous allons créer le <u>domaine</u> <span style="color:blue"><span style="color:Blue">odoo.</span>micronator-101.org</span> et rediriger tous les accès ''(http et https)'', <u>pour ce domaine seulement</u>, en forçant une connexion sécurisée vers le port 8069.
[[Image:Icone-NoteAPT.png|25px]] On utilise <span style="color:Blue">odoo</span> pour le domaine et <span style="color:red">odoo-11</span> pour le serveur.
<br>
<br>
<br>
'''Création du domaine'''
<center>
{| class="wikitable" style="width: 80%; background-color:#ffffff;"
|- style="vertical-align:bottom;font-family: Courier New;text-align: left;"
|Server Manager > Domaines > Ajouter un domaine.
||<nowiki>-</nowiki> Entrer les informations telles que ci-dessous.
<nowiki>-</nowiki> Ajouter.
||On s'assure du succès de l'opération.
|- style="vertical-align:top;"
|[[Image:odoo-11-HTTPS-004-CreationDomaine.png|center|top|350px|border]]
||[[Image:odoo-11-HTTPS-005-CreationDomaine.png|center|top|350px|border]]
||[[Image:odoo-11-HTTPS-006-CreationDomaine.png|center|top|350px|border]]
|}
</center>
'''CNAME'''
[[Image:odoo-11-HTTPS-007-AjoutCNAME.png|top|right|350px|border]]
Nous avons créer un nouveau domaine, nous ajoutons donc les CNAME suivants chez le régistraire de notre domaine <span style="color:blue">micronator-101.org</span>: <code>odoo</code> , <code>ftp.odoo</code> , <code>mail.odoo</code> , <code>proxy.odoo</code> , <code>wpad.odoo</code> et <code>www.odoo</code>.
<br>
<br>
<br>
<br>
=== Fichier index de l'i-bay Primary ===
[[Image:odoo-11-HTTPS-008-PageDeLaSociete.png|top|right|350px|border]]
Vu que nous allons réglé la redirection, celle dans le fichier <code>index.html</code> dans l'i-bay Primary ne sera plus nécessaire et nous pouvons remplacer le contenu de ce fichier par une texte en HTML décrivant notre organisation et qui sera affiché lors d'une visite à la page: http://www.micronator-101.org ou https://www.micronator-101.org.
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
= 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 reconnue mondialement. Les usagers pourront utiliser http<u><span style="color:red">s</span></u> et, vu que le certificat a été émis par une autorité de certification reconnue, le cadenas sera <u><span style="color:DarkGreen">vert</span></u>.
Cette section est inspirée de la contribution Letsencrypt produite par: DanB35, Unnilennium, Mdo, Mercyh, RayMitchell et Gieres à l'URL: [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 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 contribution <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é:
<span style="color:red">smeserver-letsencrypt</span>.noarch 0:0.4-4
Dépendance(s) installée(s) :
<span style="color:red">dehydrated</span>.noarch 0:0.5.0-3.el6.sme
Terminé !
==============================================================
WARNING: You now need to run BOTH of the following commands
to ensure consistent system state:
<span style="color:red">signal-event post-upgrade; signal-event reboot</span>
You should run these commands unless you are certain that
yum made no changes to your system.
==============================================================
On signale les changements.
# signal-event post-upgrade ; signal-event reboot
[[Image:Icone-AsurveillerAPT.png|25px]] Ne pas signaler les changements pourrait empêcher la contribution de fonctionner correctement et vos certificats ne seront pas renouvelés.
=== Mise à jour de la Contrib ===
Vous devez manuellement mettre à jour la Contrib i.e. smeserver-letsencrypt et dehydrated en utilisant la commande ci-dessous.
{| class="wikitable" style="width: 80%; background-color:#FFEED9;"
|- style="vertical-align:top;font-family: Courier New;"
| # yum update -y --enablerepo=smecontribs smeserver-letsencrypt dehydrated<br><br>
Modules complémentaires chargés : fastestmirror, smeserver<br>
Configuration du processus de mise à jour<br>
Loading mirror speeds from cached hostfile<br>
<nowiki>*</nowiki> base: centos.ca-west.mirror.fullhost.io<br>
<nowiki>*</nowiki> smeaddons: mirror.canada.pialasse.com<br>
<nowiki>*</nowiki> smecontribs: mirror.canada.pialasse.com<br>
<nowiki>*</nowiki> smeextras: mirror.canada.pialasse.com<br>
<nowiki>*</nowiki> smeos: mirror.canada.pialasse.com<br>
<nowiki>*</nowiki> smeupdates: mirror.canada.pialasse.com<br>
<nowiki>*</nowiki> updates: centos.mirror.vexxhost.com<br>
<span style="color:red">Aucun paquet marqué pour mise à jour</span>
|}
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.
{| class="wikitable" style="width: 80%; background-color:#FFEED9;"
|- style="vertical-align:top;font-family: Courier New;"
|<nowiki>#</nowiki> signal-event post-upgrade ; signal-event reboot
|}
=== Choix des domaines et des hôtes ===
On affiche les nom d'hôtes sur notre Serveur SME.
# db hosts show | grep .org
<span style="color:red">ftp</span>.micronator-101.org=host
ftp.odoo.micronator-101.org=host
<span style="color:red">mail</span>.micronator-101.org=host
mail.<span style="color:DarkMagenta">odoo</span>.micronator-101.org=host
<span style="color:DarkGreen">odoo-11.micronator-101.org=host</span>
<span style="color:DarkGreen">odoo-11.odoo.micronator-101.org=host</span>
<span style="color:red">proxy</span>.micronator-101.org=host
proxy.<span style="color:DarkMagenta">odoo</span>.micronator-101.org=host
<span style="color:red">wpad</span>.micronator-101.org=host
wpad.<span style="color:DarkMagenta">odoo</span>.micronator-101.org=host
<span style="color:red">www</span>.micronator-101.org=host
www.<span style="color:DarkMagenta">odoo</span>.micronator-101.org=host
[[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é.
[[Image:odoo-11-HTTPS-007-AjoutCNAME.png|top|right|500px|border]]
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é.
Ci-contre, les noms d'hôtes pour le "sous-domaine" <span style="color:blue">odoo.micronator-101.org</span> chez le régistraire du domaine <span style="color:blue">micronator-101.org</span>.
<br>
<br>
<br>
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 <span style="color:red">all</span>
|}
[[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 par la commande <code>db hosts show | grep .org</code>, <u>sauf ceux des noms des serveurs</u>: <span style="color:DarkGreen">odoo-11.micronator-101.org</span> et <span style="color:DarkGreen">odoo-11.odoo.micronator-101.org</span> car, ces derniers ne répondront pas au défis de Let's Encrypt.
Pour utiliser des hôtes ou des domaines activés individuellement, on active le paramètre <code>configure</code> à <code>none</code> et ensuite on ajoute les domaines et les noms d'hôtes désirés.
# config setprop letsencrypt configure <span style="color:red">none</span>
'''Domaines'''
On inclut <span style="color:blue">micronator-101.org</span>.
# db domains setprop micronator-101.org letsencryptSSLcert enabled
On inclut <span style="color:blue">odoo.micronator-101.org</span>.
# db domains setprop odoo.micronator-101.org letsencryptSSLcert enabled
On vérifie.
# db domains show
<span style="color:blue">micronator-101.org</span>=domain
Content=Primary
Description=Primary domain
Nameservers=localhost
Removable=no
SystemPrimaryDomain=yes
<span style="color:red">letsencryptSSLcert=enabled</span>
<span style="color:blue">odoo.micronator-101.org</span>=domain
Content=Primary
Description=Pour odoo.mn-101.org
Nameservers=internet
<span style="color:red">letsencryptSSLcert=enabled</span>
On voit que ces deux domaines seront inclus dans la demande du certificat à Let's Encrypt car, leur définition contient la ligne: <code>letsencryptSSLcert=enabled</code>.
'''Hôtes'''
On inclut tous les hôtes suivants.
''ftp''
# db hosts setprop <span style="color:red">ftp</span>.micronator-101.org letsencryptSSLcert enabled
# db hosts setprop <span style="color:red">ftp.odoo</span>.micronator-101.org letsencryptSSLcert enabled
''mail''
# db hosts setprop <span style="color:red">mail</span>.micronator-101.org letsencryptSSLcert enabled
# db hosts setprop <span style="color:red">mail.odoo</span>.micronator-101.org letsencryptSSLcert enabled
''proxy''
# db hosts setprop <span style="color:red">proxy</span>.micronator-101.org letsencryptSSLcert enabled
# db hosts setprop <span style="color:red">proxy.odoo</span>.micronator-101.org letsencryptSSLcert enabled
''wpad''
# db hosts setprop <span style="color:red">wpad</span>.micronator-101.org letsencryptSSLcert enabled
# db hosts setprop <span style="color:red">wpad.odoo</span>.micronator-101.org letsencryptSSLcert enabled
''www''
# db hosts setprop <span style="color:red">www</span>.micronator-101.org letsencryptSSLcert enabled
# db hosts setprop <span style="color:red">www.odoo</span>.micronator-101.org 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@<span style="color:blue">micronator.org</span>
'''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]] <u>Seulement si vous acceptez les termes et conditions</u> de Let's Encrypt, lancez la commande ci-dessous.
# config setprop letsencrypt ACCEPT_TERMS <span style="color:red">yes</span>
=== 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://<span style="color:red">acme-staging</span>.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
<span style="color:blue">micronator-101.org</span> ftp.micronator-101.org mail.micronator-101.org proxy.micronator-101.org wpad.micronator-101.org www.micronator-101.org odoo.micronator-101.org ftp.odoo.micronator-101.org mail.odoo.micronator-101.org proxy.odoo.micronator-101.org wpad.odoo.micronator-101.org www.odoo.micronator-101.org
[[Image:Icone-SeTirerDembarrasAPT.png|25px]] 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 <span style="color:blue">micronator-101.org</span>.
'''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 que vous demandez, relever les défis et requérir le certificat.
# dehydrated -c
<span style="color:blue"># INFO: Using main config file /etc/dehydrated/config</span>
+ Generating account key...
+ Registering account key with ACME server...
Processing micronator-101.org with alternative names: ftp.micronator-101.org mail.micronator-101.org proxy.micronator-101.org wpad.micronator-101.org www.micronator-101.org odoo.micronator-101.org ftp.odoo.micronator-101.org mail.odoo.micronator-101.org proxy.odoo.micronator-101.org wpad.odoo.micronator-101.org www.odoo.micronator-101.org
+ <span style="color:red">Signing domains...</span>
+ <span style="color:red">Creating new directory /etc/dehydrated/certs/micronator-101.org ...</span>
+ <span style="color:red">Creating chain cache directory /etc/dehydrated/chains</span>
+ <span style="color:red">Generating private key...</span>
+ <span style="color:red">Generating signing request...</span>
+ Requesting challenge for <span style="color:blue">micronator-101.org</span>...
+ Requesting challenge for <span style="color:DarkGreen">ftp</span>.micronator-101.org...
+ Requesting challenge for <span style="color:DarkGreen">mail</span>.micronator-101.org...
+ Requesting challenge for <span style="color:DarkGreen">proxy</span>.micronator-101.org...
+ Requesting challenge for <span style="color:DarkGreen">wpad</span>.micronator-101.org...
+ Requesting challenge for <span style="color:DarkGreen">www</span>.micronator-101.org...
+ Requesting challenge for <span style="color:blue">odoo.micronator-101.org</span>...
+ Requesting challenge for <span style="color:DarkGreen">ftp.odoo</span>.micronator-101.org...
+ Requesting challenge for <span style="color:DarkGreen">mail.odoo</span>.micronator-101.org...
+ Requesting challenge for <span style="color:DarkGreen">proxy.odoo</span>.micronator-101.org...
+ Requesting challenge for <span style="color:DarkGreen">wpad.odoo</span>.micronator-101.org...
+ Requesting challenge for <span style="color:DarkGreen">www.odoo</span>.micronator-101.org...
+ Responding to challenge for micronator-101.org...
+ <span style="color:red">Challenge is valid!</span>
+ Responding to challenge for ftp.micronator-101.org...
+ Challenge is valid!
+ Responding to challenge for mail.micronator-101.org...
+ Challenge is valid!
+ Responding to challenge for proxy.micronator-101.org...
+ Challenge is valid!
+ Responding to challenge for wpad.micronator-101.org...
+ Challenge is valid!
+ Responding to challenge for www.micronator-101.org...
+ Challenge is valid!
+ Responding to challenge for odoo.micronator-101.org...
+ Challenge is valid!
+ Responding to challenge for ftp.odoo.micronator-101.org...
+ Challenge is valid!
+ Responding to challenge for mail.odoo.micronator-101.org...
+ Challenge is valid!
+ Responding to challenge for proxy.odoo.micronator-101.org...
+ Challenge is valid!
+ Responding to challenge for wpad.odoo.micronator-101.org...
+ Challenge is valid!
+ Responding to challenge for www.odoo.micronator-101.org...
+ Challenge is valid!
+ <span style="color:red">Requesting certificate</span>...
+ Checking certificate...
+ Done!
+ <span style="color:red">Creating fullchain.pem</span>...
+ Using cached chain!
Set up <span style="color:red">modSSL</span> db keys
<span style="color:red">Signal events</span>
All complete
+ <span style="color:Blue">Done!</span>
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.
'''Vérification du certificat'''
<center>
{| class="wikitable" style="width: 80%; background-color:#ffffff;"
|- style="vertical-align:bottom;font-family: Courier New;text-align: left;"
|Avec Firefox, on se connecte au gestionnaire Server Manager.
||Après avoir accepté le certificat, on clique le cadenas et >.
||Plus d'informations.
||Afficher le certificat.
|- style="vertical-align:top;"
|[[Image:odoo-11-HTTPS-009-Verif-URL.png|center|top|250px|border]]
||[[Image:odoo-11-HTTPS-010-VerifCadenas.png|center|top|250px|border]]
||[[Image:odoo-11-HTTPS-011-VerifPlusInfo.png|center|top|250px|border]]
||[[Image:odoo-11-HTTPS-012-VerifAfficherCert.png|center|top|250px|border]]
|}
</center>
<center>
{| class="wikitable" style="width: 80%; background-color:#ffffff;"
|- style="vertical-align:bottom;font-family: Courier New;text-align: left;"
|<nowiki>-</nowiki> Certificat de test car, émis par Fake LE Intermediate XI.
<nowiki>-</nowiki> Détails.
||<nowiki>-</nowiki> Nom alternatif du sujet du certificat.
<nowiki>-</nowiki> Nos noms d'hôtes sont présents.
||
Valide pour 90 jours.
|- style="vertical-align:top;"
|[[Image:odoo-11-HTTPS-013-VerifEmisPar.png|center|top|325px|border]]
||[[Image:odoo-11-HTTPS-014-VerifNomAlter.png|center|top|325px|border]]
||[[Image:odoo-11-HTTPS-015-Verif90Jours.png|center|top|325px|border]]
|}
</center>
<center><span style="font-size:115%">'''Tout fonctionne correctement, on peut passer en mode Production et demander un certificat officiel.'''</span></center>
=== 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
<span style="color:blue"># INFO: Using main config file /etc/dehydrated/config</span>
+ <span style="color:red">Generating account key</span>...
+ <span style="color:red">Registering account key with ACME server</span>...
Processing micronator-101.org with alternative names: ftp.micronator-101.org mail.micronator-101.org proxy.micronator-101.org wpad.micronator-101.org www.micronator-101.org odoo.micronator-101.org ftp.odoo.micronator-101.org mail.odoo.micronator-101.org proxy.odoo.micronator-101.org wpad.odoo.micronator-101.org www.odoo.micronator-101.org
+ Checking domain name(s) of existing cert... unchanged.
+ Checking expire date of existing cert...
+ Valid till Sep 27 18:18:24 2018 GMT <span style="color:red">(Longer than 30 days). Ignoring because renew was forced!</span>
+ Signing domains...
+ <span style="color:red">Generating private key</span>...
+ Generating signing request...
+ Requesting challenge for micronator-101.org...
...
+ <span style="color:red">Requesting certificate</span>...
+ Checking certificate...
+ Done!
+ <span style="color:red">Creating fullchain.pem</span>...
+ Using cached chain!
Set up <span style="color:red">modSSL</span> db keys
<span style="color:red">Signal events</span>
All complete
+ <span style="color:Blue">Done!</span>
Si cette demande a réussie, félicitations! Vous avez obtenu un certificat TLS officiel et valide qui se renouvellera automatiquement à perpétuité.
[[Image:Icone-SeTirerDembarrasAPT.png|25px]] Si vous recevez l'erreur ci-dessous, simplement relancer la demande.
{| class="wikitable" style="width: 80%; background-color:#FFEED9;"
|- style="vertical-align:top;font-family: Courier New;"
|<nowiki>#</nowiki> INFO: Using main config file /etc/dehydrated/config
<span style="color:red">ERROR: Problem connecting to server</span> (get for https://acme-v01.api.letsencrypt.org/directory; <span style="color:red">curl returned with 6</span>)
|}
=== 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/]. Soumettez votre nom de domaine pour vous assurer que le nouveau certificat fonctionne correctement.
Entrez le nom de votre domaine: '''micronator-101.org''' > Submit.
<center>
{| class="wikitable"
|- style="vertical-align:top;"
|[[Image:odoo-11-HTTPS-016-QualsysHome.png|center|top|450px|border]]
||[[Image:odoo-11-HTTPS-017-QualsysResultat.png|center|top|450px|border]]
|}
</center>
<center>
{| style="background: {{{color|#FFEED9}}}; border: 1px dashed; width:60%"
|<div style="text-align:center;">This server does not support Forward Secrecy with the reference browsers. Grade capped to B.</div>
|}
[[Image:Icone-NoteAPT.png|25px]] Cette remarque peut être ignorée car, le Serveur SME ne supporte pas <code>Forward Secrecy</code>.
</center>
= Connexion sécuritaire SSL (https) à Odoo =
Lorsqu'on se logue à '''Odoo''', sans utiliser une connexion sécuritaire '''TLS'''<ref name="ftn2">'''Transport Layer Security''' ''(TLS)'' ou Sécurité de la couche de transport et son prédécesseur, Secure Sockets Layer ''(SSL)'', sont des protocoles de sécurisation des échanges sur Internet. Le protocole SSL a été développé à l'origine par Netscape. L'IETF en a poursuivi le développement en le rebaptisant Transport Layer Security ''(TLS)''. On parle parfois de SSL/TLS pour désigner indifféremment SSL ou TLS.
''Référence'': https://fr.wikipedia.org/wiki/Transport_Layer_Security. </ref>, notre mot de passe est transmis en clair sur le réseau.
[[Image:odoo-11-HTTPS-000-NouveauDom.png|top|right|200px|border]]
Pour remédier à la situation:
# Nous avons déjà ajouté le sous-domaine <span style="color:Blue">odoo.micronator-101.org</span>.
# À l'aide d'un gabarit personnalisé, nous allons rediriger les accès à <span style="color:Blue">odoo.micronator-101.org</span> et les contraindre à utiliser une connexion sécurisée TLS vers le port 8069.
=== Redirection ===
'''Gabarit personnalisé'''
Vu qu'on ne doit pas modifier directement un fichier de configuration, nous allons créer un gabarit personnalisé pour accomplir les modifications nécessaires. Ainsi, lorsqu'on mettra le Serveur SME à jour, les modifications seront conservées.
'''Copie du fragment à modifier'''
Le fragment de la configuration d'Apache à modifier est le fichier: <code>25SSLDirectives</code>. Ce fichier se trouve dans le répertoire: <code>/etc/e-smith/<u>templates</u>/etc/httpd/conf/httpd.conf/VirtualHosts</code>.
Nous devons créer un répertoire qui contiendra la copie de ce fragment qu'on pourra ainsi modifier.
# mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts
On copie le fragment original vers le gabarit personnalisé.
# cp /etc/e-smith/<span style="color:red">templates</span>/etc/httpd/conf/httpd.conf/VirtualHosts/25SSLDirectives <span style="color:red">\</span>
/etc/e-smith/<span style="color:red">templates-custom</span>/etc/httpd/conf/httpd.conf/VirtualHosts
On vérifie.
# ls -ls /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts
total 4
4 -rw-r--r-- 1 root root 196 7 sept. 22:13 <span style="color:red">25SSLDirectives</span>
'''Modification du fichier du gabarit personnalisé'''
Fichier original.
{| class="wikitable" style="width: 80%; background-color:#FFEED9;"
|- style="vertical-align:top;font-family: Courier New;"
|
<nowiki>{</nowiki><br>
<nowiki> return " # skipping SSL directives\n" unless $port eq "443";</nowiki><br><br>
<nowiki> return "" unless $modSSL{'status'} eq 'enabled';</nowiki><br><br>
<nowiki> $OUT = <<SSL_END;</nowiki><br>
<nowiki> # SSL Directives</nowiki><br>
<nowiki> SSLEngine on</nowiki><br>
SSL_END</nowiki></nowiki><br>
<nowiki>}</nowiki>
|}
[[Image:Icone-NoteAPT.png|25px]] On peut modifier le contenu du fichier du gabarit personnalisé avec <code>vi</code> , <code>Notepad++</code> ... ou utiliser la commande ci-dessous.
[[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/VirtualHosts/25SSLDirectives <<'EOT'
{
if ( $port eq "80" && $virtualHost eq "odoo.micronator-101.org")
{
$OUT .= " \n";
$OUT .= " # Pour la redirection d'Odoo.\n";
$OUT .= " # Michel-André / 2018-09-08_14h05\n";
$OUT .= " Redirect / https://odoo.micronator-101.org/\n";
}
return " # skipping SSL directives\n" unless $port eq "443";
return "" unless $modSSL{'status'} eq 'enabled';
$OUT = <<SSL_END;
# SSL Directives
SSLEngine on
<span style="color:red">SSL_END</span>
if ( $virtualHost eq "odoo.micronator-101.org" )
{
$OUT .= " \n";
$OUT .= " # Pour la redirection vers le port 8069\n";
$OUT .= " # Michel-André / 2018-09-08_14h05\n";
$OUT .= " ProxyPass / http://localhost:8069/ retry=0\n";
$OUT .= " ProxyPassReverse / http://localhost:8069/\n";
}
}
EOT
[[fichier:015-IconeASurveiller.png|left|caption|32px]] La ligne <span style="color:red">SSL_END</span> doit obligatoirement débuter sur la première colonne.
On développe <code>httpd.conf</code> pour qu'il lise le gabarit personnalisé et qu'il l'intègre dans sa configuration.
# expand-template /etc/httpd/conf/httpd.conf
On vérifie le fichier de configuration de <code>httpd.conf</code> pour s'assurer que le gabarit personnalisé a bien été intégré.
# cat /etc/httpd/conf/httpd.conf | grep "Pour la redirection"
<span style="color:blue"># Pour la redirection d'Odoo.
# Pour la redirection vers le port 8069</span>
'''Redémarrage des démons'''
On redémarre le démon <code>httpd</code>.
# /etc/rc.d/init.d/httpd-e-smith restart
On redémarre le démon <code>odoo</code>.
# /etc/rc.d/init.d/odoo restart
=== Vérification ===
[[Image:Icone-AsurveillerAPT.png|25px]] On supprime l'historique de notre navigateur.
'''''Connexion à Server Manager'''''
On s'assure qu'on peut toujours accéder au gestionnaire Server Manager en allant à: https://www.micronator-101.org/server-manager.
<center>
{| class="wikitable"
|- style="vertical-align:top;"
|[[Image:odoo-11-HTTPS-018-SMlogin.png|center|top|250px|border]]
||[[Image:odoo-11-HTTPS-019-SMBienvenue.png|center|top|700px|border]]
|}
</center>
<center>'''La connexion vers le site <span style="color:blue">micronator-101.org</span> n'est pas redirigée et on peut accéder au gestionnaire du serveur.'''</center>
'''''Connexion à Odoo'''''
On se rend sur notre site Odoo en spécifiant toujours <span style="color:blue"><u>odoo.</u>micronator-101.org</span>:
<div style="font-family: Courier New;">
* http://<span style="color:blue"><u>odoo.</u>micronator-101.org</span>
* http://<span style="color:red">www</span>.<span style="color:blue"><u>odoo.</u>micronator-101.org</span>
* http<span style="color:red">s</span>://<span style="color:blue"><u>odoo.</u>micronator-101.org</span>
* http<span style="color:red">s</span>://<span style="color:red">www</span>.<span style="color:blue"><u>odoo.</u>micronator-101.org</span>
* <span style="color:blue"><u>odoo.</u>micronator-101.org</span>
</div>
Le résultat est toujours le même: https://odoo.micronator-101.org/web/login. On est automatiquement redirigé vers la page de connexion d'Odoo et le cadenas est <span style="color:DarkGreen"><u>'''vert'''</u></span>.
[[Image:Icone-NoteAPT.png|25px]] Vu que notre certificat a été émis par '''Let's Encrypt Authority X3''', une véritable autorité de certification reconnue, le serveur Web d'Odoo a accepté le certificat et a émis une connexion sécurisée.
<center>On se logue, la page d'accueil d'Odoo apparaît et le cadenas est toujours <span style="color:DarkGreen"><u>'''vert'''</u></span>.</center>
<center>
{| class="wikitable" style="width: 80%; background-color:#ffffff;"
|- style="vertical-align:top;"
|[[Image:odoo-11-HTTPS-020-OdooLogin.png|center|top|300px|border]]
||[[Image:odoo-11-HTTPS-021-OdooAccueil.png|center|top|700px|border]]
|}
</center>
<center><big>'''Notre connexion à Odoo est maintenant toujours sécurisée. (CQFD)'''</big></center>
'''''Certificat'''''
<center>
{| class="wikitable" style="width: 95%;"
|- style="vertical-align:bottom;font-family: Courier New;text-align: left;"
|
On clique le cadenas puis ">".
||
Plus d'informations.
||
Afficher le certificat.
||<nowiki>-</nowiki> Le certificat a été émis par Let's Encrypt Authority X3 qui est une autorité de certification reconnue.
<nowiki>-</nowiki> Détails.
|- style="vertical-align:top;"
|[[Image:odoo-11-HTTPS-022-CertifCadenas.png|center|top|200px|border]]
||[[Image:odoo-11-HTTPS-023-CertifPlusInfo.png|center|top|250px|border]]
||[[Image:odoo-11-HTTPS-024-CertifEmisPar.png|center|top|250px|border]]
||[[Image:odoo-11-HTTPS-025-CertifPasAvant.png|center|top|350px|border]]
|}
</center>
<center>
{| class="wikitable" style="width: 80%;"
|- style="vertical-align:bottom;font-family: Courier New;text-align: left;"
|Pas avant.
|Pas après ''(valide pour 90 jours)''.
|Nos CNAME sont tous là.
|- style="vertical-align:top;"
|[[Image:odoo-11-HTTPS-025-CertifPasAvant.png|center|top|350px|border]]
||[[Image:odoo-11-HTTPS-026-CertifPasApres.png|center|top|350px|border]]
||[[Image:odoo-11-HTTPS-027-CertifCNAME.png|center|top|350px|border]]
|}
</center>
'''''Fichier index de l'i-bay Primary'''''
On visite la page: http://www.micronator-101.org. On peut aussi utiliser https.
[[Image:odoo-11-HTTPS-008-PageDeLaSociete.png|center|top|400px|border]]
<center>''La page décrivant notre société''.</center>
=== Mise en garde ===
[[Image:Icone-AsurveillerAPT.png|25px]] Il ne faut plus spécifier le port <span style="color:red">''':8069'''</span> car, vous obtiendriez alors l'erreur de connexion suivante: <code>SSL_ERROR_RX_RECORD_TOO_LONG</code>.
<center>[[Image:Odoo-11-HTTPS-008A-ErreurDePort8069.png|top|center|700px|border]]</center>
<center><span style="font-size:115%">'''L'accès au gestionnaire Server Manager est toujours possible.'''</span></center>
<center><span style="font-size:115%">'''Les connexions vers Odoo sont redirigées vers des connexions SSL/TLS.'''</span></center>
<center><span style="font-size:115%">'''L'accès à micronator-101.org affiche une page décrivant notre société.'''</span></center>
= Certificat standard SME =
On veut recréer un certificat original émis et certifié par le Serveur SME-9.x lui-même.
Après s'être logué avec l'utilisateur <span style="color:red">root</span>, on devrait être dans le répertoire personnel de ce dernier.
# pwd
<span style="color:red">root</span>
'''Création d'un répertoire de sauvegarde'''
# mkdir dehydrated
On se rend dans le répertoire de sauvegarde.
# cd 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
<span style="color:Blue">SSLCertificateChainFile</span> /etc/dehydrated/certs/micronator-101.org/<span style="color:red">chain.pem</span>
<span style="color:Blue">SSLCertificateFile</span> /etc/dehydrated/certs/micronator-101.org /<span style="color:red">cert.pem</span>
<span style="color:Blue">SSLCertificateKeyFile</span> /etc/dehydrated/certs/micronator-101.org /<span style="color:red">privkey.pem</span>
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 <span style="color:blue">odoo-11.micronator-101.org.pem</span>
Il n'est pas nécessaire de le faire, mais on sauvegarde quand même le fichier <code>pem</code>.
# cp /home/e-smith/ssl.pem/odoo-11.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 odoo-11.micronator-101.org.pem
'''Suppression de certaines propriétés de modSSL'''
On affiche les propriétés de <code>modSSL</code>.
# config show modSSL
modSSL=service
<span style="color:red">CertificateChainFile</span>=/etc/dehydrated/certs/micronator-101.org/chain.pem
TCPPort=443
access=public
<span style="color:red">crt</span>=/etc/dehydrated/certs/micronator-101.org /cert.pem
<span style="color:red">key</span>=/etc/dehydrated/certs/micronator-101.org /privkey.pem
status=enabled
On supprime la propriété <code>CertificateChainFile</code>.
# config delprop modSSL CertificateChainFile
On supprime la propriété <code>CommonName</code>.
# config delprop modSSL CommonName
On supprime la propriété <code>crt</code>.
# config delprop modSSL crt
On supprime la propriété <code>key</code>.
# config delprop modSSL key
À nouveau, on vérifie les propriétés de <code>modSSL</code>.
# config show modSSL
<span style="color:blue">modSSL=service
TCPPort=443
access=public
status=enabled</span>
'''Suppression des paramètres de tous les anciens certificats'''
[[fichier:015-IconeASurveiller.png|left|caption|32px]]On utilise la très dangereuse commande <code>rm -rf</code> pour supprimer tous les anciens fichiers: <code>.crt</code>, <code>.key</code> et <code>.pem</code> du Serveur SME.
''.crt''
# rm -rf /home/e-smith/ssl.crt/*
''.key''
# rm -rf /home/e-smith/ssl.key/*
''.pem''
# rm -rf /home/e-smith/ssl.pem/*
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 ci-dessous. 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;"
|
signal-event domain-modify; \<br>
signal-event email-update; \<br>
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:odoo-11-HTTPS-029-CerttifSMEPostUpgrade.png|top|right|450px|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 <code>modSSL</code>, le serveur réamorcera pour activer tous les nouveaux paramètres et prendra environ une minute pour redevenir actif.
<br>
<br>
<br>
<br>
<br>
<br>
<br>
'''Vérification'''
'''''Console du serveur'''''
On affiche la date.
# date
ven. <span style="color:red">mars 3 18:30:02</span> EST 2017
Fichier <code>pem</code>.
# ls -ls /home/e-smith/ssl.pem/
total 4
4 -rw-r--r-- 1 root root 3564 <span style="color:red">3 mars 18:23</span> odoo-11.micronator-101.com.pem
Le fichier <code>pem</code> vient tout juste d'être recréé depuis quelques minutes seulement.
'''''Navigateur Web'''''
On se rend au site: https://www.micronator-101.com.
Firefox affiche un écran d'avertissement. Avancé > Ajouter une exception... > Voir... > onglet Détails > Validité > Pas avant.
[[Image:odoo-11-HTTPS-030-CerttifSMEDetails.png|top|left|300px|border]]
Le certificat est au nom de: ''odoo-11.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 les fenêtres et ajouter l'exception.
Le nouveau certificat, émis et certifié par le Serveur SME lui-même, est fonctionnel.
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<span style="font-size:120%">'''Mot de la fin'''</span>
[[Image:Icone-NoteAPT.png|25px]] La prochaine marche à suivre décrira les étapes pour créer un site de test/développement virtuel pour Odoo-11.
[[Image:Odoo-11-BanniereDeLaVictoire-APT.png|caption|36px]] Victoire totale, hissons la bannière de la victoire.
<br>
<br>
----
<references/>
[[Category:Howto]] [[Category:Howto/fr]]
