Difference between revisions of "Odoo-11 & serveur de test/dev"

From SME Server
Jump to navigationJump to search
(RC-001)
 
(RC-001 // Ajustement pour la TOC à gauche et texte à droite // 2018-11-12 @ 10h35)
Line 1: Line 1:
−
<!--__NOTOC__ -->
+
<!-- ########################################################################### -->
−
  __TOC__
+
{| style="float: left; margin-right:20px;margin-bottom:10px;"
−
<br>
+
|-
−
= Description générale =
+
| style="vertical-align: top;" |
 +
<div style="float:right">__TOC__</div>
 +
|}
 +
<!-- ########################################################################### -->= Description générale =
 
=== Introduction ===
 
=== Introduction ===
 
Cette marche à suivre fait suite à celle sur [https://wiki.contribs.org/Odoo-11_%26_HTTPS Odoo-11 & HTTPS] et décrit les étapes pour créer un serveur de test/développement pour vérifier les mises à jour d'Odoo-11 etc....
 
Cette marche à suivre fait suite à celle sur [https://wiki.contribs.org/Odoo-11_%26_HTTPS Odoo-11 & HTTPS] et décrit les étapes pour créer un serveur de test/développement pour vérifier les mises à jour d'Odoo-11 etc....
Line 35: Line 38:
  
 
Les noms des serveurs sont différents ''(odoo-11 pour le serveur principal et dev-11 pour le serveur local)'' mais, leur domaine principal est toujours: <span style="color:blue">micronator-101.org</span>.
 
Les noms des serveurs sont différents ''(odoo-11 pour le serveur principal et dev-11 pour le serveur local)'' mais, leur domaine principal est toujours: <span style="color:blue">micronator-101.org</span>.
−
<br>
+
<br clear=all>
−
<br>
+
 
−
<br>
 
−
<br>
 
−
<br>
 
−
<br>
 
 
<hr style="width:50%; margin: 0 auto;">
 
<hr style="width:50%; margin: 0 auto;">
 
<br>
 
<br>
Line 52: Line 51:
  
 
C'est pour cette raison que nous allons créer le sous-domaine <span style="color:blue"><u>interne</u>.micronator-101.org</span>. Les accès à ce domaine particulier ne seront pas redirectionnés et nous pourrons alors accéder au gestionnaire Server Manager en spécifiant le nom de ce domaine: <span style="color:blue">https://www.interne.micronator-101.org/server-manager</span>.
 
C'est pour cette raison que nous allons créer le sous-domaine <span style="color:blue"><u>interne</u>.micronator-101.org</span>. Les accès à ce domaine particulier ne seront pas redirectionnés et nous pourrons alors accéder au gestionnaire Server Manager en spécifiant le nom de ce domaine: <span style="color:blue">https://www.interne.micronator-101.org/server-manager</span>.
−
<br>
+
<br clear=all>
−
<br>
 
  
 
<hr style="width:50%; margin: 0 auto;">
 
<hr style="width:50%; margin: 0 auto;">

Revision as of 16:35, 12 November 2018

Description générale

Introduction

Cette marche à suivre fait suite à celle sur Odoo-11 & HTTPS et décrit les étapes pour créer un serveur de test/développement pour vérifier les mises à jour d'Odoo-11 etc....

Icone-AstuceAPT.png  Le nouveau serveur peut être virtuel ou physique.

Icone-NoteAPT.png  Cette marche à suivre assume que vous avez réalisé l'installation d'un Serveur SME-9.2 virtuel ou physique, branché sur le réseau LOCAL du serveur principal, et que vous y avez installé Odoo-11 en suivant les procédures du document: Odoo-11.

But final

Odoo-11-DEV-001-ButFinal.png

Pour le présent document, sur le serveur dev-11.dev.micronator-101.org, nous avons installé Fail2ban et suivi les mêmes procédures qu'auparavant pour une nouvelle installation d'Odoo-11.

Icone-AsurveillerAPT.png  L'installation de SME-9.2 sur le serveur local est exactement telle que décrite dans le cahier 2 du cours Micronator-101: https://www.micronator.org/affaires/produit/micronator-101-cahier-2installation-dun-serveur-sme/

Ce nouveau serveur est configuré en mode Serveur uniquement.

L'installation de Fail2ban est décrite dans: 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/


Préparation du serveur

Ajout d'un nouveau domaine

Odoo-11-DEV-002-NouveauDomaine-A.png

Serveur principal vs serveur local

Si nous voulions accéder au gestionnaire Server Manager du serveur interne, on devrait spécifier micronator-101.org/server-manager; malheureusement c'est le serveur principal qui pourrait répondre...

Les noms des serveurs sont différents (odoo-11 pour le serveur principal et dev-11 pour le serveur local) mais, leur domaine principal est toujours: micronator-101.org.


Odoo-11-DEV-003-NouveauDomaine-B.png

Le serveur physique vs serveur virtuel

Pour éviter toute confusion, lors de la configuration initiale du serveur local, nous choisissons dev.micronator-101.org comme nom de domaine.

Icone-SeTirerDembarrasAPT.png  Si nous redirigeons tous les accès de notre serveur dev-11.dev.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 sous-domaine interne.micronator-101.org. Les accès à ce domaine particulier ne seront pas redirectionnés et nous pourrons alors accéder au gestionnaire Server Manager en spécifiant le nom de ce domaine: https://www.interne.micronator-101.org/server-manager.


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-DEV-004-CreationDomaine-A.png
Odoo-11-DEV-005-CreationDomaine-B.png
Odoo-11-DEV-006-CreationDomaine-C.png


Certificat Let's Encrypt

Description

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 aura été émis par une autorité de certification reconnue, le cadenas sera vert.

Ce chapitre est inspiré 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

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

Signalisation des changements

On applique les changements en signalant une mise à jour et un réamorçage. 

# 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

Icone-AstuceAPT.png  Vous pouvez manuellement mettre à jour la contribution 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 avez fait une mise à jour, vous devez signaler les changements.

# signal-event post-upgrade ; signal-event reboot

Choix des domaines et des hôtes

On affiche les nom d'hôtes de notre Serveur SME. 

# db hosts show | grep .org

dev-11.dev.micronator-101.org=host
dev-11.interne.micronator-101.org=host
ftp.dev.micronator-101.org=host
ftp.interne.micronator-101.org=host
mail.dev.micronator-101.org=host
mail.interne.micronator-101.org=host
proxy.dev.micronator-101.org=host
proxy.interne.micronator-101.org=host
wpad.dev.micronator-101.org=host
wpad.interne.micronator-101.org=host
www.dev.micronator-101.org=host
www.interne.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é.

CNAME

Les noms d'hôtes pour les "sous-domaines" interne.micronator-101.org et dev.micronator-101.org chez le régistraire du domaine micronator-101.org.

ftp.interne, mail.interne, interne, proxy.interne, wpad.interne et www.interne. ftp.dev, mail.dev, dev, proxy.dev, wpad.dev et www.dev.
Odoo-11-DEV-007-CNAME-A.png
Odoo-11-DEV-008-CNAME-B.png
Icone-AstuceAPT.png  On entre les noms des domaines et des hôtes ci-dessus chez le régistraire du nom de notre domaine.


Si on veut obtenir un certificat pour tous (all) les domaines et tous les hôtes de notre Serveur SME.

# 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 avec la commande db hosts show | grep .org sauf ceux des noms des serveurs: dev-11.dev.micronator-101.org et dev-11.interne.micronator-101.org car, ces derniers ne répondent pas au défis de Let's Encrypt.


Pour utiliser des hôtes ou des domaines activés individuellement, on spécifie 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 le domaine dev.micronator-101.org. 

# db domains setprop dev.micronator-101.org letsencryptSSLcert enabled

On inclut le domaine interne.micronator-101.org. 

# db domains setprop interne.micronator-101.org letsencryptSSLcert enabled

On vérifie. 

# db domains show

dev.micronator-101.org=domain
    Content=Primary
    Description=Sous domaine
    Nameservers=localhost
    letsencryptSSLcert=enabled
interne.micronator-101.org=domain
    Content=Primary
    Description=Primary domain
    Nameservers=localhost
    Removable=no
    SystemPrimaryDomain=yes
    letsencryptSSLcert=enabled

Hôtes

On inclut tous les hôtes suivants:

ftp 

# db hosts setprop ftp.dev.micronator-101.org letsencryptSSLcert enabled

# db hosts setprop ftp.interne.micronator-101.org letsencryptSSLcert enabled

mail 

# db hosts setprop mail.dev.micronator-101.org letsencryptSSLcert enabled

# db hosts setprop mail.interne.micronator-101.org letsencryptSSLcert enabled

proxy 

# db hosts setprop proxy.dev.micronator-101.org letsencryptSSLcert enabled

# db hosts setprop proxy.interne.micronator-101.org letsencryptSSLcert enabled

wpad 

# db hosts setprop wpad.dev.micronator-101.org letsencryptSSLcert enabled

# db hosts setprop wpad.interne.micronator-101.org letsencryptSSLcert enabled

www 

# db hosts setprop www.dev.micronator-101.org letsencryptSSLcert enabled

# db hosts setprop www.interne.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

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êcheront 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 de la configuration

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 la configuration complète. 

# cat /etc/dehydrated/config

#!/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"

Icone-AsurveillerAPT.png  Il n'y a pas de ligne vide avant #!/bin/bash. Ci-dessus, nous avons inséré une ligne vide pour faciliter la copie de la commande.


On vérifie les domaines et les hôtes. 

# cat /etc/dehydrated/domains.txt

dev.micronator-101.org ftp.dev.micronator-101.org mail.dev.micronator-101.org proxy.dev.micronator-101.org wpad.dev.micronator-101.org www.dev.micronator-101.org interne.micronator-101.org ftp.interne.micronator-101.org mail.interne.micronator-101.org proxy.interne.micronator-101.org wpad.interne.micronator-101.org www.interne.micronator-101.org

Icone-AsurveillerAPT.png  Il n'y a pas de ligne vide avant dev.micronator-101.org... Ci-dessus, nous avons inséré une ligne vide pour faciliter la copie de la commande.

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: dev.micronator-101.org.

Obtention d'un certificat pour un serveur local

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

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

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

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

config setprop letsencrypt hookScript enabled

config setprop letsencrypt host mon-domaine-externe.tld

config setprop letsencrypt user root

config setprop letsencrypt path /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge

Les parties en bleu ci-dessus doivent être modifiées pour correspondre à votre situation. La variable path doit être l'emplacement du répertoire dans lequel micronator-101.org sauvegarde les défis: le répertoire /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge. Lorsque le script dehydrated crée les fichiers de défis, il les transfère via SCP vers user@host:path puis, demande au serveur Let's Encrypt de les valider. Une fois la validation effectuée, le script dehydrated supprime le contenu du répertoire des défis: user@host:path.


Après avoir défini ces entrées, il faut en signaler les changements.

# signal-event console-save


Résolution Internet pour le domaine du serveur local

Nous avons ajouté les CNAME pour le sous domaine dev.micronator-101.org chez le régistraire du domaine micronator-101.org.

Odoo-11-DEV-010-ResolutionDNS.png

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

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


# ssh -p 2222 root@192.168.1.11 "ping -c3 dev.micronator-101.org"


  01  

  02  

  03  

  04  

  05  

  06  

  07  

  08  

  09  

  10  

  11  

  12  

  13  

  14  

  15  

  ssh -p 2222 root@192.168.1.11 "ping -c3 dev.micronator-101.org"

  

  The authenticity of host '192.168.1.11 (192.168.1.11)' can't be established.

  RSA key fingerprint is be:a1:2f:cf:c1:5f:05:53:1a:12:c8:75:c7:a5:6c:6f.

  Are you sure you want to continue connecting (yes/no)? yes

  Warning: Permanently added '192.168.1.11' (RSA) to the list of known hosts.

  root@192.168.1.11's password: mot-de-passe-du-serveur-principal

  PING micronator-101.org (206.248.138.152) 56(84) bytes of data.

  64 bytes from 206-248-138-152.dsl.teksavvy.com (206.248.138.152): icmp_seq=1 ttl=64 time=0.027 ms  

  64 bytes from 206-248-138-152.dsl.teksavvy.com (206.248.138.152): icmp_seq=2 ttl=64 time=0.038 ms  

  64 bytes from 206-248-138-152.dsl.teksavvy.com (206.248.138.152): icmp_seq=3 ttl=64 time=0.047 ms  

  

  --- micronator-101.org ping statistics ---

  3 packets transmitted, 3 received, 0% packet loss, time 2000ms

  rtt min/avg/max/mdev = 0.027/0.037/0.047/0.009 ms


  • #01: La commande qui demande de se loguer en SSH (au port 2222) avec l'usager root à l'adresse 192.168.1.11 et d'exécuter la commande entre les guillemets.
  • #02: Ligne vide pour faciliter la copie de la commande avec la souris.
  • #05: On confirme que root veut se loguer, yes.
  • #07: Le mot de passe de root sur le serveur 192.168.1.11.
  • #08: Le DNS a retourné l'adresse IP (206.248.138.152) pour le domaine micronator-101.org. Cette adresse est celle pointée par le CNAME dev chez notre régistraire; c'est celle du serveur principal car, l'enregistrement @ chez le régistraire pointe vers cette adresse.
  • #09-11: L'usager root lance les trois ping,
  • #13-15: Statistiques des ping.


Authentification par clé publique SSH

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

Génération de la clé SSH

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

# whoami

root

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

  • On accepte le nom du fichier par défaut en tapant la touche [Entrée].
  • On n'utilise pas de phrase de passe[1] en tapant la touche [Entrée].
  • On confirme en tapant encore la touche [Entrée].
# ssh-keygen -t rsa -b 2048

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

On vérifie. 

# ls -ls .ssh/

total 12
4 -rw------- 1 root root 1675 12 sept. 21:00 id_rsa
4 -rw-r--r-- 1 root root  393 12 sept. 21:00 id_rsa.pub
4 -rw-r--r-- 1 root root  221 12 sept. 19:08 known_hosts

Icone-AsurveillerAPT.png  La clé id_rsa est la clé privée qui doit toujours être cachée et n'être divulguée à absolument personne.

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


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

Icone-NoteAPT.png  Ce jeu de clés SSH, id_rsa / id_rsa.pub, servira uniquement à l'utilisateur root pour ses communications SSH entre le serveur intranet et le serveur principal.

Icone-AsurveillerAPT.png  Ce jeu de clés SSH est différent du jeu standard d'un Serveur SME qui se trouve dans le répertoire /etc/ssh/ et qui comprend: ssh_host_rsa_key / ssh_host_rsa_key.pub. 

# ls -als /etc/ssh/ssh_host_rsa*

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


Port SSHD

Odoo-11-DEV-011-PortSSH.png

Le port standard utilisé par le démon SSHD est 22. Pour déjouer un peu plus les pirates malveillants, lors de l'installation de nos Serveurs SME, nous configurons toujours le port 2222 comme port par défaut pour SSHD.

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

Nous allons forcer ces communications, pour l'utilisateur root, à utiliser le port 2222 en créant un fichier de configuration pour le démon SSHD. Ce fichier, config, doit être créé dans le répertoire .ssh de l'usager root.

Les paramètres dans le fichier de configuration SSH de root auront préséance sur tous les autres paramètres spécifiant le port SSH pour cet utilisateur seulement.


Spécification du port SSH pour l'utilisateur root

Il existe plusieurs façons de spécifier ce port mais, la plus efficace est celle ci-dessous.

Host *

     Port 2222

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

Nous aurions pu utiliser l'expression suivante pour spécifier uniquement le nom d'un hôte particulier.

Host 192.168.1.11

     Port 2222

Ou celle-ci pour spécifier tous les serveur sur le réseau 192.168.1.0.

Host 192.168.1.0/24

     Port 2222

On peut aussi spécifier des hôtes utilisant des ports différents.

Host 192.168.1.11

     Port 2222

Host 192.168.1.1

     Port 3333

Icone-AsurveillerAPT.png  Il faut que le mot "Port" soit à au moins un espace de la marge de gauche.


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

Icone-AsurveillerAPT.png  Prendre tout le contenu de l'encadré pour la commande. 

cat > /root/.ssh/config <<'EOT'

Host 192.168.1.11
     Port 2222

EOT

On vérifie le contenu. 

# cat /root/.ssh/config

Host 192.168.1.11
     Port 2222

Icone-AsurveillerAPT.png  Il peut y avoir une ligne vide avant la ligne Host 192.168.1.11.


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

Sommes-nous toujours l'usager root? 

# whoami

root

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

# cat .ssh/id_rsa.pub | ssh root@192.168.1.11  "cat >> /root/.ssh/authorized_keys2"

root@192.168.1.1's password: mot-de-passe-de-root-du_serveur-passerelle
  • cat .ssh/id_rsa.pub indique d'afficher la clé publique id_rsa.pub de l'usager root du serveur local.
  • Le caractère de pipe "|" indique de passer le résultat de la commande précédente (cat) à la commande suivante (ssh). Le paramètre -p 2222 n'est pas utilisé car, il l'est dans le fichier config. Le paramètre root@192.168.1.11 indique de se connecter en tant que root à l'adresse 192.168.1.11.
  • La commande qui est entre guillemets "...", indique au serveur de destination i.e. odoo-11 (le serveur principal - passerelle) d'exécuter la commande qui se trouve entre ces guillemets. Donc, le serveur odoo-11 va afficher avec cat ce qu'il reçoit et va l'ajouter (>>) à son fichier: /root/.ssh/authorized_keys2.


Vérification de la connexion

On vérifie la connexion SSH sans spécifier le port et sans utiliser un mot de passe. (Notez le changement dans les invites des commandes.) 

[root@dev-11 ~]# ssh root@192.168.1.11

Last login: Wed Sep 12 13:14:44 2018 from 192.168.1.81
************ Welcome to SME Server 9.2 *************
...
****************************************************
[root@odoo-11 ~]#

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

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

[root@odoo-11 ~]# exit

logout
Connection to 192.168.1.11 closed.
[root@dev-11 ~]#

Nous sommes de retour à la console du serveur local.


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

hookScript

Activation du point d'accès qui s'occupe de récupérer le certificat Let's Encrypt pour un serveur interne. 

# config setprop letsencrypt hookScript enabled

host

On indique l'adresse IP de la passerelle. 

# config setprop letsencrypt host 192.168.1.11

user

L'usager qui récupérera le certificat. 

# config setprop letsencrypt user root

path

Le chemin du répertoire de stockage des défis sur le serveur passerelle. 

# config setprop letsencrypt path /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge

On signale les changements (peut prendre plusieurs secondes). 

# signal-event console-save

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

# config show letsencrypt

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


Fichier hosts

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

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

Icone-AstuceAPT.png  Si nous n'avons pas de serveur DNS sur le réseau LOCAL, on peut faire des entrées dans le fichier hosts de la station de travail et y indiquer les adresses IP de notre Serveur SME local.

Sur une station Windows, le fichier hosts se trouve dans le répertoire: C:\Windows\System32\drivers\etc\. Pour une station Linux, il réside dans le répertoire /etc.

Clac (clic droit) sur le fichier > Propriétés.
Le fichier est en Lecture seule, on décoche ce paramètre > OK.
Odoo-11-DEV-012-FichierHosts-A.png


On édite le fichier hosts et on entre les noms et l'adresse IP de notre Serveur SME intranet après les lignes localhost. 

...
# localhost name resolution is handled within DNS itself.
#    127.0.0.1       localhost
#    ::1             localhost

# Serveur SME sur le réseau local

192.168.1.101    dev.micronator-101.org
192.168.1.101    www.dev.micronator-101.org

192.168.1.101    interne.micronator-101.org
192.168.1.101    www.interne.micronator-101.org
...
                                          On remet le fichier en Lecture seule.
Odoo-11-DEV-013-FichierHosts-B.png


  • Vidange du cache DNS

Sur la station de travail, on ouvre un écran de commande et on vide le cache DNS de la station. 

> ipconfig /flushdns

Configuration IP de Windows

Cache de résolution DNS vidé.


  • Vidange de l'historique

Icone-SeTirerDembarrasAPT.png  On vidange l'historique de notre navigateur.

Odoo-11-DEV-014-Historique-A.png
Odoo-11-DEV-015-Historique-B.png

Icone-AsurveillerAPT.png  Il faut autoriser java script et les témoins dans notre navigateur Internet.


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
Processing dev.micronator-101.org with alternative names: ftp.dev.micronator-101.org mail.dev.micronator-101.org proxy.dev.micronator-101.org wpad.dev.micronator-101.org www.dev.micronator-101.org interne.micronator-101.org ftp.interne.micronator-101.org mail.interne.micronator-101.org proxy.interne.micronator-101.org wpad.interne.micronator-101.org www.interne.micronator-101.org
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting challenge for dev.micronator-101.org...
 ...
MgVbNZ7kU3Rzmh5SZb0cNo3Womr6_ywMqkzYph8PLcU               100%   87     0.1KB/s   00:00
 + Responding to challenge for dev.micronator-101.org...
 + Challenge is valid!
 ...
 + Requesting certificate...
 + Checking certificate...
 + Done!
 + Creating fullchain.pem...
 + Walking chain...
Set up modSSL db keys
Signal events
All complete
 + Done!

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-staging.api.letsencrypt.org/directory; curl returned with 6


Vérification du certificat

Si la commande fonctionne sans erreur, essayez de vous connecter à la page du gestionnaire Server Manager https://interne.micronator-101.org/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.

Odoo-11-DEV-016-Verif-A.png

Avec Firefox, on se connecte au gestionnaire Server Manager sur le serveur local.


Après avoir accepté le certificat, on clique le cadenas puis, >. Plus d'informations. Afficher le certificat.
Odoo-11-DEV-017-Verif-B.png
Odoo-11-DEV-018-Verif-C.png
Odoo-11-DEV-019-Verif-D.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-DEV-020-Verif-E.png
Odoo-11-DEV-021-Verif-F.png
Odoo-11-DEV-022-Verif-G.png

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 qui peuvent prendre plusieurs secondes. 

# signal-event console-save

On vérifie. 

# cat /etc/dehydrated/config

#!/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"

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 dev.micronator-101.org with alternative names: ftp.dev.micronator-101.org mail.dev.micronator-101.org proxy.dev.micronator-101.org wpad.dev.micronator-101.org www.dev.micronator-101.org interne.micronator-101.org ftp.interne.micronator-101.org mail.interne.micronator-101.org proxy.interne.micronator-101.org wpad.interne.micronator-101.org www.interne.micronator-101.org
 + Checking domain name(s) of existing cert... unchanged.
 + Checking expire date of existing cert...
 + Valid till Dec 13 18:22:51 2018 GMT (Longer than 30 days). Ignoring because renew was forced!
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting challenge for dev.micronator-101.org...
 ...
hI3Yhd8hdrdAGdP4F42TKbVr_lpE1Yig0xvGhxqT86s               100%   87     0.1KB/s   00:00
 + Responding to challenge for dev.micronator-101.org...
 + Challenge is valid!
 ...
 + Requesting certificate...
 + Checking certificate...
 + Done!
 + Creating fullchain.pem...
 + Walking chain...
Set up modSSL db keys
Signal events
All complete
 + Done!

Si cette demande a réussie, félicitations! Vous avez obtenu un certificat TLS 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-staging.api.letsencrypt.org/directory; curl returned with 6

Vérification

On se rend à: https://interne.micronator-101.org/.

Le cadenas est vert. Émis par: Let's Encrypt Authority X3. Tous les domaines et noms d'hôtes sont présents.
Odoo-11-DEV-023-Verif2-A.png
Odoo-11-DEV-024-Verif2-B.png
Odoo-11-DEV-025-Verif2-C.png


Connexion sécuritaire SSL/TLS (https)

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:

Odoo-11-DEV-026-HTTPS.png
  • Nous avons déjà ajouté le sous-domaine interne.micronator-101.org que nous utiliserons pour accéder au gestionnaire Server Manager.
  • À l'aide d'un gabarit personnalisé, nous allons rediriger les accès à dev.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 alors modifier. 

# mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts

On copie le fragment original vers le gabarit personnalisé. (La commande est sur deux lignes.) 

# 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  14 sept. 20:41 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
}

Icone-NoteAPT.png  On peut modifier le contenu du fichier du gabarit personnalisé avec vi / Notepad++ / ... ou exécuter la commande du prochain paragraphe. 

{
    if ( $port eq "80" && $virtualHost eq "dev.micronator-101.org")
    {
        $OUT .= "    \n";
        $OUT .= "    # Pour la redirection d'Odoo.\n";
        $OUT .= "    # Michel-André / 2018-09-12_22h06\n";
        $OUT .= "    Redirect / https://dev.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 "dev.micronator-101.org" )
    {
        $OUT .= "    \n";
        $OUT .= "    # Pour la redirection vers le port 8069\n";
        $OUT .= "    # Michel-André / 2018-09-12_22h06\n";
        $OUT .= "    ProxyPass / http://localhost:8069/ retry=0\n";
        $OUT .= "    ProxyPassReverse / http://localhost:8069/\n";
    }

}

Icone-AsurveillerAPT.png  La ligne SSL_END doit obligatoirement débuter sur la première colonne.


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 "dev.micronator-101.org")
    {
        $OUT .= "    \n";
        $OUT .= "    # Pour la redirection d'Odoo.\n";
        $OUT .= "    # Michel-André / 2018-09-12_22h06\n";
        $OUT .= "    Redirect / https://dev.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 "dev.micronator-101.org" )
    {
        $OUT .= "    \n";
        $OUT .= "    # Pour la redirection vers le port 8069\n";
        $OUT .= "    # Michel-André / 2018-09-12_22h06\n";
        $OUT .= "    ProxyPass / http://localhost:8069/ retry=0\n";
        $OUT .= "    ProxyPassReverse / http://localhost:8069/\n";
    }

}
EOT


On développe le gabarit httpd.conf pour qu'il intègre le gabarit personnalisé. 

# 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

Connexion à Server Manager

Icone-AsurveillerAPT.png  On supprime l'historique de notre navigateur.

On s'assure qu'on peut toujours accéder au gestionnaire Server Manager du serveur local en allant à: [https://www.interne.micronator-101.org/server-manager.

Odoo-11-DEV-027-Verif3-A.png
Odoo-11-DEV-028-Verif3-B.png

Connexion à Odoo

On se rend sur notre site Odoo en spécifiant toujours dev.micronator-101.org:

Le résultat est toujours le même, on est automatiquement redirigé vers la page de connexion d'Odoo: https://dev.micronator-101.org/web/login et le cadenas est vert.

Odoo-11-DEV-029-ConnexionOdoo-A.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-DEV-030-ConnexionOdoo-B.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-DEV-031-Certif-A.png
Odoo-11-DEV-032-Certif-B.png
Odoo-11-DEV-033-Certif-C.png
Odoo-11-DEV-034-Certif-D.png


Pas avant. Pas après donc, valide pour 90 jours. Nos CNAME sont tous là.
Odoo-11-DEV-035-Certif-E.png
Odoo-11-DEV-036-Certif-F.png
Odoo-11-DEV-037-Certif-G.png


Fichier index de l'i-bay Primary

Odoo-11-DEV-009-PageDeLaSociete.png

Le fichier index.html dans l'i-bay Primary peut contenir un texte en HTML décrivant notre organisation et sera affiché lors d'une visite à la page: http://www.micronator-101.org ou https://www.micronator-101.org.









Mise en garde

Icone-AsurveillerAPT.png  Il ne faut plus utiliser: https://dev.micronator-101.org:8069, car vous obtiendrez l'erreur de connexion suivante: SSL_ERROR_RX_RECORD_TOO_LONG.

Odoo-11-DEV-038-MiseEnGarde.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 à interne.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 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 dev-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/dev-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 dev-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

caption

On 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, le bloc de commandes ci-dessous 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 avec la commande signal-event reboot 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 dev-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.interne.micronator-101.com.

Firefox affiche un écran d'avertissement. Avancé > Ajouter une exception... > Voir... > onglet Détails > Validité > Pas avant.

Odoo-11-DEV-040-NavigateurWeb.png

Le certificat est au nom de: dev-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

Cette troisième marche à suivre conclut notre étude sur l'application Odoo-11.

  1. Description de l'installation d'Odoo-11 sur un Serveur SME-9.2: https://wiki.contribs.org/Odoo-11.
  2. Description ses étapes pour assurer une connexion sécuritaire à Odoo-11 roulant sur un Serveur SME: https://wiki.contribs.org/Odoo-11_%26_HTTPS.


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

  1. ↑ phrase de passe: Groupe de mots et de caractères alphanumériques ou spéciaux, faisant office de mot de passe, connu de l'utilisateur seulement, qui sert à protéger sa clé privée et à l'identifier lors d'une connexion ou d'un transfert de fichier, tout en lui assurant une plus grande sécurité.
    Notes: Les phrases de passe ne diffèrent des mots de passe que par la longueur. Les mots de passe sont généralement très courts - de 6 à 10 caractères -, alors que les phrases de passe peuvent comporter jusqu'à 100 caractères (et même plus). Leur longueur et la combinaison des mots et des caractères alphanumériques contribuent à les rendre plus difficiles à deviner que les mots de passe, et donc plus sûres.
    Une phrase de passe doit être: connue que de l'utilisateur, suffisamment longue pour être sûre, difficile à deviner, facile à retenir et à saisir sans erreur. Certains considèrent qu'elle devrait atteindre 80 à 100 caractères pour être vraiment efficace.
    Référence: http://www.granddictionnaire.com/ficheOqlf.aspx?Id_Fiche=8361195.
  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.
Retrieved from "https://wiki.koozali.org/index.php?title=Odoo-11_%26_serveur_de_test/dev&oldid=37163"