Odoo-11 & HTTPS

From SME Server
Jump to: navigation, search

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

Odoo-11-HTTPS-001-ButFinal.png

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.

Icone-NoteAPT.png  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%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.

Odoo-11-HTTPS-002-HommeDuMilieu.png

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

Odoo-11-HTTPS-003-CNAME-Coquille.png
  • 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.

Icone-AstuceAPT.png  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:

  1. obtenir un certificat pour le(s) domaine(s) souhaité(s), et
  2. 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.

Icone-SeTirerDembarrasAPT.png  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.

Icone-NoteAPT.png  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"

Icone-AstuceAPT.png  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"
CA="https://acme-v01.api.letsencrypt.org/directory"
BASEDIR="/etc/dehydrated"
CONTACT_EMAIL=admin@micronator.org
HOOK="/usr/bin/hook-script.sh"

PARAM_ACCEPT_TERMS="yes"

  • Certificat de TEST

Le fichier de configuration pour une demande certificat de test doit spécifier la CA 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"
CA="https://acme-staging.api.letsencrypt.org/directory"
BASEDIR="/etc/dehydrated"
CONTACT_EMAIL=admin@micronator.org
HOOK="/usr/bin/hook-script.sh"

PARAM_ACCEPT_TERMS="yes"

Clé de compte Let's Encrypt

Icone-NoteAPT.png  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.

Icone-NoteAPT.png  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

Odoo-11-HTTPS-000-NouveauDom.png

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.

Icone-NoteAPT.png  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.
Odoo-11-HTTPS-004-CreationDomaine.png
Odoo-11-HTTPS-005-CreationDomaine.png
Odoo-11-HTTPS-006-CreationDomaine.png

CNAME

Odoo-11-HTTPS-007-AjoutCNAME.png

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

Odoo-11-HTTPS-008-PageDeLaSociete.png

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

Icone-AsurveillerAPT.png  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
Configuration du processus de mise à jour
Loading mirror speeds from cached hostfile
* base: centos.ca-west.mirror.fullhost.io
* smeaddons: mirror.canada.pialasse.com
* smecontribs: mirror.canada.pialasse.com
* smeextras: mirror.canada.pialasse.com
* smeos: mirror.canada.pialasse.com
* smeupdates: mirror.canada.pialasse.com
* updates: centos.mirror.vexxhost.com
Aucun paquet marqué pour mise à jour

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

Signalisation des changements

Si vous aviez fait une mise à jour, vous devriez signaler les changements.

# signal-event post-upgrade  ; 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

Icone-AsurveillerAPT.png  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é.

Odoo-11-HTTPS-007-AjoutCNAME.png

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

Icone-NoteAPT.png  La commande config setprop letsencrypt configure all est susceptible de provoquer une erreur de défi.

Icone-AsurveillerAPT.png  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

mail

# 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

Icone-NoteAPT.png  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

Icone-AsurveillerAPT.png  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.


Icone-AsurveillerAPT.png  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

Icone-SeTirerDembarrasAPT.png  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.

Icone-AstuceAPT.png  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.
Odoo-11-HTTPS-009-Verif-URL.png
Odoo-11-HTTPS-010-VerifCadenas.png
Odoo-11-HTTPS-011-VerifPlusInfo.png
Odoo-11-HTTPS-012-VerifAfficherCert.png


- Certificat de test car, émis par Fake LE Intermediate XI.

- Détails.

- Nom alternatif du sujet du cer­tificat.

- Nos noms d'hôtes sont présents.

Valide pour 90 jours.

Odoo-11-HTTPS-013-VerifEmisPar.png
Odoo-11-HTTPS-014-VerifNomAlter.png
Odoo-11-HTTPS-015-Verif90Jours.png
Tout fonctionne correctement, on peut passer en mode Production et demander un certificat officiel.


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

Icone-SeTirerDembarrasAPT.png  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.

Odoo-11-HTTPS-016-QualsysHome.png
Odoo-11-HTTPS-017-QualsysResultat.png
This server does not support Forward Secrecy with the reference browsers. Grade capped to B.

Icone-NoteAPT.png  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.

Odoo-11-HTTPS-000-NouveauDom.png

Pour remédier à la situation:

  1. Nous avons déjà ajouté le sous-domaine odoo.micronator-101.org.
  2. À 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.

{
    return "    # skipping SSL directives\n" unless $port eq "443";

    return "" unless $modSSL{'status'} eq 'enabled';

    $OUT = <<SSL_END;
    # SSL Directives
    SSLEngine on
SSL_END</nowiki></nowiki>
}


Icone-NoteAPT.png  On peut modifier le contenu du fichier du gabarit personnalisé avec vi ,  Notepad++ ... ou utiliser la commande ci-dessous.

Icone-AsurveillerAPT.png   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

Icone-AsurveillerAPT.png  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.

Odoo-11-HTTPS-018-SMlogin.png
Odoo-11-HTTPS-019-SMBienvenue.png
La connexion vers le site micronator-101.org n'est pas redirigée et on peut accéder au gestionnaire du serveur.

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.

Icone-NoteAPT.png  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.

On se logue, la page d'accueil d'Odoo apparaît et le cadenas est toujours vert.
Odoo-11-HTTPS-020-OdooLogin.png
Odoo-11-HTTPS-021-OdooAccueil.png
Notre connexion à Odoo est maintenant toujours sécurisée. (CQFD)


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.

Odoo-11-HTTPS-022-CertifCadenas.png
Odoo-11-HTTPS-023-CertifPlusInfo.png
Odoo-11-HTTPS-024-CertifEmisPar.png
Odoo-11-HTTPS-025-CertifPasAvant.png


Pas avant. Pas après (valide pour 90 jours). Nos CNAME sont tous là.
Odoo-11-HTTPS-025-CertifPasAvant.png
Odoo-11-HTTPS-026-CertifPasApres.png
Odoo-11-HTTPS-027-CertifCNAME.png


Fichier index de l'i-bay Primary

On visite la page: http://www.micronator-101.org. On peut aussi utiliser https.

Odoo-11-HTTPS-008-PageDeLaSociete.png
La page décrivant notre société.

Mise en garde

Icone-AsurveillerAPT.png  Il ne faut plus spécifier le port :8069 car, vous obtiendriez alors l'erreur de connexion suivante: SSL_ERROR_RX_RECORD_TOO_LONG.

Odoo-11-HTTPS-008A-ErreurDePort8069.png


L'accès au gestionnaire Server Manager est toujours possible.
Les connexions vers Odoo sont redirigées vers des connexions SSL/TLS.
L'accès à micronator-101.org affiche une page décrivant notre société.


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; \
signal-event email-update; \
signal-event ibay-modify

  • Si on veut réamorcer, on applique les changements en signalant une mise à jour et un réamorçage.
# signal-event post-upgrade ; signal-event reboot
Odoo-11-HTTPS-029-CerttifSMEPostUpgrade.png

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.

Odoo-11-HTTPS-030-CerttifSMEDetails.png

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

Pour la suite de cette marche à suivre, voir: https://wiki.contribs.org/Odoo-11_%26_serveur_de_test/dev.



Particularités de ce document

Avertissement

Bien que nous utilisions ici un vocabulaire issu des sciences informatiques, nous ne prétendons nullement à la précision technique de tous nos propos dans ce domaine.


Notes au lecteur

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


Conventions

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


Les liens de référence Internet sont en bleu de même que ceux intra-document mais, ces derniers débute par un " # ".

Icone-SeTirerDembarrasAPT.png  Manipulation, truc ou ruse pour se tirer d’embarras.

Icone-AstuceAPT.png  Une recommandation ou astuce.

Icone-NoteAPT.png  Une note.

Icone-AsurveillerAPT.png  Une étape, note ou procédure à surveiller.

Icone-DangerAPT.png  Danger pour la sécurité du système.

IconePlusieursLignesAPT.png  Indique que la commande est sur une seule ligne. Pour ce document en PDF, il faudra copier la commande entière dans un éditeur de texte ASCII tel que NotePad++ et la mettre sur une seule ligne avant de la copier à la console.

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

Commande à exécuter si ce n'est déjà fait.
Commande indiquée à titre d'information seulement.



Composants du Cours SME-101

Cours-SME-101-000-DiagParIcone-A-5-APT.png

Cours SME-101

Après avoir suivi le cours SME-101, l'Étudiant possédera un site de Commerce en ligne fiable et hautement sécuritaire.


De plus, il pourra utiliser un clone de son site, sur un Serveur SME virtuel sur sa station de travail, pour tester de nouvelles extensions et applications sans compromettre la sécurité ou l'intégrité de son site en ligne.


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




Documentation

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

Cours-SME-101-024-Tux-APT.png





Cours-SME-101-023-LogicielsPosteDeTravail-APT.png







Cours-SME-101-026-ServeurSME-APT.png
  • Cahier-02: Description du parcours des paquets IP du Serveur SME vers l'Internet, création de la machine virtuelle, installation/configuration du serveur Linux SME et enfin, sauvegarde/restauration de ce dernier, SME-101.02 Serveur SME.
  • Cahier-03: Abonnement à un FAI, installation et configuration d'un modem ADSL/VDSL, création d'un domaine chez un fournisseur de Service DNS dynamique avec installation d'un script pour sa mise à jour et enfin la marche à suivre pour l'obtention et la configuration d'un domaine FQDN[3], SME-101.03 ADSL/VDSL, DDNS et Domaine FQDN.
  • Cahier-04: Installation d'un certificat SSL de l'autorité de certification Let's Encrypt et script de mise à jour, SME-101.04 Certificat Let's Encrypt.




Cours-SME-101-027-CommerceEnLigne-APT.png
  • Cahier-05A: Installation et configuration de WordPress, SME-101.05A WordPress.
  • Cahier-05B: Installation et configuration de l'extension de sécurité Wordfence, SME-101.05B Wordfence.
  • Cahier-06: Installation et configuration de l'extension de vente en ligne WooCommerce, création de comptes chez Stripe et PayPal pour les paiements en ligne, SME-101.06 WooCommerce.




Cours-SME-101-028-Outils-APT.png




    

SME-201.01-002-RectangleBlanc-650x40-APT.png



Cours SME-201



SME-201.01-001-Logo-Proxmox.png
   * Cahier-01: Proxmox, SME-201.01: Proxmox-5.2.1.


SME-201.02-000-Logo-MediaWiki-APT.png
   * Cahier-02: MediaWiki, SME-201.02 MediaWiki-1.31.1.


SME-201.03-000-LogoDolibarr-APT-341x87.png
   * Cahier-03: Dolibarr   (À venir).


SME-201.04-000-Logo osTicket-APT.png
   * Cahier-04: OsTicket, SME-201.04: osTicket-1.10.4.



Michel-André          


caption  Victoire totale, hissons la bannière de la victoire.


  1. 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.
  2. 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.
  3. FQDN: Dans le DNS, un Fully Qualified Domain Name (FQDN, ou nom de domaine complètement qualifié) est un nom de domaine qui révèle la position absolue d'un nœud dans l'arborescence DNS en indiquant tous les domaines de niveau supérieur jusqu'à la racine. On parle également de domaine absolu, par opposition aux domaines relatifs. Par convention, le FQDN est ponctué par un point final.
    Référence: https://fr.wikipedia.org/wiki/Fully_qualified_domain_name.