Les deux révisions précédentes
Révision précédente
Prochaine révision
|
Révision précédente
|
doc:access_distant [2023/11/09 21:56] |
doc:access_distant [2023/11/12 22:22] (Version actuelle) |
===== Préambule ===== | ===== 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 accessible 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 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 disponibles 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 : | 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. | Si ce n'est pas le cas, il vous faudra sûrement apporter des adaptations à la procédure selon votre environnement. |
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. | 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%> | <WRAP center round info 60%> |
| |
* La vérification des certificats des clients directement avec Apache. | * 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 : | Dans les deux cas, il nous faudra disposer de notre CA. Il faut donc procéder en deux étapes : |
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. | 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'utilisateurs nombreuse ou changeante. | Plutôt recommandé si nous avons une base d'utilisateurs nombreuse ou changeante. |
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. | 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'utilisateurs peu nombreuse ou peu changeante. | Plutôt recommandé si nous avons une base d'utilisateurs peu nombreuse ou peu changeante. |
</code> | </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> | <code bash> |
</code> | </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> | <code bash> |
</code> | </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> | <code bash> |
</code> | </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. | * ''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> | <code bash> |
| |
<WRAP center round important 80%> | <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> | </WRAP> |
| |
| |
# Certificat et clé créés par la pki pour le serveur. | # 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 | SSLCertificateFile /var/local/easyrsa/medshake/pki/issued/medshake.crt |
SSLCertificateKeyFile /var/local/easyrsa/medshake/pki/private/medshake.key | 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 | SSLCACertificateFile /var/local/easyrsa/medshake/pki/ca.crt |
# Liste des certificats révoqués, permet de refuser l'accès aux certificats déclarés 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 | 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 fonctionnalité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 | SSLVerifyClient optional |
# Limite la vérification aux certificats du client. | # Limite la vérification aux certificats du client. |
# (inutile ici de contrôler toute la chaîne on n'a qu'un niveau) | # (inutile ici de contrôler toute la chaîne on n'a qu'un niveau) |
SSLCARevocationCheck leaf | |
SSLVerifyDepth 1 | SSLVerifyDepth 1 |
# Sécurité renforcée, nous n'utiliserons que la version la plus récente de TLS | # 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 | SSLProtocol -all +TLSv1.3 |
# Ajoute l'entête http pour le HSTS | # Ajoute l'entête http pour le HSTS |
DirectoryIndex index.php | 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 | CookieName apacheLogUserID |
# /!\ le domaine doit être préfixé d'un point | # /!\ le domaine doit être préfixé d'un point |
CustomLog ${MEDSHAKEEHRLOGFILE} usertrack env=!do_not_log | 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é | # On s'assure que le module est bien chargé |
RewriteEngine On | RewriteEngine On |
</Directory> | </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 |
| # clients du réseau local sans présenter ce certificat valide |
<Location ~ /(phonecapture|public)/> | <Location ~ /(phonecapture|public)/> |
# /!\ Replacer l'addresse ci-dessous par celle de votre réseau local | # /!\ Replacer l'addresse ci-dessous par celle de votre réseau local |
</Location> | </Location> |
| |
# 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 | # 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)> | <Location ~ /(components/|thirdparty/|scss/|img/|js/|favicon.ico|maintenancePublic.html|maintenance.html)> |
# Ces ressources peuvent êtres mise en cache | # Ces ressources peuvent êtres mise en cache |
Header setifempty Cache-Control "must-revalidate" | Header setifempty Cache-Control "must-revalidate" |
# Fixe 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 retour 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"' | RequestHeader edit "If-None-Match" '^"((.*)-gzip)"$' '"$1", "$2"' |
Require ip 192.168.1.0/24 | Require ip 192.168.1.0/24 |
| |
<WRAP center round tip 60%> | <WRAP center round tip 60%> |
Noubliez pas d'activer la nouvelle config apache : | N'oubliez pas d'activer la nouvelle config Apache : |
| |
<code bash> | <code bash> |
</code> | </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> | <code base> |
</WRAP> | </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> | <file openvpn /etc/openvpn/server/medshake.conf> |
#port 1194 | #port 1194 |
# Compression lz4. Peut être remplacé par lzo | # Compression lz4. Peut être remplacé par lzo |
# mais dois être indiqué sur la configuration | # mais doit être indiqué sur la configuration |
# cliente | # cliente |
compress lz4 | compress lz4 |
</file> | </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> | <code bash> |
DirectoryIndex index.php | 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 | CookieName apacheLogUserID |
# /!\ le domaine doit être préfixé d'un point | # /!\ le domaine doit être préfixé d'un point |
CustomLog ${MEDSHAKEEHRLOGFILE} usertrack env=!do_not_log | 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é | # On s'assure que le module est bien chargé |
RewriteEngine On | RewriteEngine On |
| |
# N'autorise que le membre du réseau du VPN à accéder aux fichiers se 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/> | <Directory /var/www/medshake/> |
SetEnv MEDSHAKEEHRPATH /var/www/medshake/EHR/ | SetEnv MEDSHAKEEHRPATH /var/www/medshake/EHR/ |
</Directory> | </Directory> |
| |
# Accès aux url commençant par /phonecapture/ et /pubic/ autorisé aussi pour les clients 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 |
| # clients du réseau local (utilisation phone capture et signature des documents) |
<Location ~ /(phonecapture|public)/> | <Location ~ /(phonecapture|public)/> |
# /!\ Replacer l'addresse ci-dessous par celle de votre réseau local | # /!\ Replacer l'addresse ci-dessous par celle de votre réseau local |
</Location> | </Location> |
| |
# Autorise l'accès aux assets (js, css et images) et pages de maintenance autorisés aussi pour les clients 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)> | <Location ~ /(components/|thirdparty/|scss/|img/|js/|favicon.ico|maintenancePublic.html|maintenance.html)> |
# Ces ressources peuvent êtres mises en cache | # Ces ressources peuvent êtres mises en cache |
Header setifempty Cache-Control "must-revalidate" | Header setifempty Cache-Control "must-revalidate" |
# Fixe 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ée et empéche un retour 304 | # qui gènère une entête http Etag mal formée et empéche un retour 304 |
# quand 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"' | RequestHeader edit "If-None-Match" '^"((.*)-gzip)"$' '"$1", "$2"' |
Require ip 192.168.1.0/24 | Require ip 192.168.1.0/24 |
| |
<WRAP center round tip 60%> | <WRAP center round tip 60%> |
Noubliez pas d'activer la nouvelle config apache : | N'oubliez pas d'activer la nouvelle config Apache : |
| |
<code bash> | <code bash> |
==== Côté client ==== | ==== 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%> | <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> | </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. | * Une fixe qui ne change pas d'un client à l'autre. |