StrongSwan: Établir le gestionnaire de certificats
Pourquoi des certificats?
Ceci est une question justifiée comme on pourrait argumenter qu'une clé
suffirait pour sanctuariser une connexion IPsec pour enfermer des gêneurs
dehors, soit appliquer une procédure similaire à laquelle dans un réseau sans
fil. Cette procédure aurait bien sûr quelques avantages comme il faut seulement
mémoriser la clé et on n'a aucun certificat que pourrait expirer.
Mais il y a un capital hic avec cette chose: Chacun qui acquiert la possession
automatiquement obtient accès à une connexion IPsec si sécurisée que demande
changer la clé – mais le plus grand l'interconnexion IPsec, le plus dispendieux
il devient de munir toutes les stations avec la nouvelle clé. En outre on
pourrait facilement oublier une des stations qui se trouve enfermé dehors.
En plus on ne peut pas vérifier l'identité d'une station bi-univoquement, et
même si elle est utilisée pour chiffrer, une connexion sécuritaire n'est
possible qu'avec considérable effort par ces moyens.
Pour esquiver exactement ces problèmes, des certificats entrent en jeu. Ils non seulement rapportent des clés nécessaires pour chiffrer, mais aussi contiennent simultanément une identification pour le participant auquel le certificat était alloué, même si la durée dans laquelle le certificat est valide et un indicatif qui identifie le certificat. Il est en plus possible de révoquer un certificat déjà alloué, donc il n'est plus possible de l'utiliser: Il serait tout aussi que le certificat soit déjà périmé. On y peut sensiblement circonscrire et drastiquement rendre l'abus difficile.
en hautAcheter ou non?
La réponse sur cette question dépend capitalement sur pourquoi vous voudrez
établir des connexions IPsec. Si vous les utiliserez pour connecter à votre
serveur, vous pouvez simplement vous épargner le circonstance et des dépenses
par utiliser votre propre certificat. En règle générale il est de service si
bien que lequel qu'on a acheté.
Ceci est rien différent lorsque vous voulez offrir les connexions IPsec
industriellement, par exemple par constituer votre serveur comme un standard
entre des ordinateurs de vos clients. Il y est recommandé d'acheter un
certificat, parce qu'une autorité de certification vérifiera et attestera votre
domaine – et en cas échéant votre identité aussi. En plus une autorité de
certification indiquée a des facultés de rapidement révoquer des certificats
compromis pour que personne ne puisse y faire des bêtises; ceci est important
notamment pour des professionnels.
Installer sa propre autorité de certification
Lorsque vous voulez suivre la voie d'utiliser votre propre certificat, il faut
premièrement quelques gestes de votre côté. Vous y établirez une autorité de
certification pour que vous puissiez librement délivrer des certificats et les
révoquer en cas de besoin.
En plus il y a une «signature» digitale nécessaire qui atteste la validité du
certificat pour qu'on puisse faire confiance auquel. Normalement un certificat
sans signature n'a pas de confiance, donc StrongSwan va refuser sa coopération
et rejeter le certificat.
Mais il est important que le fondement de la signature reste exclusivement dans
votre possession pour que personne ne puisse délivrer quelconques certificats à
votre titre et donc obtenir accès à vos connexions IPsec.
Pour commencer il est recommandé que vous créez un répertoire qu'est utilisé exclusivement pour votre autorité de certification, soit qui ne contient rien d'autre et mettez les droits d'accès à une façon que aucun étranger ne pourrait gagner l'accès (ceci est important notamment sur des ordinateurs auxquels plusieurs individus ont l'accès), au mieux dans le répertoire d'accueil de root. Ça assure que personne ne peut gagner accès aux données associées avec votre autorité de certification sauf l'administrateur du système.
Les instructions suivantes sont dérivées des instructions originales sur strongswan.org et prennent en compte que des algorithmes comme MD5 et SHA1 ne sont plus considérés assez sécuritaire entre-temps. En plus une clé plus longue est pareillement de l'avantage.
en hautLe certificat racine
Pour commencer il est important que vous créez un certificat racine sur lequel vous allez baser l'entière arborescence de certificats. Il se déroule en deux pas, et il faut que vous créez une clé.
- Ouvrez une console de commandes et loguez comme root.
- Changez au répertoire de votre autorité de certification.
- Effectuez la commande suivante: ipsec pki --gen --size 4096 > cakey.der
- Immédiatement après effectuez la commande suivante: ipsec pki --self --in cakey.der --dn "C=FR, O=<your_org>, CN=<your_org> CA" --lifetime 10950 --digest sha256 --ca > cacert.der
Ceci crée premièrement une clé RSA avec une longueur de 4096 bits. Il est l'identification de votre autorité de certification: Ne le cédez jamais, et ne le placez jamais sur votre serveur en aucune circonstance! Vous avez besoin seulement du certificat racine pour la racine de votre arborescence de certificats pour vérifier l'identité d'un certificat terminal sans doute, donc oil n'est pas nécessaire de copier cette clé sur votre serveur.
Au deuxième pas vous allez dériver un certificat te votre clé. Il faut lire la
clé que vous avez créée d'abord. En plus il est nécessaire que vous spécifiez
quelques données influençant la validité et la sécurité de votre certificat.
Comme vous allez seulement utiliser le certificat racine sur votre serveur et
normalement ne le cédez pas, mettez la période de validité à une valeur haute
(ils sont presque trente ans qui vous épargnent renouveler le certificat) et
spécifiez un algorithme de signature plus puissant que SHA1 ou MD5 comme ces
deux sont trop facile à craquer maintenant. Ensuite il est nécessaire
d'accorder l'identification fourni par le certificat à votre besoin. Veuillez y
mettre le code aux deux lettres pour votre pays (ici il est FR pour la France)
pour C et le nom de votre organisation pour
O. Faites le même avec le nom commun
(CN) de l'entité pour laquelle vous délivrez le
certificat. Vous devez en outre signer le certificat racine vous-même pour
qu'il devienne valide et il puisse servir comme point d'origine pour des
additionnels certificats. Copiez le certificat racine si créé sur votre serveur
au répertoire /etc/ipsec.d/cacerts/.
Vous y êtes placés pour le pas suivant. En cas de besoin vous pouvez insérer des additionnels calques de certificats comme demandé par votre infrastructure IPsec. En cas de plein des sous-divisions (que vous pourriez aussi spécifier dans l'identification par OU) un, sinon deux, calques intermédiaires pour signer les certificats terminaux sont recommandés que vous pouvez assigner aux individuels départments et sous-divisions si nécessaire.
en hautOptionnel: Des certificats intermédiaires
Il y a des certificats autorisés à signer, mais ils ne sont pas situés au nœud racine de l'arborescence de certificats, mais dont validité est attestée par le certificat racine. Y donnez les deux commandes suivantes en séquence:
- ipsec pki --gen --size 4096 > intermediate-key.der
- ipsec pki --pub --in intermediate-key.der | ipsec pki --issue --cacert cacert.der --cakey --cakey.der --dn "C=FR, O=<your_org>, CN=<your_org> sub CA" --digest sha256 --lifetime 3650 --ca > intermediate-cert.der
+++ AVERTISSEMENT +++ AVERTISSEMENT +++ AVERTISSEMENT +++ AVERTISSEMENT +++
N'utilisez jamais la même clé pour plusieurs
certificats! Lorsque vous jamais perdrez la clé, touts certificats y dérivés
sont immédiatement compromises, et il faut les redélivrer que signigie un
effort plus grand en corrélation pour vous!
Autrefois un seul certificat pourrait être compromis à un coup que vous permet
le révoquer et simplement délivrer à nouveau que limite votre effort
considérablement. Lorsqu'un certificat intermédiaire est si compromis, en règle
générale seulement un petit groupe pour lequel vous pouvez délivrer les
certificats à nouveau assez rapidement est affecté.
Mail il devient considérablement plus mal lorsque le certificat racine était
dérobé comme l'entière arborescence n'est plus fiable. Dans ce cas il faut
remplacer chaque certificat, commençant avec le certificat racine via les
certificats intermédiaires aux certificats terminaux pour rendre établir une
connexion non désirée impossible pour un attaquant! Donc toujours déposez les
clés pour les certificats utilisés pour signer des autres certificats à un
endroit sécuritaire!
Quand vous avez créé le certificat intermédiaire (que se déroule similaire que
créer un certificat racine; la seule différence consiste en ce que vous avez
besoin du certificat racine et la correspondante clé pour le signer) vous
pouvez ou créer des additionnels sous-calques, que se déroule comme décrit ici
sauf qu'il faut utiliser le certificat intermédiaire déjà créé pour signer le
calque inférieur suivant, ou vous maintenant allez créer les certificats
terminaux our des individuels participants de l'interconnexion IPsec prévue.
Copiez ces certificats aussi au /etc/ipsec.d/cacerts/ ensuite. En plus vous pouvez céder les certificats intermédiaires avec leurs clés correspondantes à des autres individus qui sont responsables pour les respectives sous-divisions pour qu'ils puissent délivrer des certificats terminaux de leur côté sans avoir besoin de recourir à vous – mais si nécessaire, soit quelque chose alla de travers dans un départment, vous pouvez rendre chaque certificat délivré là invalide par révoquer le certificat intermédiaire sans avoir besoin de toucher un des certificats terminaux délivrés.
Notice: N'imbriquez pas trop des calques entre le certificat racine et les certificats terminaux! En premier établir une connexion est unnécessairement retardé avec chaque additionnel calque, et vous allez vous disperser plus facilement lorsque vous devez administrer plus de calques et branchements! Ici moins, c'est plus et il est mieux à dessiner l'arborescence si compacte comme possible et seulement introduire les calques que sont absolument nécessaires. De toute façon plus de deux calques ne seront pas nécessaires, et la norme plutôt serait qu'un seul calque suffit.
en hautLe certificat du serveur
Il y a quelques demandes strictes qu'un certificat doit satisfaire pour que son authenticité puisse être confirmée. Il y est nécessaire qu'on peut associer l'identification biunivoquement à un serveur, soit il y a un seul certificat assigné à un serveur et chaque certificat est installé sur un seul serveur. Lorsque les mesures de sécurité sont brisées sur un serveur, le certificat affecté peut être révoqué et délivré à nouveau sans toucher les autres serveurs dans l'interconnexion IPsec. On y ne se paralyse pas, et un attaquent pourrait au pire dommager au plus un seul serveur. Les autres serveurs encore restent complètement intacts.
Pour ce certificat on a besoin aussi d'une approche à deux étages; la
différence à titre d'un certificat intermédiaire est toutefois qu'on ne le
puisse utiliser pour signer des additionnels sous-certificats.
Veuillez y procéder comme suivant:
- ipsec pki --gen --size 4096 > serverkey.der
- ipsec pki --pub --in serverkey.der | ipsec pki --issue --cacert cacert.der --cakey cakey.der --dn "C=FR, O=<your_org>, CN=<your:org:entity>" --digest sha256 --lifetime 730 > servercert.der
Dans cet exemple le certificat de serveur est signé directement avec le
certificat racine. Il est l'avantage de cette procédure qu'on obtient une
structure d'arborescence très plate. Mais le désavantage est qu'on ne peut plus
utiliser touts certificats lorsqu'il faut révoquer le certificat racine et il
faut les délivrer à nouveau!
Si vous avez introdui un calque intermédiaire, vous ne devez pas remplacer le
certificat racine, mais il suffit que vous révoquez le certificat intermédiaire
du ´e l'arborescence affectée pour remédier à un problème. Les autres reste
actif et peut continuer travailler via IPsec.
Lorsque vous voulez utiliser des certificats intermédiaires vous devez
remplacer cacert.der et
cakey.der par les noms du certificat et clé en
question pour créer le certificat terminal. Autrefois cette procédure est
pareille dans les deux cas.
Lorsque vous avez créé le certificat du serveur, placez-le dans /etc/ipsec.d/certs/ et copiez la correspondante clé au /etc/ipsec.d/private/. Touts certificats nécessaires y sont déjà installés sur le serveur.
en hautLe certificat de l'utilisateur
En fin de compte un certificat de l'utilisateur est créé pareillement à un
certificat serveur, sauf il est recommandé que vous donnez un nom secondaire
que rend vérifier l'identité plus facile. Vous non seulement pouvez vous
épargner donner la complète identification, mais aussi travailler avec des
gardes-places et donc permettre l'accès à un groupe des individus avec une
seule définition de connexion – naturellement à condition qu'ils présentent
des certificats valides pour votre connexion IPsec.
En plus il est recommandé de demander le nom d'utilisateur et le mot de passe
correspondant. Donc quelqu'un qui saisit le certificat terminal avec sa clé
n'a pas nécessairement gagné, mais il doit encore vaincre un autre obstacle
pour établir une connexion IPsec. Mais il pourrait que le certificat en
question soit révoqué jusque-là.
Pour créer un certififcat d'utilisateur effectuez les commandes suivantes:
- ipsec pki --gen --size 4096 > userkey.der
- ipsec pki --pub --in userkey.der | ipsec pki --issue --cacert cacert.der --cakey cakey.der --dn "C=FR, O=<your_org>, CN=<userid>" --san <userid> --digest sha256 --lifetime 730 > usercert.der
Comme vous avez découvert il y a un no alternatif qui était donné que vous
pouvez utiliser au lieu de l'entière identification. D'ordinaire un nom
alternatif est une identification de l'utilisateur de la forme
<nom d'utilisateur>@<entité>, une adresse courriel, etc.
Il faut que cette identification coïncide avec l'indicatif de l'utilisateur que
vous utilisez pour connecter à votre passerelle IPsec, autrement StrongSwan va
se plaindre et la connexion sera rejetée.
Pour utiliser ce certificat, installez-le sur votre propre
ordinateur dans le répertoire /etc/ipsec.d/certs/
et la clé correspondante dans le répertoire
/etc/ipsec.d/private/.
Vous n'avez pas besoin d'installer le certificat racine ou des éventuels
certificats intermédiaires, c'est pourquoi il n'est pas une bonne idée de les
céder sauf il est absolument nécessaire.
Révoquer des certificats
De temps en temps il serait nécessaire de révoquer un certificat délivré qu'est
encore valide, soit que la personne en question l'a perdu ou il lui fut dérobé
avec sa clé, soit que la personne en question veut se déconnecter permanemment
de votre interconnexion IPsec ou n'importe quelle raison. Il est nécessaire
dans ce cas que vous révoquez le certificat en question pour que personne ne le
puisse plus utiliser même s'il n'est encore expiré. Lorsque vous devez révoquer
un certificat, effectuez cette commande (veuillez faire attention que vous avez
le certificat à votre disposition pour le révoquer!):
ipsec pki --signcrl --cacert cacert.der --cakey cakey.der
--reason <reason> --cert usercert.der > crl.der
Vous pouvez donner les valeurs suivantes comme raison:
Raison de révocation | Signification |
---|---|
key-compromise | La clé sur laquelle le certificat est basé était dérobée ou craquée. La connexion affectée n'est plus sécuritaire. |
ca-compromise | L'autorité de certification est compromis, p. ex. parce que la clé sur laquelle le certificat en question était craquée ou dérobée. Le certificat affecté et tout au-dessous n'est plus sécuritaire. |
affiliation-changed | L'entité affectée n'est plus affiliée à l'interconnexion IPsec, soit qu'elle a entierement quitté l'interconnexion, soit qu'elle s'a rattachée à une autre sous-division logique. Le certificat ne peut plus être utilisé en tout cas. |
superseded | Le certificat était remplacé par un autre et n'est plus utilisé. |
cessation-of-operation | L'entité qui a délivrée le certificat est en train de cesser ses activités. On n'a plus besoin du certificat assigné. |
certificate-hold | Le certificat est révoqué temporairement. |
Enfin placez cette liste dans le répertoire /etc/ipsec.d/crls/. Redémarrez StrongSwan ensuite par systemctl restart strongswan.service et le certificat en question est révoqué. On y ne peut pas l'utiliser pour connecter à votre passerelle IPsec.
en hautPourrait-on se poser comme une autorité de certification publique?
Lorsque vous en réfléchiriez, je veux vous dire franchement:
Abstenez-vous d'en faire, notamment à votre intérêt
personnel. Lorsqu'il s'agit des données confidentielles – et si vous avez
affaire à la cryptographie, les données confidentielles ne sont pas éloignées –
vous marchez sur la corde raide.
Offrir des certificats soi-même semble charmant à première vue, mais il y a
plein d'impondérabilités qu'on ne peut guère se faire une vue d'ensemble. Il y
commence que votre serveur est sans cesse exposé aux attaques de l'Internet et
un serveur qui héberge une autorité de certification pose un but gratifiant
pour quelconques malfaiteurs qui compromettent votre entière autorité de
certification si tel attaque jamais succède, donc gagnant l'accès à chaque
connexion IPsec si sanctuarisées. En fin de compte ils sont bien placés pour
se délivrer des certificats propres au nom de votre autorité de certification
qu'ils peuvent user de votre interconnexion IPsec. Encore pire: Un attaquant
pourrait suivre l'entière communication pensée sanctuarisée par vos
certificats!
La responsabilité est un autre point délicat. Comme vous ne pouvez pas per se
exclure tout droit à dédommagement (vous en êtes sûrement en cas de dol ou
négligence grave s'il concerne l'indemnité) comme ils étaient vos certificats
que furent compromis, les dégâts peuvent s'éléver à plusieurs millions. Il y a
la question si votre assurance R. C. y est de la partie du tout lorsque vous
délivriez des certificat aux tiers à la légère.
En plus la question que se pose toujours est comment vous voulez vérifier la
légitimité des demandes de l'Internet sans faute. Des autorités de
certification indiquées ont et de personnel nécessaire et de la discipline
d'éveil requise dans ce domaine pour l'effectuer, mais vous comme un individu
vous menez un combat perdu d'avance. Et même si vous seulement délivrerez des
certificats aux personnes que vous connaissez en personne, tel entreprise pose
un risque incalculable. Vous devez garantir à n'importe quelle heure que
l'intégrité de votre autorité de certification est sauvegardée. Ceci comporte
des mesures de sécurité sur votre serveur qui empêchent que n'importe qui
peut se connecter à votre serveur ainsi qu'enregistrer des activités
inhabituelles. Et si quelqu'un a pu gagner l'accès, il faut que vous réagissez
le plus vite possible, au mieux immédiatement, et résolvez le problème avant
que quelqu'un fasse du malheur avec les données éventuellement écorniflées.
Dans le cas d'une autorité de certification il comporte que vous devez révoquer
touts certificats affectés.
Lorsque vous pensez encore d'établir une autorité de certification publique en
dépit de toute mise en garde, il néanmoins faut que vous vous enquérrez sur
cette problématique. Consultez en tout cas un avocat qui peut vous conseiller
dans des questions juridiques et vous indique notamment aux embûches légales
allant de pair avec ce sujet. En plus absolument demandez des renseignements à
votre assureur s'il au fait régularise des dégâts qui pourraient se produire
et combien une assurance R. C. que couvre ces dommages coûte à vous. Vous en
outre avez besoin d'un spécialiste TIC qui s'y connaît dans la sécurité dans le
secteur informatique et vous aide à sécuriser votre serveur contre des essais
d'attaque. Et en fin de compte: Maintenez votre système à jour en principe et
n'utilisez que des serveurs dédiés pour votre entreprise. Vous y avez la
garantie que vous êtes le seul individu qui a d'accès auquel et personne ne
pourrait empiéter sur votre domaine.
Concernant cette entreprise vous pouvez rester assuré d'ue fait: Cette affaire
ne sera pas facile du tout, et en plus vous devez prévoir un considérable
effort lorsque vous voluez avoir à peu près de succès, d'autant qu'il y a assez
de concurrence dans ce domaine.