FR/Documentation/HSQLDB Guide/ch07

From Apache OpenOffice Wiki
Jump to: navigation, search

Chapitre 7. 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 gestionnaire de trousseaux JKS (JKS keystore) muni d'une clé privée, 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é).
  • 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 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 fournisseur de clés, je vous montrerai un exemple sur la façon d'obtenir ce dont vous avez besoin depuis le fournisseur de clés JKS, côté serveur.

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

Exemple 7.1. Export d'un certificat depuis le fournisseur de clés 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 keystore existant, ou en créera un nouveau si client.store n'existe pas.

Exemple 7.2. Example 7.2. Adding a certificate to the client keystore

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

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

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.

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

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

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.

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.

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

Personal tools