Gestion de clefs RSA

Le présent petit paquetage de gestion de clefs RSA, fondé sur l'outil en ligne de commande openssl, peut être trouvé dans le sous-répertoire easy-rsa de la distribution OpenVPN.

Ceci constitue les notes de référence. Les instructions pas à pas se trouvent dans le HOWTO :

http:openvpn.net/howto.html

Installation

1. éditez le fichier vars ;
2. faites pointer KEY_CONFIG vers le fichier openssl.cnf inclus dans la présente distribution ;
3. faites pointer KEY_DIR vers le répertoire qui contiendra les clefs, certificats, etc.

Ce répertoire peut ne pas exister mais s'il existe, il sera purgé par un rm -rf, donc soyez prudent dans la détermination de KEY_DIR ;

• (optionnel) ajustez les autres champs du fichier vars en fonction de vos données de site.

Vous pouvez souhaiter augmenter KEY_SIZE à 2048 si vous êtes paranoïaque et n'avez rien à faire de ralentir le traitement des clefs mais 1024 est certainement parfait pour les tests. KEY_SIZE doit être configuré à l'identique des deux côtés de la connexion SSL/TLS ;

1. . vars
2. ./clean-all
3. Pour la création de certificats, clefs et requêtes de signature de certificats, vous devez comprendre que seuls les fichiers .key doivent rester confidentiels. Les fichiers .crt et .csr peuvent être transmis sur des canaux non sécurisés tels que le courriel en texte simple ;
4. il n'est jamais nécessaire de copier un fichier .key entre des ordinateurs. Normalement, chaque machine doit avoir sa propre paire certificat/clef.

Créer son propre certificat d'autorité racine de certification (root CA)

• ./build-ca

Les fichiers ca.crt et ca.key seront créés dans le répertoire KEY_DIR

Créer un certificat d'autorité intermédiaire de certification (optionnel)

• ./build-inter inter

Les fichiers inter.crt et inter.key seront créés dans le répertoire KEY_DIR et signés avec votre certificat racine.

Créer les paramètres Diffie-Hellman

Cette étape est nécessaire du côté serveur d'une connexion SSL/TLS.

• ./build-dh

Créer une requête de signature de certificat

Procédure pour signer un certificat si le certificat de l'autorité racine est contrôlé par une personne ou une autorité tierce ou encore s'il réside sur une autre machine.

1. récupérez le certificat ca.crt de votre autorité de certification. Quoique ce transfert puisse être réalisé par une canal non sécurisé, pour éviter une attaque de type homme du milieu (man-in-the-middle), il faut garantir que ca.crt n'ait pas été compromis. Les grosses autorités de certification résolvent ce problème en greffant leurs certificats racine dans les navigateurs web courants. Une méthode simple pour vérifier une autorité racine est de téléphoner à l'émetteur pour confirmer que la signature md5sum ou sha1sum du certificat ca.crt correspond (par exemple avec la commande « md5sum ca.crt »).
2. choisissez un nom pour votre certificat, par exemple le nom de votre ordinateur. Dans notre exemple, nous utilisons « mycert ».
3. ./build-req mycert
4. la plupart des champs peuvent être ignorés sauf « Common Name » qui doit être unique, tel que le nom de votre ordinateur.

Laissez vides tous les champs mot de passe, sauf si vous voulez protéger votre clef privée de cette manière. L'utilisation d'un mot de passe n'est pas nécessaire -- elle rendra votre clef plus sécurisée mais aussi plus complexe à utiliser, puisque vous devrez fournir celui-ci à chaque utilisation de la clef. Note : pour utiliser un mot de passe, utilisez la commande ./build-req-pass au lieu de ./build-req.

1. la clef sera placée dans $KEY_DIR/mycert.key
2. la requête sera placée dans $KEY_DIR/mycert.csr
3. expédiez mycert.csr au détenteur de l'autorité racine ; cela peut être effectué par un canal non sécurisé.
4. une fois le fichier.csr signé par le certificat de l'autorité racine, vous recevrez un fichier contenant votre certificat mycert.crt. Placez-le dans votre répertoire KEY_DIR.
5. la combinaison des fichiers mycert.crt, mycert.key et ca.crt peut désormais être utilisée pour sécuriser une extrémité d'une connexion SSL/TLS.

Signer une requête de signature de certificat

(NdT: Procédure pour signer un certificat si l'on est soi-même détenteur du certificat de l'autorité racine)

• ./sign-req mycert

Le fichier mycert.crt sera créé dans le répertoire KEY_DIR à l'aide des informations des fichiers mycert.csr et du certificat d'autorité racine.

Créer et signer une requête de signature de certificat à l'aide d'un certificat racine installé en local

Ce script engendre et signe un certificat en une seule étape mais nécessite que le certificat et la clef privée engendrés soient transmis au destinataire par un canal sécurisé.

1. ./build-key mycert (sans protection par mot de passe)
2. OU ./build-key-pass mycert (avec protection par mot de passe)
3. OU ./build-key-pkcs12 mycert (format PKCS 12)
4. OU ./build-key-server mycert (avec nsCertType=server)
5. mycert.crt et mycert.key seront créés dans le répertoire KEY_DIR, mycert.crt sera signé par l'autorité racine. Avec ./build-key-pkcs12, une fichier supplémentaire contenant la clef privée, le certificat et le certificat de l'autorité mycert.p12 sera créé.

Important

Pour éviter une possible attaque de l'homme du milieu qui consiste, pour un client autorisé, à tenter de se connecter à un autre client en se faisant passer pour le serveur, assurez-vous d'imposer une méthode de vérification du certificat par le client. Actuellement, quatre méthodes différentes permettent d'accomplir cela, par ordre de préférence décroissante :

1. créez votre certificat serveur avec le script build-key-server : le certificat engendré sera marqué comme serveur uniquement par nsCertType=server. Ajoutez ensuite la ligne « ns-cert-type server » à votre configuration client. Cela interdira aux clients de se connecter à un server qui ne dispose pas de la désignation nsCertType=server, même si le certificat a été signé par l'autorité indiqué dans la configuration d'OpenVPN (directive --ca) ;
2. utilisez la directive --tls-remote sur le client pour accepter/rejeter la connexion serveur en fonction du nom commun (« Common Name ») du certificat serveur ;
3. utilisez un script ou un greffon --tls-verify pour accepter/rejeter la connexion serveur en fonction d'un test personnalisé sur des éléments du sujet X509 embarqué dans son certificat ;
4. signez les certificats des serveurs avec une autorité et ceux des clients avec une autre. La directive de configuration « ca » du client devra référencer l'autorité de signature des serveurs tandis que celle des serveurs devra référencer l'autorité de signature des clients.

Notes

Pour afficher les champs d'un certificat :

openssl x509 -in cert.crt -text