Documentation PostgreSQL 8.2.23 > Administration du serveur > Environnement du système d'exploitation > Connexions tcp/ip sécurisées avec ssl | |
Options de chiffrement | Connexions tcp/ip sécurisées avec des tunnels ssh tunnels |
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.