Différences

Ci-dessous, les différences entre deux révisions de la page.

--- doc:access_distant [2021/02/28 15:13]
Indelog Fix conf apache
+++ doc:access_distant [2023/11/12 22:22] (Version actuelle)
@@ Ligne 5: / Ligne 5: @@
 ===== Préambule =====
-Comme indiqué explicitement sur [[medshake>documentation-technique/environnement-de-production-necessaire-a-medshakeehr.html#preambule-avertissements-0|la documentation officielle relative à la mise en production d'une instance MedShake EHR/EDC]], celle-ci **ne doit jamais être exposée telle quelle au réseau ouvert comme internet**. À la base, elle ne doit être accédée que via un réseau privé comme le réseau local du professionnel de santé.
+Comme indiqué explicitement sur [[medshake>documentation-technique/environnement-de-production-necessaire-a-medshakeehr.html#preambule-avertissements-0|la documentation officielle relative à la mise en production d'une instance MedShake EHR/EDC]], celle-ci **ne doit jamais être exposée tel quel aux réseaux ouverts comme Internet**. À la base, elle ne doit être accessible que via un réseau privé comme le réseau local du professionnel de santé.
 Ce document décrit des moyens permettant de fournir un accès distant (entendez par là un accès depuis un autre endroit que le réseau local) à son instance MedShake EHR/EDC hébergée dans le local du professionnel de santé en ajoutant une couche d'authentification supplémentaire pour les clients via l'utilisation de [[wpfr>X.509|certifcat X.509]].
-Ce document ne décrit pas comment effectuer le [[wpfr>NAT]] permettant de rediriger les connexions envoyées vers son IP publique vers le serveur hébergeant l'instance MedShake EHR/EDC sur le réseau local. Pour cela, je vous redirige vers le documentation de votre "routeur box" ainsi que vers les nombreuses autres ressources traitant du sujet et disponible sur le web.
+Ce document ne décrit pas comment effectuer le [[wpfr>NAT]] permettant de rediriger les connexions envoyées depuis son IP publique vers le serveur hébergeant l'instance MedShake EHR/EDC sur le réseau local. Pour cela, je vous redirige vers le documentation de votre "routeur box" ainsi que vers les nombreuses autres ressources traitant du sujet et disponibles sur le web.
 Ici on part du principe que votre installation est conforme à celle décrite dans [[medshake>/documentation-technique/environnement-de-production-necessaire-a-medshakeehr.html|la documentation officielle]] et que par conséquent on dispose de l’environnement suivant :
-  * Système d'exploitation Debian 10
+  * Système d'exploitation Debian 11
-  * Serveur web Apache
+  * Serveur web Apache2
 Si ce n'est pas le cas, il vous faudra sûrement apporter des adaptations à la procédure selon votre environnement.
@@ Ligne 22: / Ligne 22: @@
 <WRAP center round important 60%>
 === Hébergement de MedShake EHR/EDC hors des locaux du professionnel de santé ===
-Les méthodes qui sont décrites ici ne sont pas censées être utilisées pour fournir un hébergement hors des locaux du professionnel de santé, par exemple en data center ou fournis par un prestataire quelconque sur ses propres serveurs, sauf ci celui-ci est agréé ou certifié [[https://esante.gouv.fr/labels-certifications/hds/liste-des-herbergeurs-agrees|Hébergeur de Données de Santés (HDS)]].
+Les méthodes qui sont décrites ici ne sont pas censées être utilisées pour fournir un hébergement hors des locaux du professionnel de santé, par exemple en data center ou fournis par un prestataire quelconque sur ses propres serveurs, sauf si celui-ci est agréé ou certifié [[https://esante.gouv.fr/labels-certifications/hds/liste-des-herbergeurs-agrees|Hébergeur de Données de Santés (HDS)]].
 Je vous renvoie à la partie 6 du [[https://www.cnil.fr/sites/default/files/atoms/files/referentiel_-_cabinet.pdf|RÉFÉRENTIEL RELATIF AUX TRAITEMENTS DE DONNÉES À CARACTÈRE PERSONNEL DESTINÉS À LA GESTION DES CABINETS MÉDICAUX ET PARAMÉDICAUX]] publié par la CNILL.
@@ Ligne 28: / Ligne 28: @@
 <WRAP center round important 60%>
-=== Ces méthodes n’ont ni été relus ni approuvées par le concepteur de la solution MedShake EHR/EDC (le Dr BOUTILLIER) ===
+=== Ces méthodes n’ont été ni relus ni approuvés par le concepteur de la solution MedShake EHR/EDC (le Dr BOUTILLIER) ===
 Dans tous les cas, toujours se fier à [[medshake>/|la documentation officielle]], si à un moment elle contredit celle-ci, **la documentation officielle fait autorité**.
@@ Ligne 36: / Ligne 36: @@
 === N'appliquez pas cette procédure si vous ne la comprenez pas ! ===
-Ces méthodes demandent certaines compétences techniques pour être comprises est réalisées. Si vous n'êtes pas en mesure d'en comprendre le contenu, **ne vous lancez pas dedans seul**. Mal réalisées, elles peuvent potentiellement **occasionner une fuite des données de santé des patients**.
+Ces méthodes demandent certaines compétences techniques pour être comprises et réalisées. Si vous n'êtes pas en mesure d'en comprendre le contenu, **ne vous lancez pas dedans seul**. Mal réalisées, elles peuvent potentiellement **occasionner une fuite des données de santé des patients**.
 Au pire, demandez conseil sur le forum.
@@ Ligne 43: / Ligne 43: @@
 ===== Principes =====
-L’objectif est d'ajouter une couche d'authentifications supplémentaires afin de restreindre l'accès à l'instance MedSake EHR/EDC aux seuls clients explicitement identifiés et autorisés.
+L’objectif est d'ajouter une couche d'authentification supplémentaire afin de restreindre l'accès à l'instance MedSake EHR/EDC aux seuls clients explicitement identifiés et autorisés.
-Pour cela nous allons nous appuyer sur la mise en place d'une [[wpfr>Ca#Informatique|Autorité de certification (CA)]] que nous utiliserons ensuite pour délivrer des [[wpfr>X.509|certificats X.509]] signés par celle-ci et qui seront ensuite utilisés pour authentifier chaque utilisateur accédant à l'instance MedShake EHR/EDC. Nous générerons aussi une [[wpfr>CRL|liste de révocation de certificat (CRL)]] afin bloquer les accès aux clients présentant des certificats qui seraient révoqués pour diverses raisons.
+Pour cela nous allons nous appuyer sur la mise en place d'une [[wpfr>Ca#Informatique|Autorité de certification (CA)]] que nous utiliserons ensuite pour délivrer des [[wpfr>X.509|certificats X.509]] signés par celle-ci et qui seront ensuite utilisés pour authentifier chaque utilisateur accédant à l'instance MedShake EHR/EDC. Nous générerons aussi une [[wpfr>CRL|liste de révocation de certificats (CRL)]] afin bloquer les accès aux clients présentant des certificats qui seraient révoqués pour diverses raisons.
 <WRAP center round info 60%>
@@ Ligne 88: / Ligne 88: @@
   * La vérification des certificats des clients directement avec Apache.
-  * La vérification des certificats des clients par '[[https://openvpn.net/community/|OpenVPN]] qui leur permettra ou non de se connecter à son [[wpfr>Réseau privé virtuel|Réseau privé virtuel (VPN)]]. L'instance Medshake EHR/EDC ne sera alors accessible qu'au travers ce celui-ci.
+  * La vérification des certificats des clients par '[[https://openvpn.net/community/|OpenVPN]] qui leur permettra ou non de se connecter à son [[wpfr>Réseau privé virtuel|Réseau privé virtuel (VPN)]]. L'instance Medshake EHR/EDC ne sera alors accessible qu'au travers de celui-ci.
 Dans les deux cas, il nous faudra disposer de notre CA. Il faut donc procéder en deux étapes :
@@ Ligne 103: / Ligne 103: @@
 Cette méthode est moins "étanche qu'avec OpenVPN" et nous oblige à exposer le serveur web directement à internet. Il faudra donc bien vérifier et tester la configuration Apache.
-Par contre ,la maintenance du système et les audits de sécurité seront plus simples, car nous avons un composant de moins à gérer (le serveur VPN). De plus, la mise en place côté client est aussi plus simple, car nous n'avons pas besoin d'ajouter et de configurer le client OpenVPN, fournir le certificat au navigateur web suffit.
+Par contre, la maintenance du système et les audits de sécurité seront plus simples, car nous avons un composant de moins à gérer (le serveur VPN). De plus, la mise en place côté client est aussi plus simple, car nous n'avons pas besoin d'ajouter et de configurer le client OpenVPN; fournir le certificat au navigateur web suffit.
-Plutôt recommandé si nous avons une base d'utilisateur nombreuse ou changeante.
+Plutôt recommandé si nous avons une base d'utilisateurs nombreuse ou changeante.
 == Via OpenVPN ==
-Cette méthode est plus "étanche" que l'authentification directe des certificats client avec Apache. Elle permet d'isoler l'accès à l'instance MedShake EHR/EDC au seul réseau du VPN. De ce fait, on se retrouve dans des conditions similaires à celle de l'instance uniquement accessible sur le réseau local. De plus, nous n'avons pas besoin d'exposer le serveur web à l'internet, seul le serveur VPN a besoin de l'être.
+Cette méthode est plus "étanche" que l'authentification directe des certificats clients avec Apache. Elle permet d'isoler l'accès à l'instance MedShake EHR/EDC au seul réseau du VPN. De ce fait, on se retrouve dans des conditions similaires à celle de l'instance uniquement accessible sur le réseau local. De plus, nous n'avons pas besoin d'exposer le serveur web à l'internet, seul le serveur VPN a besoin de l'être.
-En contrepartie, on ajoute un composant supplémentaire à surveiller et maintenir qu'il faudra prendre en compte dans les audits de sécurités. De plus, la mise en place côté client sera plus complexe, car il faudra aussi installer et configurer le client OpenVPN sur tous les postes utilisateurs (y compris sur les smartphones si on veut utiliser //phonecapture//).
+En contrepartie, on ajoute un composant supplémentaire à surveiller et maintenir qu'il faudra prendre en compte dans les audits de sécurité. De plus, la mise en place côté client sera plus complexe, car il faudra aussi installer et configurer le client OpenVPN sur tous les postes utilisateurs (y compris sur les smartphones si on veut utiliser //phonecapture//).
-Plutôt recommandé si nous avons une base d'utilisateur peu nombreuse ou peu changeante.
+Plutôt recommandé si nous avons une base d'utilisateurs peu nombreuse ou peu changeante.
 ===== La CA =====
@@ Ligne 120: / Ligne 120: @@
 Ici la CA est installée directement sur le serveur qui héberge l'instance MedShake EHR/EDC. Sauf mention contraire, toutes les commandes décrites dans cette partie doivent y être effectuées dans un Shell sur le serveur disposant des droits ''root''.
-Il faut aussi disposer d'un moyen de récupérer les certificats se trouvant sur le serveur afin de les placer sur les postes clients. Je recommande d'utiliser ''scp'' ou ''sftp'' pour cela, mais pas directement depuis les postes client. L'administrateur utilise son accès sécurisé au serveur via ''ssh'' depuis son poste à lui pour récupérer les certificats directement sur son poste et les transmet ensuite par le moyen qui lui convient aux autres clients.
+Il faut aussi disposer d'un moyen de récupérer les certificats se trouvant sur le serveur afin de les placer sur les postes clients. Je recommande d'utiliser ''scp'' ou ''sftp'' pour cela, mais pas directement depuis les postes clients. L'administrateur utilise son accès sécurisé au serveur via ''ssh'' depuis son poste à lui pour récupérer les certificats directement sur son poste et les transmet ensuite par le moyen qui lui convient aux autres clients.
 </WRAP>
-Afin de faciliter la gestion de notre CA nous allons utiliser l'utilitaire [[https://easy-rsa.readthedocs.io/en/latest/|Easy-RSA]]. Il s'agit d'un ensembles de script servant de front-end à OpenSSL.
+Afin de faciliter la gestion de notre CA nous allons utiliser l'utilitaire [[https://easy-rsa.readthedocs.io/en/latest/|Easy-RSA]]. Il s'agit d'un ensemble de scripts servant de front-end à OpenSSL.
 ==== Mise en place ====
-Pour commencer, nous devons installer l'utilitaire Easy-RSA. Sur la plupart des distributions majeures, il devrait être disponible via le gestionnaire de paquet. Sous Debian et dérivé nous pouvons l'installer avec la commande suivante :
+Pour commencer, nous devons installer l'utilitaire Easy-RSA. Sur la plupart des distributions majeures, il devrait être disponible via le gestionnaire de paquets. Sous Debian et dérivés nous pouvons l'installer avec la commande suivante :
 <code bash>
@@ Ligne 133: / Ligne 133: @@
 </code>
-Il faut un endroit pour y placer notre CA. Nous allons éviter de la placer quelque part dans le dossier ''/home/'' ce qui peut sous certaines conditions poser des problèmes de droits d'accès. Les emplacements ''/srv/'' ou  ''/var/local/'' sont de bons candidats. Ici la CA se trouvera dans ''/var/local/easyrsa/medshake/''. Le paquet Debian ''easy-rsa'' nous fournit le script ''make-cadir'' pour nous aider à l'initialiser :
+Il faut un endroit pour y placer notre CA. Nous allons éviter de la placer quelque part dans le dossier ''/home/'' ce qui peut, sous certaines conditions, poser des problèmes de droits d'accès. Les emplacements ''/srv/'' ou  ''/var/local/'' sont de bons candidats. Ici la CA se trouvera dans ''/var/local/easyrsa/medshake/''. Le paquet Debian ''easy-rsa'' nous fournit le script ''make-cadir'' pour nous aider à l'initialiser :
 <code bash>
@@ Ligne 142: / Ligne 142: @@
 </code>
-On va maintenant créer une configuration pour Easy-RSA spécifique à la CA. La commande ''make-cadir'' va créer un fichier ''vars'' dans l'emplacement où nous avons initialisé la CA. De base le fichier contient beaucoup de commentaires très utiles. Cependant pour faciliter la compréhension des paramètres que nous allons modifier, nous le remplaçons par notre propre version :
+On va maintenant créer une configuration pour Easy-RSA spécifique à la CA. La commande ''make-cadir'' va créer un fichier ''vars'' dans l'emplacement où nous avons initialisé la CA. De base, le fichier contient beaucoup de commentaires très utiles. Cependant pour faciliter la compréhension des paramètres que nous allons modifier, nous le remplaçons par notre propre version :
 <code bash>
@@ Ligne 170: / Ligne 170: @@
 set_var EASYRSA_ALGO		ec
-# Durée de validités du certificat de la CA en jours.
+# Durée de validité du certificat de la CA en jours.
 # Ici une durée de 10 ans.
 #
@@ Ligne 179: / Ligne 179: @@
 set_var EASYRSA_CA_EXPIRE	3650
-# Durée de validité des certificats signés par la CA en jour.
+# Durée de validité des certificats signés par la CA en jours.
 # Ici 1 an.
 # /!\ les utilisateurs avec un certificat expiré ne pourront plus accéder à
@@ Ligne 201: / Ligne 201: @@
 </code>
-Puis on va créer le certificat et la clé privée associée pour la CA. Un mot de passe va être demandé pour protéger la clé privée de la CA, **attention à celui-ci, cette clé sera utilisée pour signer les certificats émis par la CA ainsi que la CRL, sans lui vous ne pourrez plus émettre, renouveler ou révoquer les certificats**.
+Puis on va créer le certificat et la clé privée associée pour la CA. Un mot de passe va être demandé pour protéger la clé privée de la CA. **Attention à celui-ci, cette clé sera utilisée pour signer les certificats émis par la CA ainsi que la CRL, sans lui vous ne pourrez plus émettre, renouveler ou révoquer les certificats**.
 <code bash>
@@ Ligne 207: / Ligne 207: @@
 </code>
-Il faut aussi créer le fichier pour la CRL avec la commande ''easyrsa gen-crls'' même si nous n'avons aucune révocation de certificat pour le moment. **Vu que nous préciserons son emplacement plus loin dans la configuration de nos services et pour éviter tout problème lors de leur démarrage, le fichier pour la CRL doit exister en amonts.**//La commande demandera la saisis du mot de passe de la clé privée de la CA qui à été fournis à l'étape ''build-ca''.//
+Il faut aussi créer le fichier pour la CRL avec la commande ''easyrsa gen-crls'' même si nous n'avons aucune révocation de certificat pour le moment. **Vu que nous préciserons son emplacement plus loin dans la configuration de nos services et pour éviter tout problème lors de leur démarrage, le fichier pour la CRL doit exister en amonts.**//La commande demandera la saisie du mot de passe de la clé privée de la CA qui a été fourni à l'étape ''build-ca''.//
 <code bash>
@@ Ligne 220: / Ligne 220: @@
 Ici, nous utiliserons la commande ''easyrsa sign-req'' qui sert à créer et signer le certificat client.
-La commande demande un mot de passe, s'agit de celui du la clé privée de la CA.
+La commande demande un mot de passe, il s'agit de celui de la clé privée de la CA.
 </WRAP>
 <WRAP center round info 60%>
-Les exemples de commande ci-dessous sont à exécuter dans le dossier ou nous avons initialisé la CA (''/var/local/easyrsa/medshake/''). La commande ''./easyrsa'' lui est relative.
+Les exemples de commande ci-dessous sont à exécuter dans le dossier où nous avons initialisé la CA (''/var/local/easyrsa/medshake/''). La commande ''./easyrsa'' lui est relative.
 </WRAP>
 === Certificats serveur ===
-La création de certificats destinés à être utilisés côté serveur est similaire à celle des certificats client avec une petite subtilité. Ces certificats peuvent être utilisés par nos services (Apache ou OpenVPN) pour implémenter TLS et prouver au client leur authenticité en présentant aussi un certificat signé par la CA que le client pourra vérifier. Ici on crée un certificat que l'on nome //"medsahke"// et qui pourra être utilisé au choix par OpenVPN ou Apache.
+La création de certificats destinés à être utilisés côté serveur est similaire à celle des certificats clients avec une petite subtilité. Ces certificats peuvent être utilisés par nos services (Apache ou OpenVPN) pour implémenter TLS et prouver au client leur authenticité en présentant aussi un certificat signé par la CA que le client pourra vérifier. Ici on crée un certificat que l'on nome //"medsahke"// et qui pourra être utilisé au choix par OpenVPN ou Apache.
 Cela se fait en deux opérations :
@@ Ligne 235: / Ligne 235: @@
 On commence par créer une [[wpfr>Demande_de_signature_de_certificat|Demande de signature de certificat (CSR)]] en utilisant la commande ''easyrsa gen-req''. Cette opération se charge aussi de la création de la clé privée associée. Nous allons lui passer deux arguments :
-  * ''medshake'' qui est nom du certificat (vous pouvez le nommer comme vous voulez).
+  * ''medshake'' qui est le nom du certificat (vous pouvez le nommer comme vous voulez).
   * ''nopass'', car nous ne voulons pas que la clé privée du serveur soit protégée par mot de passe (sans cela il nous faudrait le ressaisir à chaque fois que le service utilisant le certificat démarre).
@@ Ligne 248: / Ligne 248: @@
 <WRAP center round important 60%>
-À la signature du certificat, Easy-RSA va demander de fournir un //"Common Name"// pour le certificat serveur. **Donnez-lui le domaine qui sera utilisé pour contacter le serveur** (ce qui sera fourni dans la configuration Apache pour la directive ''ServerName''). Ceci permettra d'éviter les alertes du navigateur web quand le serveur présente un certificat qui ne correspond pas au domaine utilisé (quant à la vérification de la signature du certificat fournir par le serveur web, nous fournirons le certificat le CA aux navigateurs).
+À la signature du certificat, Easy-RSA va demander de fournir un //"Common Name"// pour le certificat serveur. **Donnez-lui le domaine qui sera utilisé pour contacter le serveur** (ce qui sera fourni dans la configuration Apache pour la directive ''ServerName''). Ceci permettra d'éviter les alertes du navigateur web quand le serveur présente un certificat qui ne correspond pas au domaine utilisé (quant à la vérification de la signature du certificat fourni par le serveur web, nous fournirons le certificat la CA aux navigateurs).
 </WRAP>
@@ Ligne 268: / Ligne 268: @@
   * La création du certificat signé par la CA avec ''easyrsa sign-req''.
-On ajoute aussi une troisième étape : la création d'un fichier [[wpfr>PKSC12]] qui permet de distribuer le certificat de la CA, le certificat du client et sa clé privé via un seul et même fichier qui sera chiffré et protégé par mot de passe avec la commande ''easyrsa export-p12''.
+On ajoute aussi une troisième étape : la création d'un fichier [[wpfr>PKSC12]] qui permet de distribuer le certificat de la CA, le certificat du client et sa clé privée via un seul et même fichier qui sera chiffré et protégé par mot de passe avec la commande ''easyrsa export-p12''.
 Commençons par l'émission de la CSR qui va aussi au passage créer la clé privée du client. Nous passons deux paramètres à ''easyrsa gen-req'' :
   * ''Dr_TOTO'' qui sera le nom du certificat de notre client pour cet exemple. //je vous recommande de nommer vos certificats clients de manière explicite afin d'identifier facilement quel certificat appartient à quel utilisateur.//
-  * ''nopass'' pour ne pas protéger par mot de passe la clé privée du client. Normalement il ne faudrait pas distribuer une clé privée en claire, mais ici nous distribuerons nos certificats sous forme de fichier PKCS12 qui s’occupera du chiffrement de la clé privée. **Par contre, si vous n'utilisez pas PKCS12 n'utilisez pas non plus paramètre ''nopass''**.
+  * ''nopass'' pour ne pas protéger par mot de passe la clé privée du client. Normalement il ne faudrait pas distribuer une clé privée en clair, mais ici nous distribuerons nos certificats sous forme de fichier PKCS12 qui s’occupera du chiffrement de la clé privée. **Par contre, si vous n'utilisez pas PKCS12 n'utilisez pas non plus le paramètre ''nopass''**.
 <code bash>
@@ Ligne 279: / Ligne 279: @@
 </code>
-Puis il ne reste plus qu'à générer le certificat avec ''easyrsa sign-req'' et les deux paramètres suivant :
+Puis il ne reste plus qu'à générer le certificat avec ''easyrsa sign-req'' et les deux paramètres suivants :
   * ''client'' pour préciser que nous voulons créer un certificat destiné à être utilisé par un serveur.
-  * ''Dr_TOTO'' qui le nom de la CSR créer précédemment.
+  * ''Dr_TOTO'' qui le nom de la CSR créée précédemment.
 <code bash>
@@ Ligne 320: / Ligne 320: @@
 == Révocation ==
-Si le certificat d'un client se trouve compromis il peut autoriser des accès à l'instance MedShake EHR/EDC à des clients qui ne de devraient pas. Dans ce cas, il faut pouvoir indiquer au serveur qu'il doit désormais refuser les accès au client qui le présente.
+Si le certificat d'un client se trouve compromis il peut autoriser des accès à l'instance MedShake EHR/EDC à des clients qui ne le devraient pas. Dans ce cas, il faut pouvoir indiquer au serveur qu'il doit désormais refuser les accès aux clients qui le présentent.
 La première étape est d'utiliser ''easyrsa revoke'' avec deux paramètres :
@@ Ligne 332: / Ligne 332: @@
 <WRAP center round info 60%>
-La commande ''easyrsa revoke'' retire le certificat et sa clé privée des dossiers ''./pki/issued/'' et ''./pki/private/'' et les places dans le dossier ''./pki/revoked/''.
+La commande ''easyrsa revoke'' retire le certificat et sa clé privée des dossiers ''./pki/issued/'' et ''./pki/private/'' et les place dans le dossier ''./pki/revoked/''.
 </WRAP>
-Une fois fait-il nous faut régénérer la CRL pour y inclure la nouvelle révocation avec ''easyrsq gen-crl'' :
+Une fois fait, il nous faut régénérer la CRL pour y inclure la nouvelle révocation avec ''easyrsq gen-crl'' :
 <code bash>
@@ Ligne 345: / Ligne 345: @@
 Par défaut Easy-RSA place tous les fichiers dans un sous dossier ''./pki/''. Ici tout sera donc dans le dossier ''/var/local/easyrsa/medshake/pki/''.
-On ne va par décrire ici le contenu de tout le dossier, mais seulement éléments qui nous intéresses. Ici le dossier ''./pki/'' doit contenir les éléments suivants :
+On ne va par décrire ici le contenu de tout le dossier, mais seulement les éléments qui nous intéressent. Ici le dossier ''./pki/'' doit contenir les éléments suivants :
 <uml>
@@ Ligne 351: / Ligne 351: @@
 * pki
 **_ <i>ca.crt</i> : certificat de la CA, permet de vérifier l'authenticité des certificats clients et serveurs
-**_ <i>crl.crt</i> : liste des certificats révoqués, contient une liste signée par la CA de certificat compromis dont l’utilisation ne doit plus être autorisée
+**_ <i>crl.crt</i> : liste des certificats révoqués, contient une liste signée par la CA de certificats compromis dont l’utilisation ne doit plus être autorisée
 ** issued
 ***_ <i>medshake.crt</i> : certificat pour le serveur
@@ Ligne 358: / Ligne 358: @@
 ***_ <i>medshake.key</i> : clé privée pour le serveur
 ***_ <i>Dr_TOTO.key</i> : clé privée pour le client
-***_ <i>Dr_TOTO.p12</i> : fichier PKSC12 pour le client Dr_TOTO (contiens le certificat CA, le certificat client et sa clé privée)
+***_ <i>Dr_TOTO.p12</i> : fichier PKSC12 pour le client Dr_TOTO (contient le certificat CA, le certificat client et sa clé privée)
 @endmindmap
 </uml>
-Les clients devront récupérer leur fichier PKCS12. Le dossier ''./pki/'' n'est accessible que par le propriétaire, donc dans note cas que par ''root'', ce qui peut poser problème pour récupérer les éléments qui s'y trouvent afin de les transférer sur les postes clients. Si on veut récupérer les éléments via ''scp'' ou ''sftp'' et que nous nous connectons au serveur via un compte non privilégié il faudra faire une copie des fichiers PKCS12 dans un endroit qui lui sera lisible et changer les droits de lecture sur le ficher PKCS12 (qui sera aussi uniquement lisible par ''root'').
+Les clients devront récupérer leur fichier PKCS12. Le dossier ''./pki/'' n'est accessible que par le propriétaire, donc dans notre cas que par ''root'', ce qui peut poser problème pour récupérer les éléments qui s'y trouvent afin de les transférer sur les postes clients. Si on veut récupérer les éléments via ''scp'' ou ''sftp'' et que nous nous connectons au serveur via un compte non privilégié il faudra faire une copie des fichiers PKCS12 dans un endroit qui lui sera lisible et changer les droits de lecture sur le ficher PKCS12 (qui sera aussi uniquement lisible par ''root'').
 ===== Utilisation avec Apache =====
@@ Ligne 371: / Ligne 371: @@
 <WRAP center round important 80%>
-Attention : on suppose aussi qu'aucun autre point de votre configuration Apache ne permet l'accès à l'instance MedShake EHR/EDC, dans le cas contraire des clients sans certificat pourraient y accéder.
+Attention : on suppose aussi qu'aucun autre point de votre configuration Apache ne permet l'accès à l'instance MedShake EHR/EDC. Dans le cas contraire des clients sans certificat pourraient y accéder.
 </WRAP>
@@ Ligne 400: / Ligne 400: @@
     # Certificat et clé créés par la pki pour le serveur.
-    # Le certificat ayant été signé par la CA, les clients pourront aussi authentifier
+    # Le certificat ayant été signé par la CA, les clients pourront aussi
-    # le serveur.
+    # authentifier le serveur.
     SSLCertificateFile /var/local/easyrsa/medshake/pki/issued/medshake.crt
     SSLCertificateKeyFile /var/local/easyrsa/medshake/pki/private/medshake.key
-    # Certificat de la CA. Nécessaire pour vérifier l'authenticité des certificats des clients.
+    # Certificat de la CA. Nécessaire pour vérifier l'authenticité des certificats
+    # des clients.
     SSLCACertificateFile /var/local/easyrsa/medshake/pki/ca.crt
-    # Liste des certificats révoqués, permet de refuser l'accès aux certificats déclaré comme compromis.
+    # Liste des certificats révoqués, permet de refuser l'accès aux certificats
+    # déclarés comme compromis.
     SSLCARevocationFile /var/local/easyrsa/medshake/pki/crl.pem
-    # Active la vérification des certificats clients optionel (certain client du réseau local peuvent se connecter sans pour utiliser des fonctionalités comme phonecapture)
+    # Active la vérification des certificats clients optionnels (certains clients
+    # du réseau local peuvent se connecter sans certificat pour utiliser des fonctionnalités
+    # comme phonecapture)
     SSLVerifyClient optional
     # Limite la vérification aux certificats du client.
     # (inutile ici de contrôler toute la chaîne on n'a qu'un niveau)
-    SSLCARevocationCheck leaf
     SSLVerifyDepth 1
     # Sécurité renforcée, nous n'utiliserons que la version la plus récente de TLS
-    # (rejette d'office les clients non suffisamment à jours)
+    # (rejette d'office les clients non suffisamment à jour)
     SSLProtocol -all +TLSv1.3
     # Ajoute l'entête http pour le HSTS
@@ Ligne 424: / Ligne 427: @@
     DirectoryIndex index.php
-    # Fichier de log dédié avec un format compatible avec le lecteur de log intégré à Medshake
+    # Fichier de log dédié avec un format compatible avec le lecteur de log intégré
+    # à Medshake
     CookieName apacheLogUserID
     # /!\ le domaine doit être préfixé d'un point
@@ Ligne 434: / Ligne 438: @@
     CustomLog ${MEDSHAKEEHRLOGFILE} usertrack env=!do_not_log
-    # Des règles de réécriture d'urls sont nécessaires (voir le public_html/.htaccess)
+    # Des règles de réécriture d'urls sont nécessaires(voir le public_html/.htaccess)
     # On s'assure que le module est bien chargé
     RewriteEngine On
@@ Ligne 448: / Ligne 452: @@
     </Directory>
-    # Accès aux url commençant par /phonecapture/ et /pubic/ autorisé pour les clients du réseau local sans présenter ce certificat valide
+    # Accès aux url commençant par /phonecapture/ et /pubic/ autorisé pour les
-    <Location ~ /var/www/medshake/(phonecapture|public)/>
+    # clients du réseau local sans présenter ce certificat valide
+    <Location ~ /(phonecapture|public)/>
         # /!\ Replacer l'addresse ci-dessous par celle de votre réseau local
         Require ip 192.168.1.0/24
@@ Ligne 456: / Ligne 461: @@
     </Location>
-    # Autorise l'accès aux assets (js, css et images) et pages de maintenance autorisé pour les clients du réseau local sans présenter ce certificat valide
+    # Autorise l'accès aux assets (js, css et images) et pages de maintenance
+    # autorisés pour les clients du réseau local sans présenter ce certificat valide
     <Location ~ /(components/|thirdparty/|scss/|img/|js/|favicon.ico|maintenancePublic.html|maintenance.html)>
         # Ces ressources peuvent êtres mise en cache
         Header setifempty Cache-Control "must-revalidate"
-        # Fix un bug présent dans le version de apache utilisé dans Debian 10 (2.4.38)
+        # Fixe un bug présent dans le version de apache utilisé dans Debian 10(2.4.38)
-        # qui gènère une entête http Etag mal formé et empéche un retrour 304
+        # qui gènère une entête http Etag mal formé et empêche un retour 304
-        # quant la ressource est en cache.
+        # quand la ressource est en cache.
-        # voire https://bz.apache.org/bugzilla/show_bug.cgi?id=45023#c22
+        # voir https://bz.apache.org/bugzilla/show_bug.cgi?id=45023#c22
         RequestHeader edit "If-None-Match" '^"((.*)-gzip)"$' '"$1", "$2"'
         Require ip 192.168.1.0/24
@@ Ligne 478: / Ligne 484: @@
 <WRAP center round tip 60%>
-Noubliez pas d'activer la nouvelle config apache :
+N'oubliez pas d'activer la nouvelle config Apache :
 <code bash>
@@ Ligne 508: / Ligne 514: @@
 ==== Côté serveur ====
-Cette partie est à effectué sur le serveur qui héberge votre instance MedShake EHR/EDC en tant qu'utilisateur //root//.
+Cette partie est à effectuer sur le serveur qui héberge votre instance MedShake EHR/EDC en tant qu'utilisateur //root//.
 === Configuration OpenVPN ===
-Il nous faut disposer du logiciel OpenVPN. Sous Debian et dérivé il s'installe avec le paquet ''openvpn''.
+Il nous faut disposer du logiciel OpenVPN. Sous Debian et dérivés il s'installe avec le paquet ''openvpn''.
 <code base>
@@ Ligne 518: / Ligne 524: @@
 </code>
-OpenVPN dispose d'un système d'authentification [[wpfr>HMAC]] qui en gros permet de signer les paquets lors de l'établissement d'une connexion et de renforcer la protection contre certains types d’attaques comme les attaques DoS. Nous allons créer une clé spéciale à cet effet grâce à la commande ''openvpn --genkey --secret <keyname>''. Elle doit rester secrète au maximum c'est pour cela qu'a sa création elle n'est lisible et inscriptible que par le propriétaire (mode //600//).
+OpenVPN dispose d'un système d'authentification [[wpfr>HMAC]] qui en gros permet de signer les paquets lors de l'établissement d'une connexion et de renforcer la protection contre certains types d’attaques comme les attaques DoS. Nous allons créer une clé spéciale à cet effet grâce à la commande ''openvpn --genkey --secret <keyname>''. Elle doit rester secrète au maximum c'est pour cela qu'à sa création elle n'est lisible et inscriptible que par le propriétaire (mode //600//).
 <code bash>
@@ Ligne 530: / Ligne 536: @@
 </code>
-Il faut aussi que le service puisse accéder à la CRL pour vérifier la validité des certificats des clients, or la CRL doit être lisible par le service une fois que ce dernier est chrooté. De plus le service ne tournera pas non plus avec les droits //root// il faut donc que la CRL soit lisible par tout le monde. Nous ferons donc ceci :
+Il faut aussi que le service puisse accéder à la CRL pour vérifier la validité des certificats des clients, or la CRL doit être lisible par le service une fois que ce dernier est chrooté. De plus, le service ne tournera pas non plus avec les droits //root//, il faut donc que la CRL soit lisible par tout le monde. Nous ferons donc ceci :
 <code base>
@@ Ligne 541: / Ligne 547: @@
 </WRAP>
-Passons maintenant à la configuration du serveur OpenVPN elle-même. Sous Debian et dérivés on dispose d'emplacements dédiés pour y placer nos configurations OpenVPN cliente et serveur, plusieurs peuvent fonctionner en parallèle et elles se lancent toutes avec une unité systemd dédié. Plaçons notre configuration pour MedShake EHR/EDC dans ''/etc/openvpn/server/medshake.conf'' :
+Passons maintenant à la configuration du serveur OpenVPN elle-même. Sous Debian et dérivés on dispose d'emplacements dédiés pour y placer nos configurations OpenVPN client et serveur, plusieurs peuvent fonctionner en parallèle et elles se lancent toutes avec une unité systemd dédiée. Plaçons notre configuration pour MedShake EHR/EDC dans ''/etc/openvpn/server/medshake.conf'' :
 <file openvpn /etc/openvpn/server/medshake.conf>
@@ Ligne 561: / Ligne 567: @@
 #port 1194
 # Compression lz4. Peut être remplacé par lzo
-# mais dois être indiqué sur la configuration
+# mais doit être indiqué sur la configuration
 # cliente
 compress lz4
@@ Ligne 577: / Ligne 583: @@
 tmp-dir tmp/
-# Ne ni relire les fichiers clés, ni fermer le périphérique tun
+# Ne pas relire les fichiers clés, ni fermer le périphérique tun
 # à la réception d'un signal de relecture de configuration.
 # Nécessaire, car le service fonctionnera avec un utilisateur
@@ Ligne 616: / Ligne 622: @@
 # Emplacement de la clé pour l'authentification HMAC.
 # Possède un sens d'utilisation indiqué à la fin de la ligne.
-# Ici sur le serveur on a mis '0' donc sur les clients ce seront à '1'
+# Ici sur le serveur on a mis '0' donc sur les clients ils seront à '1'
 tls-auth /etc/openvpn/medshake-ta.key 0
@@ Ligne 622: / Ligne 628: @@
 # Ping les clients toutes les 10 secondes
 # et ferme la connexion si le client ne donne pas
-# de nouvelle au bout de 60 secondes.
+# de nouvelles au bout de 60 secondes.
 keepalive 10 60
 # Autorise les clients à changer d'IP et de port durant la connexion
@@ Ligne 628: / Ligne 634: @@
 </file>
-Pour démarrer le serveur on précise l'unité //systemd// qui utilisera note fichier de configuration (''@medshake'') :
+Pour démarrer le serveur on précise l'unité //systemd// qui utilisera notre fichier de configuration (''@medshake'') :
 <code bash>
@@ Ligne 648: / Ligne 654: @@
 === Configuration Apache ====
-Il faut aussi modifier la configuration Apache pour faire en sorte que l’instance MedShake EHR/EDC ne soit accessible qu'au travers de note réseau VPN. Pour cela nous pouvons :
+Il faut aussi modifier la configuration Apache pour faire en sorte que l’instance MedShake EHR/EDC ne soit accessible qu'au travers de notre réseau VPN. Pour cela nous pouvons :
   * Limiter l'écoute du ''VirtualHost'' sur l'adresse du serveur à l’intérieur du réseau VPN (//10.32.64.1//).
@@ Ligne 670: / Ligne 676: @@
     # Même si la connexion à l'instance ne se fait qu'au travers du VPN
-    # il faut continuer d'utiliser https car certaine fonctionnalité
+    # il faut continuer d'utiliser https car certaines fonctionnalités
     # comme l'utilisation de la caméra par le navigateur web (utilisé
-    # par "Phonecapture") ne fonctionnerons pas sur via http (mesure
+    # par "Phonecapture") ne fonctionneront pas sur via http (mesure
     # de sécurité implémentée dans les navigateurs web).
     SSLEngine On
@@ Ligne 685: / Ligne 691: @@
     DirectoryIndex index.php
-    # Fichier de log dédié avec un format compatible avec le lecteur de log intégré à Medshake
+    # Fichier de log dédié avec un format compatible avec le lecteur de log intégré
+    # à Medshake
     CookieName apacheLogUserID
     # /!\ le domaine doit être préfixé d'un point
@@ Ligne 695: / Ligne 702: @@
     CustomLog ${MEDSHAKEEHRLOGFILE} usertrack env=!do_not_log
-    # Des règles de réécriture d'urls sont nécessaires (voir le public_html/.htaccess)
+    # Des règles de réécriture d'urls sont nécessaires(voir le public_html/.htaccess)
     # On s'assure que le module est bien chargé
     RewriteEngine On
-    # N'autorise que le membre du réseau du VPN a accéder aux fichiers ce trouvant dans ce dossier
+    # N'autorise que le membre du réseau du VPN à accéder aux fichiers se trouvant
+    # dans ce dossier
     <Directory /var/www/medshake/>
         SetEnv MEDSHAKEEHRPATH /var/www/medshake/EHR/
@@ Ligne 707: / Ligne 715: @@
     </Directory>
-    # Accès aux url commençant par /phonecapture/ et /pubic/ autorisé aussi pour les client du réseau local (utilisation phone capture et signature des documents)
+    # Accès aux url commençant par /phonecapture/ et /pubic/ autorisé aussi pour les
-    <Location ~ /var/www/medshake/(phonecapture|public)/>
+    # clients du réseau local (utilisation phone capture et signature des documents)
+    <Location ~ /(phonecapture|public)/>
         # /!\ Replacer l'addresse ci-dessous par celle de votre réseau local
         Require ip 192.168.1.0/24
         Require IP 10.32.64.0/24
-        # client de partout avec un certificat valide
-	Require expr %{SSL_CLIENT_VERIFY} == 'SUCCESS
     </Location>
-    # Autorise l'accès aux assets (js, css et images) et pages de maintenance autorisé aussi pour les client du réseau local
+    # Autorise l'accès aux assets (js, css et images) et pages de maintenance
+    # autorisés aussi pour les clients du réseau local
     <Location ~ /(components/|thirdparty/|scss/|img/|js/|favicon.ico|maintenancePublic.html|maintenance.html)>
-        # Ces ressources peuvent êtres mise en cache
+        # Ces ressources peuvent êtres mises en cache
         Header setifempty Cache-Control "must-revalidate"
-        # Fix un bug présent dans le version de apache utilisé dans Debian 10 (2.4.38)
+        # Fixe un bug présent dans le version de apache utilisé dans Debian 10(2.4.38)
-        # qui gènère une entête http Etag mal formé et empéche un retrour 304
+        # qui gènère une entête http Etag mal formée et empéche un retour 304
-        # quant la ressource est en cache.
+        # quand la ressource est en cache.
-        # voire https://bz.apache.org/bugzilla/show_bug.cgi?id=45023#c22
+        # voir https://bz.apache.org/bugzilla/show_bug.cgi?id=45023#c22
         RequestHeader edit "If-None-Match" '^"((.*)-gzip)"$' '"$1", "$2"'
         Require ip 192.168.1.0/24
@@ Ligne 737: / Ligne 745: @@
 <WRAP center round tip 60%>
-Noubliez pas d'activer la nouvelle config apache :
+N'oubliez pas d'activer la nouvelle config Apache :
 <code bash>
@@ Ligne 757: / Ligne 765: @@
 ==== Côté client ====
-Il faut déjà disposer du logiciel OpenVPN sur les postes clients **y compris sur les smartphones si nous voulons accéder à l'instance Medshake EHR/EDC depuis ceci** (ce qui sera nécessaire pour utiliser des fonctionnalités comme //Phonecapture//).
+Il faut déjà disposer du logiciel OpenVPN sur les postes clients **y compris sur les smartphones si nous voulons accéder à l'instance Medshake EHR/EDC depuis ceux-ci** (ce qui sera nécessaire pour utiliser des fonctionnalités comme //Phonecapture//).
-Les clients auront besoin de récupérer leur fichier PKCS12 crée à l'aide d'Easy-RSA ainsi que la clé pour l'authentification HMAC que nous avons crée dans ''/etc/openvpn/medshake-ta.key''. //On peut aussi fournir au client le certificat de la CA (''/var/local/easyrsa/medshake/pki/ca.crt'') si on a utilisé un certificat signé par celle-ci pour le ssl du serveur web. Ainsi le navigateur web pourra identifier le certificat du serveur web (pensez aussi à autoriser l'utilisation du certificat de la CA pour vérifier les certificats des serveurs dans la configuration du navigateur web).//
+Les clients auront besoin de récupérer leur fichier PKCS12 créé à l'aide d'Easy-RSA ainsi que la clé pour l'authentification HMAC que nous avons créé dans ''/etc/openvpn/medshake-ta.key''. //On peut aussi fournir au client le certificat de la CA (''/var/local/easyrsa/medshake/pki/ca.crt'') si on a utilisé un certificat signé par celle-ci pour le ssl du serveur web. Ainsi le navigateur web pourra identifier le certificat du serveur web (pensez aussi à autoriser l'utilisation du certificat de la CA pour vérifier les certificats des serveurs dans la configuration du navigateur web).//
 <WRAP center round important 60%>
-Attention au fichier clé pour l'authentification HMAC, c'est un fichier sensible ayant son importance dans sécurisation des accès au serveur VPN. Évitez de la transmettre par des moyens non sûrs comme en pièce jointe par courriel. Le fichier PKCS12 est chiffre et protégé par un mot de passe, ce n'est pas le cas de la clé HMAC.
+Attention au fichier clé pour l'authentification HMAC, c'est un fichier sensible ayant son importance dans sécurisation des accès au serveur VPN. Évitez de la transmettre par des moyens non sûrs comme en pièce jointe par courriel. Le fichier PKCS12 est chiffré et protégé par un mot de passe, ce n'est pas le cas de la clé HMAC.
 </WRAP>
-Voici un exemple de fichier de configuration client correspondant à la configuration serveur créé précédemment. Il est divisé en deux partis :
+Voici un exemple de fichier de configuration client correspondant à la configuration serveur créé précédemment. Il est divisé en deux parties :
   * Une fixe qui ne change pas d'un client à l'autre.
@@ Ligne 805: / Ligne 813: @@
 # Emplacement de la clé pour l'authentification HMAC
-# La clé à un sens d'utilisation précisé en bout la ligne
+# La clé a un sens d'utilisation précisé en bout la ligne
 # s’il est de  '0' sur le serveur il sera de '1' sur le client
 tls-auth /chemin/vers/ma/ta.key 1