Difference between revisions of "Odoo-11 & HTTPS"
Michelandre (talk | contribs) (RC-001) |
Michelandre (talk | contribs) m (Michelandre moved page Odoo & HTTPS to Odoo-11 & HTTPS: Pour être compatible avec la première marche à suivre d'Odoo-11) |
Revision as of 03:08, 12 September 2018
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.
But final
Pour le présent document, sur le serveur odoo-11.micronator-101.org, nous avons installé Fail2ban et suivi les mêmes procédures qu'auparavant pour une nouvelle installation d'Odoo-11.
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/.
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%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. La connaissance d'une clé ne permet pas de déduire l'autre.
Échange de clés Diffie-Hellman
Référence: https://fr.wikipedia.org/wiki/%C3%89change_de_cl%C3%A9s_Diffie-Hellman.
En cryptographie, l'échange de clés Diffie-Hellman, du nom de ses auteurs Whitfield Diffie et Martin Hellman, est une méthode par laquelle deux agents nommés conventionnellement Alice et Bob peuvent se mettre d'accord sur un nombre (qu'ils peuvent utiliser comme clé pour chiffrer la conversation suivante) sans qu'un troisième agent appelé Ève puisse découvrir le nombre, même en ayant écouté tous leurs échanges.
Somme de contrôle
Référence: https://fr.wikipedia.org/wiki/Somme_de_contr%C3%B4le.
La somme de contrôle 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.
Le nonce est un nombre arbitraire, à usage unique, utilisé pour signer un ensemble de données d'une communication électronique. Il permet notamment d'éviter les attaques de type "Attaque par rejeu".
Condensat
Référence: http://gdt.oqlf.gouv.qc.ca.
Séquence de caractères alphanumériques de longueur fixe qui représente le contenu d'un message, sans le révéler, dont la valeur unique est produite par un algorithme de hachage et qu'on utilise pour créer une signature numérique.
Empreinte numérique
Référence: http://gdt.oqlf.gouv.qc.ca/ficheOqlf.aspx?Id_Fiche=8371028.
L'empreinte numérique sert à authentifier un message ou à vérifier l'identité de son auteur.
Une empreinte numérique a toujours la même taille, quelle que soit la longueur du message initial. À l'instar d'une empreinte digitale, deux messages différents n'ont pas la même empreinte numérique. Après avoir calculé l'empreinte de son message, l'expéditeur la chiffre avec sa clé privée. Il envoie ensuite cette signature en même temps que le reste de son message. Lorsque le destinataire reçoit cette empreinte chiffrée, il la déchiffre grâce à la clé publique de l'expéditeur. Le destinataire compare alors le résultat obtenu avec le résultat qu'il calcule lui-même à partir du message reçu. Si les deux empreintes numériques sont identiques, il est assuré à la fois de l'identité de l'expéditeur et de l'intégrité du message.
Homme-du-milieu
Référence: https://fr.wikipedia.org/wiki/Attaque_de_l'homme_du_milieu.
L'attaque de l'homme-du-milieu (HdM) ou man-in-the-middle attack (MITM) est une attaque qui a pour but d'intercepter les communications entre deux parties, sans que ni l'une ni l'autre ne puisse se douter que le canal de communication entre elles a été compromis. Le canal le plus courant est une connexion à 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_%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.
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.
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'identité du propriétaire du site Internet.
- Pour qui?: Les certificats DV seront utilisés pour les sites Internet qui ont juste besoin d'une connexion https (connexion sécurisée) ou une connexion sécurisée pour webmail, intranet, citrix secure gateway et ainsi de suite. Ce Certificat SSL est parfait dans le cas où quelqu'un a besoin immédiatement d'un certificat.
SAN et Wildcard
Référence: https://www.thawte.fr/ssl/san-uc-ssl-certificates/#.
Référence: https://www.thawte.fr/ssl/wildcard-ssl-certificates/.
Que signifient les termes SAN (Subject Alternative Names) et UC (Unified Communications)?
Les certificats qui utilisent les SAN sont des outils puissants qui permettent de sécuriser plusieurs noms de domaines de façon efficace et économique. Les certificats SSL Thawte permettent de sécuriser jusqu'à 25 noms de domaines complets avec un seul certificat utilisant les SAN. Les noms de certificats qui utilisent les SAN sont également appelés certificats UC (Unified Communications ou communications unifiées) et sont utilisés avec Microsoft Exchange Server 2007, Microsoft Exchange Server 2010 et Microsoft Communications Server. L'objectif d'un certificat avec SAN est le même que n'importe quel autre certificat; il permet à un serveur de définir son identité et d'établir une communication sécurisée. Les certificats avec SAN procurent également un champ SAN (Subject Alternative Name) qui permet de protéger les noms de domaines additionnels avec un seul certificat.
- Pourquoi ai-je besoin d'un SAN?
Au lieu d'acheter des certificats individuels pour chaque nom de domaine, vous pouvez ajouter des noms de domaines dans les champs SAN pour partager le même certificat. Non seulement l'entreprise économise le coût d'achat de certificats individuels mais, elle gagne également du temps en évitant d'avoir à gérer plusieurs certificats.
Par exemple, un seul certificat avec prise en charge des SAN serait capable de sécuriser les noms de domaines suivants:
* www.macompagnie.com
* mail.macompagnie.com
* macompagnie.com
* www.toto.net
* mail.toto.net
* toto.net
- Certificat SAN vs certificat Wildcard
Les certificats Wildcard sont similaires aux certificats SAN avec quelques restrictions. Avec un certificat Wildcard, vous pouvez sécuriser plusieurs sous-domaines avec un seul domaine racine. Par exemple, si vous avez un certificat Wildcard pour www.macompagnie.com, il sécurise également intranet.macompagnie.com et email.macompagnie.com avec le même certificat.
Cependant, vous ne pourrez pas sécuriser plusieurs domaines uniques comme www.macompagnie.net et www.toto.org.
- Certificats SSL Wildcard
Sécurisation de plusieurs sous-domaines sur un seul serveur.
Les certificats SSL Wildcard Thawte sécurisent plusieurs sous-domaines avec un certificat SSL unique, réduisant ainsi le temps et le coût de gestion. L'utilisation de la notation Wildcard (un astérisque et un point avant votre nom de domaine) vous permet d'étendre la sécurité à différents sous-domaines, basés sur le nom de votre domaine de niveau supérieur.
CNAME
Référence: http://www.networking4all.com/fr/support/noms+de+domaine/dns/archives+cname/. (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)).
- Exemple
Vous avez un site Web avec le nom de domaine monsite.quebec. Ce nom de domaine est connecté à un enregistrement A qui traduit le nom de domaine à l'adresse IP appropriée, par exemple: 11.22.33.44.
Vous avez aussi plusieurs sous-domaines, comme coquille.monsite.quebec, email.monsite.quebec, etc... et vous souhaitez que ces sous-domaines pointent à votre nom de domaine principal monsite.quebec. Au lieu de créer des enregistrements A pour chaque sous-domaine et les lier à l'adresse IP de votre domaine principal, vous créez un alias (enregistrement CNAME) pour chacun d'eux pour obtenir la figure ci-contre. Dans le cas où votre adresse IP change, vous devez seulement éditer un enregistrement A et tous les sous-domaines suivent automatiquement du fait des CNAME pointant vers le domaine principal.
Si 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.
La facilité d'utilisation promise par Let's Encrypt repose principalement sur le client dehydrated et sur l'automatisation qu'il propose.
Le client dehydrated s'occupe (ou peut s'occuper) de deux tâches distinctes:
- obtenir un certificat pour le(s) domaine(s) souhaité(s), et
- installer le certificat obtenu.
Pour obtenir un certificat, le client dehydrated:
- génère une paire de clefs et une demande de signature de certificat (Certificate Signing Request: CSR);
- envoie la demande à un serveur ACME;
- répond aux défis d'authentification (challenges) posés par la CA, permettant au demandeur de prouver qu'il contrôle le(s) domaine(s) demandé(s);
- reçoit le certificat signé en retour.
Le client dehydrated 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 dehydrated garde aussi une trace des certificats obtenus. Lancé à intervalle régulier, il répétera automatiquement la procédure s'il détecte qu'un certificat est sur le point d'expirer.
En définitive, le but est que l'administrateur puisse mettre en place TLS en une seule commande, avant d'oublier jusqu'à l'existence même du client dehydrated.
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 dehydrated.
Transparence des certificats
Une partie de la mission de transparence de la société Let's Encrypt comprend la divulgation publique des certificats qu'elle délivre via Certificate Transparency. L'adresse courriel n'est pas divulguée publiquement.
Limites
Référence: 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
* Certificats par domaine signifie 5 émissions de certificat et non pas combien de domaines au sein d'un certificat multi-domaines SAN.
** Un certificat multi-domaines SAN ayant domaine1.com, www.domaine1.com, domaine2.com, www.domaine2.com, toto.info 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?
*** 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[1])
Lorsqu'on veut tester dehydrated, c'est l'option staging (défini par la ligne CA="https://acme-staging.api.letsencrypt.org/directory") qui est utilisée dans le fichier de configuration config.
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 dehydrated utilise la CA officielle, Let’s Encrypt Authority X3.
- CA de TEST
Un certificat de test ne sera pas signé directement par Let's Encrypt mais par sa CA de tests, Fake LE Intermediate X1. Ce certificat de test ne sera pas reconnu par la plupart des navigateurs et affichera une erreur. La communication sera tout de même chiffrée.
La CA acme-staging est l'émettrice pour Fake LE Intermediate X1.
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 Let’s Encrypt Authority X3.
Toutefois, la contribution Let's Encrypt insère quand même, dans le fichier de configuration, la ligne:
| CA="https://acme-v01.api.letsencrypt.org/directory" |
Pour une demande de certificat, il est inutile de spécifier un fichier de configuration car, par défaut, c'est le fichier config qui est utilisé.
Fichier config de la configuration Production.
| #!/bin/bash WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge" |
- Certificat de TEST
Le fichier de configuration pour une demande certificat de test doit spécifier la CA acme-staging qui seule, émet ces certificats de test pour Let's Encrypt.
| #!/bin/bash WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge" |
Clé de compte Let's Encrypt
La clé de compte privkey-1234567890.pem est stockée dans le répertoire /etc/dehydrated/certs/nom-du-domaine/. La clé de compte account_key.pem est stockée dans un sous-répertoire de /etc/dehydrated/accounts/.
Contenu du répertoire /etc/dehydrated/accounts/:
- 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
CA="https://acme...dans le fichier de configuration/etc/dehydrated/config.
La clé de compte est utilisée exclusivement par le client dehydrated et uniquement pour:
- créer un compte usager chez la CA,
- signer les domaines et
- chiffrer la communication entre le Serveur SME et la CA.
Que ce soit une demande pour un certificat de TEST ou OFFICIEL, la clé de compte est toujours appelé account_key.pem.
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 dehydrated.
# /usr/bin/dehydrated --help
En cas de trouble majeur avec un certificat
Advenant un trouble majeur avec un certificat et que vous vouliez en recréer un original, émis et certifié par le Serveur SME lui-même, veillez consulter le chapitre: Certificat standard SME.
Préparation du serveur
Ajout d'un nouveau domaine
Si nous redirigeons tous les accès de notre serveur odoo-11.micronator-101.org 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 domaine odoo.micronator-101.org et rediriger tous les accès (http et https), pour ce domaine seulement, en forçant une connexion sécurisée vers le port 8069.
On utilise odoo pour le domaine et odoo-11 pour le serveur.
Création du domaine
| Server Manager > Domaines > Ajouter un domaine. | - Entrer les informations telles que ci-dessous.
- Ajouter. |
On s'assure du succès de l'opération. |
 |
 |
 |
CNAME
Nous avons créer un nouveau domaine, nous ajoutons donc les CNAME suivants chez le régistraire de notre domaine micronator-101.org: odoo , ftp.odoo , mail.odoo , proxy.odoo , wpad.odoo et www.odoo.
Fichier index de l'i-bay Primary
Vu que nous allons réglé la redirection, celle dans le fichier index.html 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.
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 https et, vu que le certificat a été émis par une autorité de certification reconnue, le cadenas sera vert.
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.
Référence: 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 smeserver-letsencrypt.
# yum install -y --enablerepo=smecontribs smeserver-letsencrypt Modules complémentaires chargés : fastestmirror, smeserver ... Installation de 2 paquet(s) Taille totale des téléchargements : 56 k Taille d'installation : 98 k ... Installé: smeserver-letsencrypt.noarch 0:0.4-4 Dépendance(s) installée(s) : dehydrated.noarch 0:0.5.0-3.el6.sme Terminé ! ============================================================== WARNING: You now need to run BOTH of the following commands to ensure consistent system state: signal-event post-upgrade; signal-event reboot You should run these commands unless you are certain that yum made no changes to your system. ==============================================================
On signale les changements.
# signal-event post-upgrade ; signal-event reboot
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.
| # yum update -y --enablerepo=smecontribs smeserver-letsencrypt dehydrated Modules complémentaires chargés : fastestmirror, smeserver |
S'il y avait une mise à jour, cette commande l'installerait automatiquement.
Signalisation des changements
Si vous aviez fait une mise à jour, vous devriez signaler les changements.
| # signal-event post-upgrade ; 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 ftp.micronator-101.org=host ftp.odoo.micronator-101.org=host mail.micronator-101.org=host mail.odoo.micronator-101.org=host odoo-11.micronator-101.org=host odoo-11.odoo.micronator-101.org=host proxy.micronator-101.org=host proxy.odoo.micronator-101.org=host wpad.micronator-101.org=host wpad.odoo.micronator-101.org=host www.micronator-101.org=host www.odoo.micronator-101.org=host
Si certains de vos défis sont renvoyés sans erreur mais, que certains échouent, il est possible que vous n'ayez pas d'enregistrements DNS A, MX ou CNAME pour tous les noms d'hôtes que vous avez ajoutés à votre certificat. Lorsque Let's Encrypt lance les défis pour une liste de noms d'hôtes et qu'un de ceux-ci ne répond pas, le défi échoue et le certificat n'est pas généré.
La cause principale des défis non relevés est qu'il n'existe pas d'enregistrements DNS pour tous les noms d'hôtes ajoutés au certificat. La plupart des administrateurs de systèmes ne créent pas tous les enregistrements DNS nécessaires et le certificat n'est pas généré.
Ci-contre, les noms d'hôtes pour le "sous-domaine" odoo.micronator-101.org chez le régistraire du domaine micronator-101.org.
Si on veut obtenir un certificat pour tous (all) les domaines et tous les noms d'hôtes.
| # config setprop letsencrypt configure all |
La commande config setprop letsencrypt configure all est susceptible de provoquer une erreur de défi.
Nous voulons tous les noms d'hôtes affichés par la commande db hosts show | grep .org, sauf ceux des noms des serveurs: odoo-11.micronator-101.org et odoo-11.odoo.micronator-101.org 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 configure à none et ensuite on ajoute les domaines et les noms d'hôtes désirés.
# config setprop letsencrypt configure none
Domaines
On inclut micronator-101.org.
# db domains setprop micronator-101.org letsencryptSSLcert enabled
On inclut odoo.micronator-101.org.
# db domains setprop odoo.micronator-101.org letsencryptSSLcert enabled
On vérifie.
# db domains show micronator-101.org=domain Content=Primary Description=Primary domain Nameservers=localhost Removable=no SystemPrimaryDomain=yes letsencryptSSLcert=enabled odoo.micronator-101.org=domain Content=Primary Description=Pour odoo.mn-101.org Nameservers=internet letsencryptSSLcert=enabled
On voit que ces deux domaines seront inclus dans la demande du certificat à Let's Encrypt car, leur définition contient la ligne: letsencryptSSLcert=enabled.
Hôtes
On inclut tous les hôtes suivants.
ftp
# db hosts setprop ftp.micronator-101.org letsencryptSSLcert enabled
# db hosts setprop ftp.odoo.micronator-101.org letsencryptSSLcert enabled
# db hosts setprop mail.micronator-101.org letsencryptSSLcert enabled
# db hosts setprop mail.odoo.micronator-101.org letsencryptSSLcert enabled
proxy
# db hosts setprop proxy.micronator-101.org letsencryptSSLcert enabled
# db hosts setprop proxy.odoo.micronator-101.org letsencryptSSLcert enabled
wpad
# db hosts setprop wpad.micronator-101.org letsencryptSSLcert enabled
# db hosts setprop wpad.odoo.micronator-101.org letsencryptSSLcert enabled
www
# db hosts setprop www.micronator-101.org letsencryptSSLcert enabled
# db hosts setprop www.odoo.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
Le domaine de messagerie spécifié n'a nul besoin de correspondre à l'un des domaines pour lesquels vous demandez un certificat.
# config setprop letsencrypt email admin@micronator.org
Longueur de la clé privée
Si vous ne voulez pas la valeur par défaut de 4096 bits, vous pouvez définir la longueur de la clé privée de votre certificat. Ceci ne devrait pas être nécessaire dans la plupart des cas mais; si vous le souhaitiez, il faudrait utiliser la commande ci-dessous pour ce faire.
| # config setprop letsencrypt keysize LONGUEUR-EN-BITS |
Termes et conditions
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.
Seulement si vous acceptez les termes et conditions de Let's Encrypt, lancez la commande ci-dessous.
# config setprop letsencrypt ACCEPT_TERMS yes
Activation du mode TEST
L'étape suivante consiste à activer le mode TEST. Ce mode va obtenir des certificats du serveur de TEST de Let's Encrypt. Les limites 5/7 (5 certificats par 7 jours) ne s'appliqueront pas. Toutes erreurs ou autres problèmes rencontrés ne vous empêchera pas, plus tard, d'obtenir votre certificat de Production.
On active le mode TEST.
# config setprop letsencrypt status test
On signale les changements. (Peut prendre plusieurs secondes.)
# signal-event console-save
Vérification
On vérifie si on est bien en mode TEST.
# cat /etc/dehydrated/config | grep CA
CA="https://acme-staging.api.letsencrypt.org/directory"
On vérifie l'adresse courriel.
# cat /etc/dehydrated/config | grep CONTACT CONTACT_EMAIL=admin@micronator.org
On vérifie les domaines et les hôtes.
# cat /etc/dehydrated/domains.txt
micronator-101.org 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
Tout le contenu du fichier domains.txt 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.
Le certificat sera émis au nom du premier domaine de la ligne; ici, ce sera micronator-101.org.
Lancement du script dehydrated
Vous pouvez maintenant exécuter le script dehydrated 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 # INFO: Using main config file /etc/dehydrated/config + 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 + Signing domains... + Creating new directory /etc/dehydrated/certs/micronator-101.org ... + Creating chain cache directory /etc/dehydrated/chains + Generating private key... + Generating signing request... + Requesting challenge for micronator-101.org... + Requesting challenge for ftp.micronator-101.org... + Requesting challenge for mail.micronator-101.org... + Requesting challenge for proxy.micronator-101.org... + Requesting challenge for wpad.micronator-101.org... + Requesting challenge for www.micronator-101.org... + Requesting challenge for odoo.micronator-101.org... + Requesting challenge for ftp.odoo.micronator-101.org... + Requesting challenge for mail.odoo.micronator-101.org... + Requesting challenge for proxy.odoo.micronator-101.org... + Requesting challenge for wpad.odoo.micronator-101.org... + Requesting challenge for www.odoo.micronator-101.org... + Responding to challenge for micronator-101.org... + Challenge is valid! + 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! + Requesting certificate... + Checking certificate... + Done! + Creating fullchain.pem... + Using cached chain! Set up modSSL db keys Signal events All complete + Done!
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
| 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. |
 |
 |
 |
 |
| - Certificat de test car, émis par Fake LE Intermediate XI.
- Détails. |
- Nom alternatif du sujet du certificat.
- Nos noms d'hôtes sont présents. |
Valide pour 90 jours. |
 |
 |
 |
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 -x est nécessaire pour forcer un nouveau certificat
# dehydrated -c -x # INFO: Using main config file /etc/dehydrated/config + 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 + Checking domain name(s) of existing cert... unchanged. + Checking expire date of existing cert... + Valid till Sep 27 18:18:24 2018 GMT (Longer than 30 days). Ignoring because renew was forced! + Signing domains... + Generating private key... + Generating signing request... + Requesting challenge for micronator-101.org... ... + Requesting certificate... + Checking certificate... + Done! + Creating fullchain.pem... + Using cached chain! Set up modSSL db keys Signal events All complete + Done!
Si cette demande a réussie, félicitations! Vous avez obtenu un certificat TLS officiel et valide qui se renouvellera automatiquement à perpétuité.
Si vous recevez l'erreur ci-dessous, simplement relancer la demande.
| # INFO: Using main config file /etc/dehydrated/config
ERROR: Problem connecting to server (get for https://acme-v01.api.letsencrypt.org/directory; curl returned with 6) |
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/. Soumettez votre nom de domaine pour vous assurer que le nouveau certificat fonctionne correctement.
Entrez le nom de votre domaine: micronator-101.org > Submit.
 |
 |
This server does not support Forward Secrecy with the reference browsers. Grade capped to B.
|
Cette remarque peut être ignorée car, le Serveur SME ne supporte pas Forward Secrecy.
Connexion sécuritaire SSL (https) à Odoo
Lorsqu'on se logue à Odoo, sans utiliser une connexion sécuritaire TLS[2], notre mot de passe est transmis en clair sur le réseau.
Pour remédier à la situation:
- Nous avons déjà ajouté le sous-domaine odoo.micronator-101.org.
- À l'aide d'un gabarit personnalisé, nous allons rediriger les accès à odoo.micronator-101.org 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: 25SSLDirectives. Ce fichier se trouve dans le répertoire: /etc/e-smith/templates/etc/httpd/conf/httpd.conf/VirtualHosts.
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/templates/etc/httpd/conf/httpd.conf/VirtualHosts/25SSLDirectives \ /etc/e-smith/templates-custom/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 25SSLDirectives
Modification du fichier du gabarit personnalisé
Fichier original.
|
{ |
On peut modifier le contenu du fichier du gabarit personnalisé avec vi , Notepad++ ... ou utiliser la commande ci-dessous.
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
SSL_END
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
left|caption|32px La ligne SSL_END doit obligatoirement débuter sur la première colonne.
On développe httpd.conf 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 httpd.conf pour s'assurer que le gabarit personnalisé a bien été intégré.
# cat /etc/httpd/conf/httpd.conf | grep "Pour la redirection"
# Pour la redirection d'Odoo.
# Pour la redirection vers le port 8069
Redémarrage des démons
On redémarre le démon httpd.
# /etc/rc.d/init.d/httpd-e-smith restart
On redémarre le démon odoo.
# /etc/rc.d/init.d/odoo restart
Vérification
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.
 |
 |
Connexion à Odoo
On se rend sur notre site Odoo en spécifiant toujours odoo.micronator-101.org:
- http://odoo.micronator-101.org
- http://www.odoo.micronator-101.org
- https://odoo.micronator-101.org
- https://www.odoo.micronator-101.org
- odoo.micronator-101.org
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 vert.
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.
 |
 |
Certificat
|
On clique le cadenas puis ">". |
Plus d'informations. |
Afficher le certificat. |
- Le certificat a été émis par Let's Encrypt Authority X3 qui est une autorité de certification reconnue.
- Détails. |
 |
 |
 |
 |
| Pas avant. | Pas après (valide pour 90 jours). | Nos CNAME sont tous là. |
|
 |
 |
Fichier index de l'i-bay Primary
On visite la page: http://www.micronator-101.org. On peut aussi utiliser https.
Mise en garde
Il ne faut plus spécifier le port :8069 car, vous obtiendriez alors l'erreur de connexion suivante: SSL_ERROR_RX_RECORD_TOO_LONG.
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 root, on devrait être dans le répertoire personnel de ce dernier.
# pwd
root
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 SSLCertificateChainFile /etc/dehydrated/certs/micronator-101.org/chain.pem SSLCertificateFile /etc/dehydrated/certs/micronator-101.org /cert.pem SSLCertificateKeyFile /etc/dehydrated/certs/micronator-101.org /privkey.pem
On sauvegarde le fichier de la chaîne de certification.
# cp /etc/dehydrated/certs/micronator-101.com/chain.pem .
On sauvegarde le fichier du certificat.
# cp /etc/dehydrated/certs/micronator-101.com/cert.pem .
On sauvegarde le fichier de la clé privée.
# cp /etc/dehydrated/certs/micronator-101.com/privkey.pem .
On vérifie le fichier pem.
# ls -ls /home/e-smith/ssl.pem/
total 8
8 -rw-r--r-- 1 root root 7637 2 mars 20:46 odoo-11.micronator-101.org.pem
Il n'est pas nécessaire de le faire, mais on sauvegarde quand même le fichier pem.
# 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 modSSL.
# config show modSSL
modSSL=service
CertificateChainFile=/etc/dehydrated/certs/micronator-101.org/chain.pem
TCPPort=443
access=public
crt=/etc/dehydrated/certs/micronator-101.org /cert.pem
key=/etc/dehydrated/certs/micronator-101.org /privkey.pem
status=enabled
On supprime la propriété CertificateChainFile.
# config delprop modSSL CertificateChainFile
On supprime la propriété CommonName.
# config delprop modSSL CommonName
On supprime la propriété crt.
# config delprop modSSL crt
On supprime la propriété key.
# config delprop modSSL key
À nouveau, on vérifie les propriétés de modSSL.
# config show modSSL
modSSL=service
TCPPort=443
access=public
status=enabled
Suppression des paramètres de tous les anciens certificats
left|caption|32pxOn utilise la très dangereuse commande rm -rf pour supprimer tous les anciens fichiers: .crt, .key et .pem 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.
|
signal-event domain-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
Si on choisit le bloc de commandes avec réamorçage, la commande signal-event post-upgrade mettra à jour les paramètres de configuration de modSSL, le serveur réamorcera pour activer tous les nouveaux paramètres et prendra environ une minute pour redevenir actif.
Vérification
Console du serveur
On affiche la date.
# date
ven. mars 3 18:30:02 EST 2017
Fichier pem.
# ls -ls /home/e-smith/ssl.pem/
total 4
4 -rw-r--r-- 1 root root 3564 3 mars 18:23 odoo-11.micronator-101.com.pem
Le fichier pem 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.
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 pem (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.
Mot de la fin
La prochaine marche à suivre décrira les étapes pour créer un site de test/développement virtuel pour Odoo-11.
Victoire totale, hissons la bannière de la victoire.
- ↑ 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.
- ↑ 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.
