FR/Documentation/HSQLDB Guide/ch07

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.

Encryptage de la connexion JDBC

(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.)

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 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 "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).

Vous devez d'abord avoir le certificat (seulement sa partie "publique"). Puisque ce certificat est transmit à tous les clients, vous pouvez l'obtenir en écrivant un client Java qui le duplique sur 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 croire une certification non commerciale, vous avez probablement accès au serveur du trousseau, je vous montrerai un exemple sur la façon d'obtenir ce dont vous avez besoin depuis le trousseau JKS, côté serveur.

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

Exemple 7.1. Export d'un certificat depuis le trousseau 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 ou sont vos "trousseaux de confiance" du système. (where your system trust keystores are.) Vous pouvez mettre des clés privées ou vous voulez. La commande suivante ajoutera le certificat à un trousseau existant, ou en créera un nouveau si client.store n'existe pas.

Exemple 7.2. Ajouter un certificat au trousseau du 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 trousseau, vous aimerez probablement partir d'une copie du trousseau 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, et j'ai oublié exactement ou 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 trousseau 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 trousseau de confiance personnel (your custom trust keystore) à votre programme client. La manière générique de définir le trousseau 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)

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).

Example 7.4. Running an Hsqldb server with TLS encryption

   java -Djavax.net.ssl.keyStorePassword=secret  \
       -Djavax.net.ssl.keyStore=/usr/hsqldb/db/db3/server.store  \
       -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). 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.

If there is any user demand, we will have a more secure way to supply the password before long. JSSE

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...

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.

Pretty painless. 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. 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.

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.

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

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

Make sure to set the password of the key exactly the same as the password for the keystore!

You need the program DERImport.class of course. Do some internet searches to find DERImport.java or DERImport.class and download it.

If DERImport has become difficult to obtain, I can write a program to do the same thing-- just let me know. Non-CA-Signed Cert

Run man keytool or see the Creating a Keystore section of JSSERefGuide.html. 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.

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.

The cautionary warning above still applies. The password will be visible to any minimally competent local UNIX user who wants to see it.