4D OPENSSL : Créez vos propres certificats SSL autosignés

Dans cette note technique nous vous proposons un outil de génération de certificats SSL autosignés fait en 4D 2004 et basé sur la librairie de cryptographie Openssl. L'ouverture de la version 2004 de 4D sur des programmes externes grâce à la nouvelle commande LANCER PROCESS EXTERNE a rendu possible la réalisation de ce type d'applications. Cette commande vous permet non seulement de lancer un process externe depuis 4D, mais aussi de communiquer avec ce dernier via des paramètres d'entrée et de sortie.

SSL (Secure Socket Layer) est actuellement le procédé standard de cryptage et de sécurisation des données sur Internet. Il est indépendant du protocole de communication employé, et peut donc servir à crypter des connexions HTTP, FTP, POP ou IMAP. En effet, SSL agit telle une couche supplémentaire, permettant d'assurer la sécurité des données, située entre la couche application et la couche transport (protocole TCP par exemple). De par ce mode SSL, les chances d'interceptions de vos données confidentielles et mots de passe sont quasi inexistantes, ce qui n'est pas forcément le cas via une connexion normale où les données sont envoyées en clair. Cette technologie offre donc la possibilité de travailler et discuter dans un environnement sûr. Elle consiste à utiliser un cryptage SSL et repose sur l'utilisation de certificats pour rendre confidentiel les échanges au travers des réseaux.

Pour mettre en place ce procédé de sécurisation, nous allons nous appuyer sur un package logiciel incluant une librairie assez complète de cryptographie appelé « Openssl ». La dernière version disponible au moment de la rédaction de cette note technique est la version 0.9.7f.

L'utilisation de OpenSSL est légale en France. La Free Software Foundation Europe, qui milite pour les logiciels libres, a obtenu de la DCSSI (Direction Centrale pour la sécurité des systèmes d'information), une cellule du SGDN (Secrétariat général pour la défense nationale), en date du 15 juillet 2002, une autorisation générale de fourniture en vue de l'utilisation et de l'importation de OpenSSL (0.9.6d et versions suivantes), et une dispense de licence des Douanes pour l'exportation. Malgré un certain assouplissement des règles françaises pour les simples utilisateurs (les chercheurs, les universitaires, etc.) il est toujours obligatoire, pour les fournisseurs de solutions, soit de faire une déclaration (systèmes dont la clé ne dépasse pas 128 bits), soit d'attendre l'autorisation formelle de la DCSSI pour des systèmes plus puissants. C'est le cas pour Openssl, car ce logiciel n'a pas de limite dans sa force de cryptage. Vous trouverez plus de détails sur le site de la FSFE : http://www.france.fsfeurope.org/

Sous Windows, il faudra télécharger une version d'Openssl compilée pour Windows. Pour réaliser la présente note, nous avons utilisé la version 0.9.7f. Vous pouvez la télécharger depuis http://curl.haxx.se/download.html ou http://www.stunnel.org . Pour aller plus vite, vous pouvez télécharger et installer PackageOpenssl.ZIP, prêt à utiliser et qui contient tous les fichiers nécessaires. Vous devez, ensuite créer un répertoire sur votre disque (par exemple « C:\OpenSSL ») pour y copier tous les fichiers (openssl.exe…etc.). En revanche, vous n'avez rien à installer sous MacOS X puisque ce système propose en natif cette librairie cryptographique avec des clés de 128 bits. Il est également important de suivre les évolutions de la libraire OpenSSL et de récupérer les dernières mises à jour en visitant les sites indiqués plus haut ainsi que le site officiel http://www.openssl.org/.

Le but de cette note technique n'est pas de détailler le fonctionnement de la librairie Openssl, mais plutôt de vous expliquer comment l'exploiter via la commande LANCER PROCESS EXTERNE de 4D 2004 pour générer vos certificats SSL.

La syntaxe d'une commande Openssl est la suivante :

Openssl ( type de traitement ) [ arguments spécifiques … ]

Le premier argument spécifie le type d'opération que l'on souhaite effectuer (par exemple : génération d'une clé, d'une demande de certificat et/ou d'un certificat …), puis suivent les arguments spécifiques à l'opération demandée. Les pages de manuel sont très bien documentées et peuvent être consultées à l'adresse suivante : http://www.openssl.org/docs/

L'ouverture de la nouvelle commande LANCER PROCESS EXTERNE de 4D 2004 sur des programmes externes a rendu possible la réalisation de cette note technique. C'est une approche d'ouverture très intéressante qui peut être facilement adopté pour d'autres besoins. En effet, cette commande nous permet non seulement de lancer un process externe depuis 4D, sous MacOS X et Windows, mais aussi de communiquer avec ce dernier via des paramètres d'entrée, de sortie et de flux d'erreurs. Il est donc essentiel de comprendre les mécanismes internes mis en jeux par cette commande pour pouvoir en tirer parti. Voici la syntaxe exacte de cette commande :

LANCER PROCESS EXTERNE (« Chemin à l'application » {; STDIN {; STDOUT{; STDERR }}})

• Chemin à l'application : ce paramètre est obligatoire et doit contenir le chemin d'accès absolu de l'application à exécuter ainsi que des éventuels arguments.
• STDIN, STDOUT et STDERR sont des paramètres facultatifs de types Blob ou Texte. Le premier est un paramètre d'entrée (doit être renseigné avant l'exécution) alors que les deux autres sont des paramètres de retour (renseignés après l'exécution).

Le schéma suivant illustre les mécanismes de communication entre 4D 2004 et le programme externe avec lequel on cherche s'interfacer :

Il est important de faire la différence entre les arguments passés à l'application externe et les paramètres d'entrée stdin. Ces deux paramètres transitent dans des canaux (« pipes » en anglais) différents. Les arguments correspondent aux paramètres attendus par l'application et doivent respecter un formatage bien défini. Par exemple, le chemin d'accès à un document à ouvrir. Par contre, le paramètre ou le flux d'entrée est une quantité de données attendue par l'application sur le canal stdin. Lorsque ce type de paramètre est passé à la commande LANCER PROCESS EXTERNE, 4D le gère comme une quantité de données binaires et l'envoie telle quelle à l'application externe via le canal stdin sans se soucier de son contenu. Ensuite, 4D se met à l'écoute des canaux stdout et stderr de cette application.

Lorsque l'exécution de cette application est terminée, 4D renseigne les deux derniers paramètres par leur valeur de retour respective sans effectuer le moindre traitement sur leur contenu. En revanche, 4D met sa variable système OK à 1 lorsque la commande s'exécute correctement et à 0 dans le cas contraire. L'exécution correcte de la commande LANCER PROCESS EXTERNE ne garantit pas l'exécution correcte de l'application externe, c'est donc du ressort du développeur d'analyser les valeurs de retour (stdout et stderr) pour savoir ce qui s'est réellement passé.

Pour mettre en évidence ces notions, nous vous proposons un exemple concret qui est celui de la commande de génération d'une demande de certificat. Cette commande nécessite, d'une part, des arguments qui font partie du premier paramètre de la commande LANCER PROCESS EXTERNE et d'autre part, des informations indispensables pour la création du certificat. Ces informations seront passées via le canal d'entrée stdin grâce au deuxième paramètre.

Voici l'écriture de la commande telle quelle doit être saisie dans un Shell du Terminal sous MacosX ou dans une fenêtre DOS sous Windows.

   openssl req -new -key Chemin_du_clé  -out Chemin_demande_de_certificats  < Chemin_de_ infoscertificat.txt 

Avec

• « Openssl » est la commande du package Openssl.
• « req -new -key  Chemin_du_clé -out Chemin_demande_de_certificat » sont les arguments nécessaires à la génération de la demande de certificat (le chemin d'accès de la clé primaire et le chemin d'accès complet au fichier contenant cette demande.
• < Chemin_de_infoscertificat.txt : ce sont les paramètres d'entrée (stdin). Notez la présence du caractère « < » avant le paramètre d'entrée correspondant au chemin d'accès à un fichier « infocertificat.txt » contenant les informations sur le certificat. Si on ne passe pas ce paramètre, on sera amené à saisir manuellement toutes les infos dans un Shell du terminal sous MacosX ou dans une fenêtre DOS sous Windows.

Au niveau de 4D, l'exécution de cette commande consiste à concaténer la commande « openssl » avec les arguments et les passer dans le premier paramètre de la commande LANCER PROCESS EXTERNE. En revanche, les informations d'entrée seront passées au flux d'entrée (stdin) qui correspond au deuxième paramètre de la commande. Notez qu'il ne s'agit pas de passer la chaîne « < Chemin_de_infoscertificat.txt » dans le flux d'entrée STDIN, mais plutôt le contenu réel du paramètre. C'est-à-dire le contenu du fichier « infoscertificat.txt ». Voici le code 4D de la base de démo correspondant à cette opération :

DOCUMENT VERS BLOB(VCheminInfosCertificat;$blob)
    VIn:=BLOB vers texte($blob;Texte sans longueur )
LANCER PROCESS EXTERNE(VOpenssl_Commande;VIn;VOut;Verror)

Avec :

VcheminInfosCertificat : Une variable texte contenant le chemin d'accès au un fichier des informations sur le certificat « infoscertificat.txt ».

VIn : Une variable texte contenant les données en entrée STDIN

Une paire de clés, c'est une clé publique et une clé privée stockées dans un même fichier « Key.pem ». Voici comment on écrit, d'une façon générale, la commande permettant de générer une paire de clés RSA :

openssl genrsa -out Chemin_de_LaClé(.pem)  Var_LongueurDeLaClé 

Avec

• Chemin_de_LaClé(.pem) : le chemin d'accès à la clé nouvellement crée (d'extension .pem).
• Var_LongueurDeLaClé: la longueur de cette clé.

Par exemple, la commande suivante génère une paire de clés RSA de longueur 1024 bits à la racine du disque « C: »  :

openssl genrsa -out C:/Key.pem  1024

On peut éventuellement générer une paire de clé protégées par DES3 c'est-à-dire chiffrer le résultat en utilisant l'algorithme triple DES. Développé en 1974 par IBM, l'algorithme de chiffrement DES (Data Encryption Standard) est devenu un standard en 1977. Cette solution chiffre les données trois fois. Elle est aujourd'hui la plus communément utilisée pour protéger les données des regards indiscrets. Elle reste toutefois beaucoup plus lente, car elle nécessite trois opérations de chiffrement successives au lieu d'une seule et autant de manipulations côté destinataire. Voici la commande à utiliser pour générer une paire de clé protégée par DES3 :

openssl genrsa -des3 -out Chemin_de_LaClé(.pem)  Var_LongeurDeLaClé 

Le chiffrement triple DES requiert une protection par mot de passe, ou plutôt par passphrase qui doit être fournie lorsque OpenSSL le demande. La paire de clés stockée dans le fichier Key.pem sera donc chiffrée. Ceci peut facilement être vérifié en examinant les deux premières lignes ce cette paire de clé :

   -----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,93F9B4627D877570
[…]
-----END RSA PRIVATE KEY-----

   openssl rsa -noout -text -in C:/Key.pem
   openssl rsa -pubout -in C:/Key.pem

Bien entendu pour être autorisé à effectuer ces opérations dans le cas d'une paire de clés protégées par un chiffrement tripe DES3, vous serez amené à saisir la passphrase requise.

Lors de la génération d'une paire de clés chiffrées via la commande la commande LANCER PROCESS EXTERNE, la saisie de passphrase ne peut être automatisée en utilisant le passage des paramètres. Ceci est une contrainte imposée par Openssl pour forcer la saisie manuelle pour des raisons évidentes de sécurité.

Sous Windows, une fenêtre MS-DOS pour la saisie de passphrase sera donc ouverte à partir de 4D et se automatiquement refermera après deux validations (de la première saisie et de la confirmation) comme le montre la photo d'écran ci-dessous. Bien entendu, cette passphrase doit être aussi fournie lors de génération d'une demande certificat et du certificat final à partir d'une clé cryptée avec DES3 sans quoi la génération ne pourra pas se faire.

Le système MacOSX n'autorise pas, dans ce contexte, l'ouverture automatique d'un Shell du Terminal lors de l'utilisation du langage des commandes. Ceci est bien une spécificité du système et n'est donc pas un bug de la commande LANCER PROCESS EXTERNE. Afin de faciliter la génération des certificats cryptés avec DES3 sous MacOS X, la base exemple construit pour vous les requêtes adéquates en fonction des paramètres que vous aurez définis dans le tableau de bord. Il convient ensuite de les copier dans le presse-papiers, les coller dans un Shell du Terminal et les exécuter. Les copies d'écran suivantes montrent les dialogues qui seront affichés sous MacOSX dans le cas d'une génération avec chiffrement DES3.

La génération d'une demande de certificat nécessite une paire de clés et en particulier la clé privée. Elle contient également diverses autres informations. Cette demande est placée dans un fichier texte qui sera utilisé au moment de la génération du certificat SSL. Voici la commande à utiliser pour une générer une demande de certificat :

openssl req -new ?key Chemin_de_LaClé(.pem)  -out Chemin_demande_de_certificats(.csr) < Chemin_de_ infoscertificat.txt 

Avec :

• Chemin_de_LaClé(.pem) : le chemin d'accès de la clé Key.pem généré précédemment.
• Chemin_demande_de_certificats(.csr) : le chemin d'accès de la demande de certificat qui va être générée. L'extension du fichier généré est « .csr ».
• Chemin_de_infoscertificat.txt: le chemin d'accès au fichier texte contenant les informations sur le certificat

Voici un exemple de contenu du fichier texte « infoscertificat.txt. » passé en paramètre à cette commande :

----------------------------------------
FR
   Hauts de Seine
   CLICHY
   4D SA
   WebMaster
   www.notestechniques.fr
Emain@4d.fr
.
.
----------------------------------------

Ci-dessous les champs de saisie correspondants tels qu'ils se présentent dans un Shell du terminal de MacOSX ou dans une fenêtre MS-DOS lors d'une génération d'une demande de certificat :

Country Name (2 letter code) [AU]:FR
   State or Province Name (full name) [Some-State]: Hauts de Seine
   Locality Name (eg, city) []:CLICHY
   Organization Name (eg, company) [Internet Widgits]: 4D SA
   Organizational Unit Name (eg, section) []:WebMaster
   Common Name (your name or server's hostname) []:www.notestechniques.fr
   Email Address []:Emain@4d.fr
   Please enter the following 'extra' attributes
   to be sent with your certificate request
A challenge password []:.
An optional company name []:.

Les deux derniers paramètres sont facultatifs et correspondent respectivement à la saisie d'un mot de passe et d'un nom supplémentaire de la société. Si vous ne voulez pas saisir ces champs, il suffit de mettre un point dans chaque zone. Vous pouvez trouver plus d'informations sur ces paramètres dans la documentation 4D relative à la commande GENERER DEMANDE CERTIFICAT.

Un certificat est un document électronique, résultat d'un traitement fixant les relations qui existent entre une clef publique, son propriétaire (une personne, une application, un site) et l'application pour laquelle il est émis.

• Pour une personne, il prouve l'identité de la personne au même titre qu'une carte d'identité. Pour une application, il assure que celle-ci n'a pas été détournée de ses fonctions.
• Pour un site, il offre la garantie lors d'un accès vers celui-ci que l'on est bien sur le site auquel on veut accéder.

On ne gère dans cette note que des certificats qui s'appuient sur un protocole normalisé X509 (ITU-T X.509 international standard V3 - 1996) (RFC2459). Il existe d'autres applications ou systèmes de cryptographie qui ne s'appuient pas sur les certificats X509 (PGP par exemple).

La commande Openssl de génération d'un certificat s'écrit de la façon suivante :

openssl req -in Chemin_demande_de_certificats(.csr) -days Var_Durée ?key
   Chemin_de_LaClé(.pem) -x509 -out Chemin_du_certificat(.pem)

Avec :

• Chemin_de_LaClé(.pem) : le chemin d'accès de la clé Key.pem généré précédemment.
• Chemin_demande_de_certificats(.csr) : le chemin d'accès de la demande de certificat générée précédemment.
• Chemin_du_certificat(.pem): le chemin d'accès du certificat qui va être généré. Le fichier généré a pour extension .pem.
• Var_Durée : la durée de validité du certificat en nombre de jours. Si ce paramètre est omis, la valeur par défaut est de 1 mois.

Par exemple, la commande suivante génère un certificat « Cert.pem » à la racine du disque « C : » valable pour un an :

Openssl req -in C:/DemandeCert.csr -days 365 ?key C:/Key.pem  -x509 -out C:/Cert.pem

Openssl x509 -noout -text -in C:/Cert.pem

La présente note technique est accompagnée des documents suivants▲

Préférences▲

Le tableau de bord comprend une première partie qui propose différents paramétrages. Le première consiste à définir le dossier où seront stockés les fichiers générés : la clé (Key.pem), la demande de certificat (Demandecert.csr) et le certificat final (Cert.pem).

Le deuxième paramètre est le chemin d'accès aux fichiers d'informations nécessaires pour la génération de la demande de certificat

Le troisième paramètre concerne uniquement la plate-forme Windows et correspond à l'emplacement du fichier openssl.exe du package openssl. Ce paramètre n'est pas accessible sous Macintosh, car la librairie openssl est disponible en natif dans le système Mac OSX. Il suffit donc d'appeler directement les commandes openssl sans spécifier aucun emplacement.

La base de démo vous propose également les différents paramètres suivants qui vous permettent de mieux personnaliser vos clés et vos certificats SSL :

Longueur de la clé à générer : plus cette longueur est grande plus les temps de génération de la clé ainsi que celui de traitement des requêtes SSL par le serveur web sont importants.

La durée de validité du certificat : cette durée est évaluée en nombre de jours. Lorsque ce paramètre est égal à zéro, la durée de validité prise par défaut est égale à 1 mois (30 jours).

Le chiffrement DES3 : vous avez la possibilité de générer des clés chiffrées ou non avec l'algorithme de cryptage DES3.

Génération des fichiers▲

La deuxième partie du tableau de bord comprend les différentes actions de génération placées dans l'ordre chronologique d'exécution.

• La première action génère la clé de cryptage en tenant compte des différents paramétrages préalables : la longueur de la clé, le choix du chiffrement, le choix de la durée de validité et l'emplacement dédié pour la génération.

• La deuxième action consiste à générer la demande de certificat à partir de la clé de cryptage généré précédemment et en incluant les informations relatives au certificat.

• La troisième action correspond à la génération finale du certificat « Cert.pem » à partir de la clé et de la demande de certificat générées précédemment.

• La dernière action vous permet d'ouvrir directement et facilement le dossier contenant tous les fichiers qui viennent d'être générés.

Dialogue d’informations▲

Après l'exécution de chaque commande openssl, un dialogue contenant toutes informations importantes sur le déroulement de l'opération sera affiché.

Un exemple de ce dialogue est illustré dans la copie d'écran suivante :

La partie en haut permet de vous indiquer si la commande openssl a été correctement exécutée ou pas par la commande LANCER PROCESS EXTERNE de 4D 2004. Cette information ne garantit pas le bon déroulement de l'opération déclenchée par la commande. En effet, la commande openssl, peut être lancée correctement à partir de 4D et échouer pour d'autres raisons comme l'absence de la clé à l'endroit spécifié ou une mauvaise saisie de la passphrase dans le cas d'une génération cryptée avec l'algorithme DES3. Pour cela, une deuxième partie a été rajoutée dans le dialogue afin de vous transmettre les informations complémentaires retournées par la libraire openssl via le canal de sortie d'erreur STDERR. Par ailleurs, un bouton a été placé entre les deux parties pour vous permettre de copier la commande qui vient d'être exécutée dans la presse-papiers pour un éventuel besoin de vérification.

Dans cette note technique, nous vous avons proposé un outil de génération de certificats SSL autosignés fait en 4D 2004 et basé sur la librairie openssl. Cet outil vous propose différents paramétrages vous permettant de mieux personnaliser vos certificats. Nous avons tirer parti, dans cette note, de l'ouverture de 4D 2004 aux programmes externes grâce à la nouvelle commande LANCER PROCESS EXTERNE. Cette ouverture est extrêmement utile puisqu'elle peut très bien être adoptée pour faire communiquer 4D avec toute autre application ou programme externe.

Téléchargez la base exemple : base exemple