Difference between revisions of "FR/Documentation/HSQLDB Guide/ch07"

From Apache OpenOffice Wiki
Jump to: navigation, search
m (→‎Encryption de la connexion JDBC)
m (Fr.openoffice.org/FAQ/Base/Guide HSQLDB/ch07 moved to FR/Documentation/HSQLDB Guide/ch07: Placer ce guide à coté des autres.)
 
(19 intermediate revisions by 2 users not shown)
Line 1: Line 1:
−
'''Chapitre 7. TLS'''
+
{{DISPLAYTITLE:Ch. 7. Couche de sécurité du transport (TLS)}}
 +
<div style="float:right; background-color:lightyellow; border: 2px solid black; margin:0 1em 0 0.5em; padding:0 0.3em 0 0.3em; ">
 +
__TOC__
 +
</div>
 +
'''Chapitre 7. Couche de sécurité du transport (TLS)'''
  
 
TLS Support (a.k.a. SSL)
 
TLS Support (a.k.a. SSL)
Line 20: Line 24:
 
* Sun Java 2.x et supérieur. (C'est probablement possible avec un moteur Java de IBM, mais je ne pense pas que quelqu'un ait essayé d'exécuter HSQLDB avec TLS dans un environnement Java de IBM, et je sais que personne du groupe de développement HSQLDB n'a documenté comment définir cet environnement).
 
* Sun Java 2.x et supérieur. (C'est probablement possible avec un moteur Java de IBM, mais je ne pense pas que quelqu'un ait essayé d'exécuter HSQLDB avec TLS dans un environnement Java de IBM, et je sais que personne du groupe de développement HSQLDB n'a documenté comment définir cet environnement).
 
* Avec Java 2.x ou 3.x, vous devrez <u>installer JSSE</u>. Votre serveur et / ou client démarrera plus lentement que celui des utilisateurs de Java 4.x. Les utilisateurs côté client ne seront pas capables d'utiliser le protocole https: JDBC (Parce que la manipulation du protocole https n'est pas implémentée dans Java JSSE versions 2.x/3.x ; S'il y avait des demandes, nous pourrions l'envisager).
 
* Avec Java 2.x ou 3.x, vous devrez <u>installer JSSE</u>. Votre serveur et / ou client démarrera plus lentement que celui des utilisateurs de Java 4.x. Les utilisateurs côté client ne seront pas capables d'utiliser le protocole https: JDBC (Parce que la manipulation du protocole https n'est pas implémentée dans Java JSSE versions 2.x/3.x ; S'il y avait des demandes, nous pourrions l'envisager).
−
* Un gestionnaire de trousseaux JKS (JKS keystore) muni d'une clé privée, de façon à lancer le serveur.
+
* Un <u>trousseau JKS muni d'une clé privée</u> (JKS keystore), de façon à lancer le serveur.
−
* Si vous officiez côté serveur, alors vous devez exécuter un serveur ou serveur web HSQLDB. Cela n'a pas d'importance si vous avez de nouvelles instances de bases de données sous-jacentes, et pas plus si vous réalisez une nouvelle configuration de serveur ou encryptez une configuration de serveur existante. (Vous pouvez basculer l'encryption active/inactive à volonté).
+
* Si vous officiez côté serveur, alors vous devez exécuter un serveur ou serveur web HSQLDB. Cela n'a pas d'importance si vous avez de nouvelles instances de bases de données sous-jacentes, et pas plus si vous réalisez une nouvelle configuration de serveur ou encryptez une configuration de serveur existante. (Vous pouvez basculer l'encryptage actif/inactif à volonté).
 
* Il vous faut un fichier HSQLDB jar qui a été construit avec le JSSE présent. Si vous avez eu votre distribution HSQLDB 1.7.2 chez nous, le problème est réglé car nous l'avons construit avec Java 1.4 (qui contient JSSE). Si vous avez construit votre propre fichier jar avec Java 1.3, assurez vous d'avoir d'abord installé JSSE.
 
* Il vous faut un fichier HSQLDB jar qui a été construit avec le JSSE présent. Si vous avez eu votre distribution HSQLDB 1.7.2 chez nous, le problème est réglé car nous l'avons construit avec Java 1.4 (qui contient JSSE). Si vous avez construit votre propre fichier jar avec Java 1.3, assurez vous d'avoir d'abord installé JSSE.
  
−
== Encryptage de la connexion JDBC ===
+
== Cryptage (chiffrement) de la connexion JDBC ==
 
(Encrypting your JDBC connection)
 
(Encrypting your JDBC connection)
  
−
A ce jour, Seulement un encryptage certifié par le serveur et dans un seul sens, a été testée. (At this time, only 1-way, server-cert encryption is tested.)
+
A ce jour, Seulement un cryptage certifié par le serveur et dans un seul sens, a été testé. (At this time, only 1-way, server-cert encryption is tested.)
  
 
=== Côté client ===
 
=== Côté client ===
Line 41: Line 45:
 
A ce moment, ce dernier ne fonctionnera que pour les clients utilisant Java 1.4.
 
A ce moment, ce dernier ne fonctionnera que pour les clients utilisant Java 1.4.
  
−
Si le serveur auquel vous voulez vous connecter utilise un certificat approuvé par votre fournisseur de clés par défaut (your default trust keystores), alors il n'y a rien d'autre à faire. Sinon vous devez demander à Java de "croire" la certification du serveur. (C'est un peu trop simpliste de dire que si le certificat du serveur a été acheté, alors tout est réglé ; si quelqu'un "signe son propre" certificat en le signant lui-même ou en utilisant un certificat privé ca, (using a private ca certificate), alors vous aurez besoin de régler ce paramètre sur trust/croire).
+
Si le serveur auquel vous voulez vous connecter utilise un certificat approuvé par votre magasin de clés certifié  par défaut(trousseau / fournisseur de clés par défaut) (your default trust keystores), alors il n'y a rien d'autre à faire. Sinon vous devez demander à Java de "faire confiance" à la certification du serveur. (C'est un peu trop simpliste de dire que si le certificat du serveur a été acheté, alors tout est réglé ; si quelqu'un "signe son propre" certificat en le signant lui-même ou en utilisant un certificat privé d'autorité de certification (CA), (using a private ca certificate), alors vous aurez besoin de régler ce paramètre sur trust/confiance).
  
 +
Vous devez d'abord avoir le certificat (seulement sa partie "publique"). Puisque ce certificat est transmis à tous les clients, vous pouvez l'obtenir en écrivant un client Java qui l'écrira dans le fichier (you could obtain it by writing a java client that dumps it to file), ou alors en utilisant la commande openssl s_client. Puisque dans la plupart des cas, si vous voulez faire confiance à un certificat non commercial, vous avez probablement accès au serveur de clé, je vous montrerai un exemple sur la façon d'obtenir ce dont vous avez besoin depuis le serveur JKS.
  
 +
Vous devez déjà avoir [http://www.esup-portail.org/consortium/espace/SSO_1B/tech/java/java_x509.html une certification X509] pour votre serveur. Si vous avez un serveur de clé, vous pouvez alors générer une certification X509 comme ceci :
  
−
First, you need to obtain the cert (only the "public" part of it). Since this cert is passed to all clients, you could obtain it by writing a java client that dumps it to file, or perhaps by using openssl s_client. Since in most cases, if you want to trust a non-commercial cert, you probably have access to the server keystore, I'll show an example of how to get what you need from the server-side JKS keystore.
+
'''Exemple 7.1. Export d'un certificat depuis le magasin du serveur'''
 +
keytool -export -keystore server.store -alias existing_alias -file server.cer
 +
Dans cet exemple, server.cer est le certificat X509 dont vous avez besoin pour la prochaine étape.
  
−
You may already have an X509 cert for your server. If you have a server keystore, then you can generate a X509 cert like this.
+
Maintenant, vous devez ajouter ce certificat à un site de confiance (to one of the system trust keystores) ou à un de vos propres fournisseurs de clés. Reportez vous à (section Personnaliser les fournisseurs) [http://java.sun.com/j2se/1.4.2/docs/guide/security/jsse/JSSERefGuide.html#CustomizingStores the Customizing Stores section in JSSERefGuide.html] pour déterminer où sont vos magasins de clés de confiance. (where your system trust keystores are.) Vous pouvez mettre des clés privées où vous voulez. La commande suivante ajoutera le certificat à un magasin existant, ou en créera un nouveau si <tt>client.store</tt> n'existe pas.
  
−
Example 7.1. Exporting certificate from the server's keystore
+
'''Exemple 7.2. Ajouter un certificat au magasin client'''
 +
Example 7.2. Adding a certificate to the client keystore
  
−
    keytool -export -keystore server.store -alias existing_alias -file server.cer
+
keytool -import -trustcacerts -keystore trust.store -alias new_alias -file server.cer
  
−
In this example, server.cer is the X509 certificate that you need for the next step.
+
Si vous faites un nouveau magasin, vous aimerez probablement partir d'une copie du magasin par défaut du système, que vous pouvez trouver quelque part à partir de la racine de votre dossier Java (typiquement jre/lib/security/cacerts pour JDK, mais j'ai oublié où il est exactement pour JRE).
  
−
Now, you need to add this cert to one of the system trust keystores or to a keystore of your own. See the Customizing Stores section in JSSERefGuide.html to see where your system trust keystores are. You can put private keystores anywhere you want to. The following command will add the cert to an existing keystore, or create a new keystore if client.store doesn't exist.
+
A moins que votre système d'exploitation puisse empêcher d'autres personnes d'écrire dans vos fichiers, vous ne voulez probablement pas définir un mot de passe dans le magasin de confiance. (on the trust keystore)
−
 
+
−
Example 7.2. Adding a certificate to the client keystore
+
  
−
keytool -import -trustcacerts -keystore trust.store -alias new_alias -file server.cer
+
Si vous avez ajouté le certificat à un magasin de confiance du système (If you added the cert to a system trust store), alors vous en avez fini. Autrement vous devrez spécifier votre magasin de confiance personnel (your custom trust keystore) à votre programme client. La manière générique de définir le magasin de confiance est de définir la propriété système javax.net.ssl.trustStore à chaque fois que vous exécutez votre programme client. Par exemple :
  
−
If you are making a new keystore, you probably want to start with a copy of your system default keystore which you can find somewhere under your JAVA_HOME directory (typically jre/lib/security/cacerts for a JDK, but I forget exactly where it is for a JRE).
+
'''Exemple 7.3. Spécifier votre propre magasin de confiance à un client JDBC'''
  
−
Unless your OS can't stop other people from writing to your files, you probably do not want to set a password on the trust keystore.
+
(Example 7.3. Specifying your own trust store to a JDBC client)
 +
java -Djavax.net.ssl.trustStore=/home/blaine/trust.store -jar /path/to/hsqldb.jar dest-urlid
 +
Cet exemple exécute le programme SqlTool. SqlTool a une prise en charge intégrée TLS, toutefois pour SqlTool vous pouvez définir les magasins de confiance sur la base de l'urlid, dans le fichier de configuration(de SqlTool).
  
−
If you added the cert to a system trust store, then you are finished. Otherwise you will need to specify your custom trust keystore to your client program. The generic way to set the trust keystore is to set the sytem property javax.net.ssl.trustStore every time that you run your client program. For example
+
N.B. Le nom de l'hôte dans l'URL de votre base de données doit correspondre rigoureusement avec le nom commun du certificat du serveur. C'est à dire que si un certificat d'un site est admc.com, vous ne pouvez pas utiliser <tt>jdbc:hsqldb:hsqls://localhost</tt> ou <tt>jdbc:hsqldb:hsqls://www.admc.com:1100</tt> pour vous y connecter.
  
−
Example 7.3. Specifying your own trust store to a JDBC client
+
Si vous voulez plus de détails, voyez [http://java.sun.com/j2se/1.4.2/docs/guide/security/jsse/JSSERefGuide.html JSSERefGuide.html sur le site de Sun], ou dans le sous-dossier docs/guide/security/jsse de votre documentation Java SE.
  
−
    java -Djavax.net.ssl.trustStore=/home/blaine/trust.store -jar /path/to/hsqldb.jar dest-urlid
+
=== Coté serveur ===
 +
(Server-Side)
  
−
This example runs the program SqlTool. SqlTool has built-in TLS support, however, so, for SqlTool you can set truststore on a per-urlid basis in the SqlTool configuration file.
+
Procurez vous un magasin JKS contenant une clé privée. Ensuite définissez la propriété système <tt>javax.net.ssl.keyStore</tt> au chemin de ce fichier, et <tt>javax.net.ssl.keyStorePassword</tt> au mot de passe du magasin (et à la clé privée-- Ils doivent être identiques).
  
−
N.b. The hostname in your database URL must match the Common Name of the server's certificate exactly. That means that if a site certificate is admc.com, you can not use jdbc:hsqldb:hsqls://localhost or jdbc:hsqldb:hsqls://www.admc.com:1100 to connect to it.
+
'''Exemple 7.4. Exécuter un serveur Hsqldb avec un cryptage TLS'''
 +
java -Djavax.net.ssl.keyStorePassword=secret  \
 +
    -Djavax.net.ssl.keyStore=/usr/hsqldb/db/db3/server.store  \
 +
    -cp /path/to/hsqldb.jar org.hsqldb.Server
 +
(Ceci est une commande simple séparée en 2 lignes en utilisant le caractère de continuation "\" (backslash). Dans cet exemple, j'utilise un fichier <tt>server.properties</tt> et donc je n'ai pas besoin de donner d'arguments pour spécifier les instances de la base de données ou l'adresse de fin du serveur). (the server endpoint)
  
−
If you want more details on anything, see JSSERefGuide.html on Sun's site, or in the subdirectory docs/guide/security/jsse of your Java SE docs.
+
{{Documentation/FR/Attention|'''Attention'''
−
Server-Side
+
  
−
Get yourself a JKS keystore containing a private key. Then set the system property javax.net.ssl.keyStore to the path to that file, and javax.net.ssl.keyStorePassword to the password of the keystore (and to the private key-- they have to be the same).
+
Entrer un mot de passe par la ligne de commande n'est pas sécurisé. Il est vraiment approprié que lorsque des utilisateurs non fiables n'ont pas accès à votre ordinateur
  
−
Example 7.4. Running an Hsqldb server with TLS encryption
+
S'il y avait des demandes d'utilisateurs, nous aurions une façon plus sécurisée de fournir le mot de passe avant peu.
  
−
    java -Djavax.net.ssl.keyStorePassword=secret  \
+
== JSSE ==
−
        -Djavax.net.ssl.keyStore=/usr/hsqldb/db/db3/server.store  \
+
Si vous utilisez Java 4.x, vous êtes déjà prêt. Utilisateurs de Java 1.x, vous êtes livrés à vous-mêmes (Le JSSE de Sun ne fonctionne pas avec la 1.x). Utilisateurs de Java 2.x et 3.x à suivre...
−
        -cp /path/to/hsqldb.jar org.hsqldb.Server
+
  
−
(This is a single command that I have broken into 2 lines using my shell's \ line-continuation feature. In this example, I'm using a server.properties file so that I don't need to give arguments to specify database instances or the server endpoint).
+
Allez voir http://java.sun.com/products/jsse/index-103.html. Si vous êtes d'accord avec les termes et remplissez les conditions, téléchargez la version familiale (domestic) ou globale du logiciel JSSE. Tout ce dont vous avez besoin dans la distribution du logiciel sont les trois fichiers jar. Si vous avez installé JDK, déplacez les trois fichiers jar dans le répertoire <tt>$JAVA_HOME/jre/lib/ext</tt>. Si vous avez une installation JRE, alors déplacez les trois fichiers jar dans le dossier <tt>$JAVA_HOME/lib/ext</tt>.
−
Caution
+
  
−
Specifying a password on the command-line is definitely not secure. It's really only appropriate when untrusted users do not have any access to your computer.
+
Joliment sans efforts.
  
−
If there is any user demand, we will have a more secure way to supply the password before long.
+
== Création d'un magasin de clés privées ==
−
JSSE
+
(Making a Private-key Keystore)
  
−
If you are running Java 4.x, then you are all set. Java 1.x users, you are on your own (Sun does not provide a JSSE that will work with 1.x). Java 2.x and 3.x users continue...
+
Il y a principalement deux manières de faire. Soit vous utilisez un certificat signé par une autorité de certification, ou vous fabriquez le votre. Une chose que vous avez besoin de connaître dans les deux cas est que le nom commun du certificat doit être exactement le nom de l'hôte que les clients JDBC utiliseront dans l'URL de leur base de données.
  
−
Go to http://java.sun.com/products/jsse/index-103.html. If you agree to the terms and meet the requirements, download the domestic or global JSSE software. All you need from the software distro is the three jar files. If you have a JDK installation, then move the 3 jar files into the directory $JAVA_HOME/jre/lib/ext. If you have a JRE installation, then move the 3 jar files into the directory $JAVA_HOME/lib/ext.
+
=== Certificat signé CA ===
 +
(CA-Signed Cert)
 +
Voir : [http://fr.wikipedia.org/wiki/Certificate_Authority Autorité de certification]
  
−
Pretty painless.
+
Je ne vais pas vous raconter comment obtenir un certificat signé CA par SSL. C'est déjà bien documenté en beaucoup d'autres endroits.
−
Making a Private-key Keystore
+
  
−
There are two main ways to do this. Either you can use a certificate signed by a certificate authority, or you can make your own. One thing that you need to know in both cases is, the Common Name of the cert has to be the exact hostname that JDBC clients will use in their database URL.
+
<font color="red">Assuming that you have a standard '''pem-style''' private key certificate, here's how you can use openssl and the program DERImport to get it into a JKS keystore.</font>
−
CA-Signed Cert
+
  
−
I'm not going to tell you how to get a CA-signed SSL certificate. That is well documented at many other places.
+
Parce que j'ai déjà passé beaucoup de temps sur ce document, je vous donne juste un exemple.
  
−
Assuming that you have a standard pem-style private key certificate, here's how you can use openssl and the program DERImport to get it into a JKS keystore.
+
'''Exemple 7.5. Ajouter une clé privée <font color="red">pem-style</font> dans un magasin JKS.'''
  
−
Because I have spent a lot of time on this document already, I am just giving you an example.
+
(Example 7.5. Getting a pem-style private key into a JKS keystore)
  
−
Example 7.5. Getting a pem-style private key into a JKS keystore
+
openssl pkcs8 -topk8 -outform DER -in Xpvk.pem -inform PEM -out Xpvk.pk8 -nocrypt
 +
 +
openssl x509 -in Xcert.pem -out Xcert.der -outform DER
 +
 +
java DERImport new.keystore NEWALIAS Xpvk.pk8 Xcert.der
  
−
openssl pkcs8 -topk8 -outform DER -in Xpvk.pem -inform PEM -out Xpvk.pk8 -nocrypt
+
{{Important|Important :
  
−
openssl x509 -in Xcert.pem -out Xcert.der -outform DER
+
Assurez vous de définir le mot de passe de la clé exactement comme celui du magasin !}}
  
−
java DERImport new.keystore NEWALIAS Xpvk.pk8 Xcert.der
+
Vous avez évidemment besoin du programme <tt>DERImport.class</tt>. Faites des recherches internet pour trouver <tt>DERImport.java</tt> ou <tt>DERImport.class</tt> et téléchargez le.
  
−
Important
+
S'il devient difficile de se procurer DERImport, je pourrais écrire un programme qui fait la même chose-- Faites le seulement moi savoir.
  
−
Make sure to set the password of the key exactly the same as the password for the keystore!
+
=== Certification non-signée CA ===
 +
(Non-CA-Signed Cert)
  
−
You need the program DERImport.class of course. Do some internet searches to find DERImport.java or DERImport.class and download it.
+
Exécutez <tt>man keytool</tt> ou voyez [http://java.sun.com/j2se/1.4.2/docs/guide/security/jsse/JSSERefGuide.html#CreateKeystore the Creating a Keystore section of JSSERefGuide.html].
  
−
If DERImport has become difficult to obtain, I can write a program to do the same thing-- just let me know.
+
== Démarrage automatique de Server ou WebServer sous UNIX ==
−
Non-CA-Signed Cert
+
(Automatic Server or WebServer startup on UNIX)
  
−
Run man keytool or see the Creating a Keystore section of JSSERefGuide.html.
+
Si vous êtes sous UNIX et voulez démarrer et stopper automatiquement un serveur ou serveur web s'exécutant avec encryptage, suivez les instructions du chapitre [[Fr.openoffice.org/FAQ/Base/Guide_HSQLDB/ch03|Démarrage rapide sous UNIX]], rappelez-vous de rendre le fichier de configuration du script init lisible seulement par l'administrateur, et renseignez les variables <tt>TLS_PASSWORD</tt> et <tt>TLS_KEYSTORE</tt>.
−
Automatic Server or WebServer startup on UNIX
+
  
−
If you are on UNIX and want to automatically start and stop a Server or WebServer running with encryption, follow the instructions in the UNIX Quick Start chapter, and remember to make the init script configuration file readable only to root and to set the variables TLS_PASSWORD and TLS_KEYSTORE.
+
Si vous utilisez un certificat privé de serveur, assurez vous également de définir le chemin du magasin de confiance (trust store filepath) comme exposé dans le fichier de configuration exemple du script init.
  
−
If you are using a private server certificate, make sure to also set the trust store filepath as shown in the sample init script configuration file.
+
Le [[#Cot.C3.A9_serveur|message "Attention" ci-dessus]] s'applique encore ici. Le mot de passe sera visible par quiconque ayant un minimum de compétences sous UNIX et désirant le déchiffrer.
  
−
The cautionary warning above still applies. The password will be visible to any minimally competent local UNIX user who wants to see it.
+
[[Category: FR/HSQLDB_Guide]]

Latest revision as of 18:47, 9 May 2009

Chapitre 7. Couche de sécurité du transport (TLS)

TLS Support (a.k.a. SSL)

Blaine Simpson

HSQLDB Development Group

<blaine.simpson@admc.com>

$Date: 2006/07/27 21:08:21 $

Les instructions consignées dans ce document sont susceptibles de changement à tout moment. En particulier, nous prévoyons de changer la méthode pour fournir un certificat de mot de passe côté serveur.

Spécifications

(Requirements)

Spécifications de prise en charge de TLS pour HSQLDB (Hsqldb TLS Support Requirements)

  • Sun Java 2.x et supérieur. (C'est probablement possible avec un moteur Java de IBM, mais je ne pense pas que quelqu'un ait essayé d'exécuter HSQLDB avec TLS dans un environnement Java de IBM, et je sais que personne du groupe de développement HSQLDB n'a documenté comment définir cet environnement).
  • Avec Java 2.x ou 3.x, vous devrez installer JSSE. Votre serveur et / ou client démarrera plus lentement que celui des utilisateurs de Java 4.x. Les utilisateurs côté client ne seront pas capables d'utiliser le protocole https: JDBC (Parce que la manipulation du protocole https n'est pas implémentée dans Java JSSE versions 2.x/3.x ; S'il y avait des demandes, nous pourrions l'envisager).
  • Un trousseau JKS muni d'une clé privée (JKS keystore), de façon à lancer le serveur.
  • Si vous officiez côté serveur, alors vous devez exécuter un serveur ou serveur web HSQLDB. Cela n'a pas d'importance si vous avez de nouvelles instances de bases de données sous-jacentes, et pas plus si vous réalisez une nouvelle configuration de serveur ou encryptez une configuration de serveur existante. (Vous pouvez basculer l'encryptage actif/inactif à volonté).
  • Il vous faut un fichier HSQLDB jar qui a été construit avec le JSSE présent. Si vous avez eu votre distribution HSQLDB 1.7.2 chez nous, le problème est réglé car nous l'avons construit avec Java 1.4 (qui contient JSSE). Si vous avez construit votre propre fichier jar avec Java 1.3, assurez vous d'avoir d'abord installé JSSE.

Cryptage (chiffrement) de la connexion JDBC

(Encrypting your JDBC connection)

A ce jour, Seulement un cryptage certifié par le serveur et dans un seul sens, a été testé. (At this time, only 1-way, server-cert encryption is tested.)

Côté client

(Client-Side)

Utilisez simplement l'un des préfixes de protocole suivants :

Préfixes des URLs Hsqldb TLS

  • jdbc:hsqldb:hsqls://
  • jdbc:hsqldb:https://

A ce moment, ce dernier ne fonctionnera que pour les clients utilisant Java 1.4.

Si le serveur auquel vous voulez vous connecter utilise un certificat approuvé par votre magasin de clés certifié par défaut(trousseau / fournisseur de clés par défaut) (your default trust keystores), alors il n'y a rien d'autre à faire. Sinon vous devez demander à Java de "faire confiance" à la certification du serveur. (C'est un peu trop simpliste de dire que si le certificat du serveur a été acheté, alors tout est réglé ; si quelqu'un "signe son propre" certificat en le signant lui-même ou en utilisant un certificat privé d'autorité de certification (CA), (using a private ca certificate), alors vous aurez besoin de régler ce paramètre sur trust/confiance).

Vous devez d'abord avoir le certificat (seulement sa partie "publique"). Puisque ce certificat est transmis à tous les clients, vous pouvez l'obtenir en écrivant un client Java qui l'écrira dans le fichier (you could obtain it by writing a java client that dumps it to file), ou alors en utilisant la commande openssl s_client. Puisque dans la plupart des cas, si vous voulez faire confiance à un certificat non commercial, vous avez probablement accès au serveur de clé, je vous montrerai un exemple sur la façon d'obtenir ce dont vous avez besoin depuis le serveur JKS.

Vous devez déjà avoir une certification X509 pour votre serveur. Si vous avez un serveur de clé, vous pouvez alors générer une certification X509 comme ceci :

Exemple 7.1. Export d'un certificat depuis le magasin du serveur 

keytool -export -keystore server.store -alias existing_alias -file server.cer

Dans cet exemple, server.cer est le certificat X509 dont vous avez besoin pour la prochaine étape.

Maintenant, vous devez ajouter ce certificat à un site de confiance (to one of the system trust keystores) ou à un de vos propres fournisseurs de clés. Reportez vous à (section Personnaliser les fournisseurs) the Customizing Stores section in JSSERefGuide.html pour déterminer où sont vos magasins de clés de confiance. (where your system trust keystores are.) Vous pouvez mettre des clés privées où vous voulez. La commande suivante ajoutera le certificat à un magasin existant, ou en créera un nouveau si client.store n'existe pas.

Exemple 7.2. Ajouter un certificat au magasin client Example 7.2. Adding a certificate to the client keystore 

keytool -import -trustcacerts -keystore trust.store -alias new_alias -file server.cer

Si vous faites un nouveau magasin, vous aimerez probablement partir d'une copie du magasin par défaut du système, que vous pouvez trouver quelque part à partir de la racine de votre dossier Java (typiquement jre/lib/security/cacerts pour JDK, mais j'ai oublié où il est exactement pour JRE).

A moins que votre système d'exploitation puisse empêcher d'autres personnes d'écrire dans vos fichiers, vous ne voulez probablement pas définir un mot de passe dans le magasin de confiance. (on the trust keystore)

Si vous avez ajouté le certificat à un magasin de confiance du système (If you added the cert to a system trust store), alors vous en avez fini. Autrement vous devrez spécifier votre magasin de confiance personnel (your custom trust keystore) à votre programme client. La manière générique de définir le magasin de confiance est de définir la propriété système javax.net.ssl.trustStore à chaque fois que vous exécutez votre programme client. Par exemple :

Exemple 7.3. Spécifier votre propre magasin de confiance à un client JDBC

(Example 7.3. Specifying your own trust store to a JDBC client) 

java -Djavax.net.ssl.trustStore=/home/blaine/trust.store -jar /path/to/hsqldb.jar dest-urlid

Cet exemple exécute le programme SqlTool. SqlTool a une prise en charge intégrée TLS, toutefois pour SqlTool vous pouvez définir les magasins de confiance sur la base de l'urlid, dans le fichier de configuration(de SqlTool).

N.B. Le nom de l'hôte dans l'URL de votre base de données doit correspondre rigoureusement avec le nom commun du certificat du serveur. C'est à dire que si un certificat d'un site est admc.com, vous ne pouvez pas utiliser jdbc:hsqldb:hsqls://localhost ou jdbc:hsqldb:hsqls://www.admc.com:1100 pour vous y connecter.

Si vous voulez plus de détails, voyez JSSERefGuide.html sur le site de Sun, ou dans le sous-dossier docs/guide/security/jsse de votre documentation Java SE.

Coté serveur

(Server-Side)

Procurez vous un magasin JKS contenant une clé privée. Ensuite définissez la propriété système javax.net.ssl.keyStore au chemin de ce fichier, et javax.net.ssl.keyStorePassword au mot de passe du magasin (et à la clé privée-- Ils doivent être identiques).

Exemple 7.4. Exécuter un serveur Hsqldb avec un cryptage TLS 

java -Djavax.net.ssl.keyStorePassword=secret  \
    -Djavax.net.ssl.keyStore=/usr/hsqldb/db/db3/server.store  \
    -cp /path/to/hsqldb.jar org.hsqldb.Server

(Ceci est une commande simple séparée en 2 lignes en utilisant le caractère de continuation "\" (backslash). Dans cet exemple, j'utilise un fichier server.properties et donc je n'ai pas besoin de donner d'arguments pour spécifier les instances de la base de données ou l'adresse de fin du serveur). (the server endpoint)

{{Documentation/FR/Attention|Attention

Entrer un mot de passe par la ligne de commande n'est pas sécurisé. Il est vraiment approprié que lorsque des utilisateurs non fiables n'ont pas accès à votre ordinateur

S'il y avait des demandes d'utilisateurs, nous aurions une façon plus sécurisée de fournir le mot de passe avant peu.

JSSE

Si vous utilisez Java 4.x, vous êtes déjà prêt. Utilisateurs de Java 1.x, vous êtes livrés à vous-mêmes (Le JSSE de Sun ne fonctionne pas avec la 1.x). Utilisateurs de Java 2.x et 3.x à suivre...

Allez voir http://java.sun.com/products/jsse/index-103.html. Si vous êtes d'accord avec les termes et remplissez les conditions, téléchargez la version familiale (domestic) ou globale du logiciel JSSE. Tout ce dont vous avez besoin dans la distribution du logiciel sont les trois fichiers jar. Si vous avez installé JDK, déplacez les trois fichiers jar dans le répertoire $JAVA_HOME/jre/lib/ext. Si vous avez une installation JRE, alors déplacez les trois fichiers jar dans le dossier $JAVA_HOME/lib/ext.

Joliment sans efforts.

Création d'un magasin de clés privées

(Making a Private-key Keystore)

Il y a principalement deux manières de faire. Soit vous utilisez un certificat signé par une autorité de certification, ou vous fabriquez le votre. Une chose que vous avez besoin de connaître dans les deux cas est que le nom commun du certificat doit être exactement le nom de l'hôte que les clients JDBC utiliseront dans l'URL de leur base de données.

Certificat signé CA

(CA-Signed Cert) Voir : Autorité de certification

Je ne vais pas vous raconter comment obtenir un certificat signé CA par SSL. C'est déjà bien documenté en beaucoup d'autres endroits.

Assuming that you have a standard pem-style private key certificate, here's how you can use openssl and the program DERImport to get it into a JKS keystore.

Parce que j'ai déjà passé beaucoup de temps sur ce document, je vous donne juste un exemple.

Exemple 7.5. Ajouter une clé privée pem-style dans un magasin JKS.

(Example 7.5. Getting a pem-style private key into a JKS keystore) 

openssl pkcs8 -topk8 -outform DER -in Xpvk.pem -inform PEM -out Xpvk.pk8 -nocrypt

openssl x509 -in Xcert.pem -out Xcert.der -outform DER

java DERImport new.keystore NEWALIAS Xpvk.pk8 Xcert.der
Important.png Important :

Assurez vous de définir le mot de passe de la clé exactement comme celui du magasin !

Vous avez évidemment besoin du programme DERImport.class. Faites des recherches internet pour trouver DERImport.java ou DERImport.class et téléchargez le.

S'il devient difficile de se procurer DERImport, je pourrais écrire un programme qui fait la même chose-- Faites le seulement moi savoir.

Certification non-signée CA

(Non-CA-Signed Cert)

Exécutez man keytool ou voyez the Creating a Keystore section of JSSERefGuide.html.

Démarrage automatique de Server ou WebServer sous UNIX

(Automatic Server or WebServer startup on UNIX)

Si vous êtes sous UNIX et voulez démarrer et stopper automatiquement un serveur ou serveur web s'exécutant avec encryptage, suivez les instructions du chapitre Démarrage rapide sous UNIX, rappelez-vous de rendre le fichier de configuration du script init lisible seulement par l'administrateur, et renseignez les variables TLS_PASSWORD et TLS_KEYSTORE.

Si vous utilisez un certificat privé de serveur, assurez vous également de définir le chemin du magasin de confiance (trust store filepath) comme exposé dans le fichier de configuration exemple du script init.

Le message "Attention" ci-dessus s'applique encore ici. Le mot de passe sera visible par quiconque ayant un minimum de compétences sous UNIX et désirant le déchiffrer.

Retrieved from "https://wiki.openoffice.org/w/index.php?title=FR/Documentation/HSQLDB_Guide/ch07&oldid=124533"
Personal tools