16.7. Connexions tcp/ip sécurisées avec ssl
PostgreSQL™ dispose d'un
support natif pour l'utilisation de connexions ssl, cryptant ainsi les communications
clients/serveurs pour une sécurité améliorée. Ceci requiert
l'installation d'openssl™ à la
fois sur le système client et sur le système serveur et que ce
support soit activé au moment de la construction de PostgreSQL™ (voir le Chapitre 14,
Procédure d'installation).
Avec le support ssl compilé, le
serveur PostgreSQL™ peut être
lancé avec ssl activé en activant
ssl dans PostgreSQL.conf. lors d'un démarrage en mode
ssl, le serveur cherchera les
fichiers server.key et server.crt dans le répertoire des données, qui
doivent contenir respectivement la clé privée du serveur et le
certificat. Ces fichiers doivent être configurés correctement avant
qu'un serveur dont le mode ssl est
activé puisse démarrer. si la clé privée est protégée avec une
phrase, le serveur la demandera et ne se lancera pas tant que
celle-ci n'aura pas été saisie.
Le serveur écoutera les connexions ssl et standard sur le même port TCP et négociera
avec tout client se connectant qu'il utilise ou non ssl. voir le Chapitre 20,
Authentification du client pour savoir comment forcer
l'utilisation de ssl pour
certaines connexions.
Pour les détails sur la création de la clé privé et du certificat du
serveur, référez-vous à la documentation d'openssl™. un simple certificat signé par
soi-même peut être utilisé pour des tests mais un certificat signé
par une autorité (ca) (soit un des
ca globaux soit un local) devrait
être utilisé en production de façon à ce que le client puisse
vérifier l'identité du serveur. Pour créer rapidement un certificat
signé soi-même, utilisez la commande openssl™ suivante :
openssl req -new -text -out server.req
Remplissez les informations que
openssl
réclame. assurez-vous que
vous entrez le nom local de l'hôte sur « common name » ; le mot de passe de challenge peut
être laissé vide. Le programme générera une clé qui est protégée par
une phrase ; elle n'acceptera pas une phrase qui fait moins de quatre
caractères. Pour supprimer la phrase (ce que vous devez faire si vous
voulez automatiser le lancement du serveur), lancez les commandes
openssl rsa -in privkey.pem -out server.key
rm privkey.pem
Saisissez l'ancienne phrase pour débloquer la clé existante.
Maintenant, saisissez
openssl req -x509 -in server.req -text -key server.key -out server.crt
chmod og-rwx server.key
pour remplacer le certificat en un certificat signé par soi-même et
copiez la clé et le certificat là où le serveur les cherchera.
Si la vérification des certificats du client est requise, placez les
certificats du ca que vous
souhaitez vérifier dans le fichier root.crt
du répertoire des données. s'il est présent, un certificat client
sera demandé à partir du client lors du lancement d'une connexion SSL
et il doit y avoir des certificats présent dans root.crt. (Voir Section 29.16, « Support
de SSL » pour une description de la configuration des
certificats du client.) Les entrées du CRL (
Certificate Revocation List
, liste de
révocation des certificats) sont aussi vérifiées si le fichier
root.crl existe.
Quand le fichier root.crt est absent, les
certificats du client ne seront ni demandés ni vérifiés. Dans ce
mode, SSL fournit la sécurité de la communication pas
l'authentification.
Les fichiers server.key, server.crt, root.crt et
root.crl sont seulement examinés lors du
lancement du serveur ; donc vous devez relancer le serveur pour
prendre en compte les modifications.