Par défaut, PostgreSQL ne vérifie pas le certificat du serveur. Cela signifie qu'il est possible de se faire passer pour le serveur final (par exemple en modifiant un enregistrement DNS ou en prenant l'adresse IP du serveur) sans que le client ne le sache. Pour empêcher ceci, le client doit être capable de vérifier l'identité du serveur via une chaîne de confiance. Une chaîne de confiance est établie en plaçant le certificat racine auto-signé d'une autorité de certificats (CA) sur un ordinateur et un certificat feuille signé par le certificat racine sur un autre ordinateur. Il est aussi possible d'utiliser un certificat « intermédiaire » signé par le certificat racine et qui signe des certificats feuilles.

Pour permettre au client de vérifier l'identité du serveur, placez un certificat racine sur le client et un certificat feuille signé par le certificat racine sur le serveur. Pour permettre au serveur de vérifier l'identité du client, placez un certificat racine sur le serveur et un certificat feuille signé par le certificat racine sur le client. Un ou plusieurs certificats intermédiaires (habituellement stockés avec le certificat feuille) peuvent aussi être utilisés pour lier le certificat feuille au certificat racine.

Une fois qu'une chaîne de confiance a été établie, il existe deux façons pour le client de valider le certificat feuille envoyé par le serveur. Si le paramètre sslmode est configuré à verify- ca, libpq vérifiera que le serveur est de confiance en vérifiant la chaîne de certificats jusqu'au certificat racine stocké sur le client. Si sslmode est configuré à verify- full, libpq va aussi vérifier que le nom d'hôte du serveur correspond au nom stocké dans le certificat du serveur. La connexion SSL échouera si le certificat du serveur n'établit pas ces correspondances. La connexion SSL échouera si le certificat du serveur ne peut pas être vérifié. verify-full est recommandé pour les environnements les plus sensibles à la sécurité.

En mode verify-full, le nom de l'hôte est mis en correspondance avec le ou les attributs "Subject Alternative Name" du certificat, ou avec l'attribut "Common Name" si aucun "Subject Alternative Name" de type dNSName est présent. Si le nom du certificat débute avec le caractère étoile (*), le caractère étoile sera traité comme un métacaractère qui correspondra à tous les caractères à l'exception du point. Cela signifie que le certificat ne pourra pas être utilisé pour des sous-domaines complets. Si la connexion se fait en utilisant une adresse IP au lieu d'un nom d'hôte, l'adresse IP sera vérifiée (sans faire de recherche DNS).

Pour permettre la vérification du certificat du serveur, un ou plusieurs certificats racines doivent être placés dans le fichier ~/.postgresql/root.crt du répertoire personnel de l'utilisateur (sur Windows, le fichier est nommé %APPDATA%\postgresql\root.crt). Les certificats intermédiaires doivent aussi être ajoutés au fichier s'ils sont nécessaires pour lier la chaîne de certificat envoyée par le serveur aux certificats racines stockés sur le client.

Les entrées de la liste de révocation des certificats (CRL) sont aussi vérifiées si le fichier ~/.postgresql/root.crl existe (%APPDATA%\postgresql\root.crl sur Microsoft Windows).

L'emplacement du certificat racine et du CRL peuvent être changés avec les paramètres de connexion sslrootcert et sslcrl, ou les variables d'environnement PGSSLROOTCERT et PGSSLCRL.

Si le serveur tente de vérifier l'identité du client en réclamant le certificat feuille du client, libpq enverra le certificat stocké dans le fichier ~/.postgresql/postgresql.crt du répertoire personnel de l'utilisateur. Les certificats doivent chaîner vers le certificat racine de confiance du serveur. Un fichier de clé privé correspondant ~/.postgresql/postgresql.key doit aussi être présent. Sur Microsoft Windows, ces fichiers sont nommés %APPDATA%\postgresql\postgresql.crt et %APPDATA%\postgresql\postgresql.key. L'emplacement des fichiers certificat et clé peut être surchargé par les paramètres de connexion sslcert et sslkey, ou par les variables d'environnement PGSSLCERT et PGSSLKEY.

Sur les systèmes Unix, les droits sur le fichier de clé privée ne doit pas permettre l'accès au monde et au groupe ; vous pouvez vous en assurer avec une commande telle que chmod 0600 ~/.postgresql/postgresql.key. Il est aussi possible de rendre root propriétaire deu fichier et d'avoir le droit d'accès pour le groupe (autrement dit, les droits 0640). Cette configuration est prévue pour les installations où les fichiers certificat et clé sont gérés par le système d'exploitation. L'utilisateur de libpq devra alors devenir membre du group qui a accès à ces fichiers certificat et clé. (Sur Microsoft Windows, aucune vérification n'est effectuée sur les droits des fichiers car le répertoire %APPDATA%\postgresql est supposé sécurisé.)

Le premier certificat dans postgresql.crt doit être le certificat du client parce qu'il doit correspondre à la clé privée du client. Les certificats « intermédiaires » peuvent être ajoutés au fichier en option -- le faire permet d'éviter d'avoir à stocker les certificats intermédiaires sur le fichier root.crt du serveur.

Pour des instructions sur la création de certificats, voir Section 18.9.3.

Les différentes valeurs du paramètre sslmode fournissent différents niveaux de protection. SSL peut fournir une protection contre trois types d'attaques différentes :

Pour qu'une connexion soit sûre, l'utilisation de SSL doit être configurée sur le client et sur le serveur avant que la connexion ne soit effective. Si c'est seulement configuré sur le serveur, le client pourrait envoyer des informations sensibles (comme les mots de passe) avant qu'il ne sache que le serveur réclame une sécurité importante. Dans libpq, les connexions sécurisées peuvent être garanties en configurant le paramètre sslmode à verify-full ou verify-ca, et en fournissant au système un certificat racine à vérifier. Ceci est analogue à l'utilisation des URL https pour la navigation web chiffrée.

Une fois que le serveur est authentifié, le client peut envoyer des données sensibles. Cela signifie que jusqu'à ce point, le client n'a pas besoin de savoir si les certificats seront utilisés pour l'authentification, rendant particulièrement sûr de ne spécifier que ceci dans la configuration du serveur.

Toutes les options SSL ont une surcharge du type chiffrement et échange de clés. Il y a donc une balance entre performance et sécurité. Tableau 33.1 illustre les risques que les différentes valeurs de sslmode cherchent à protéger, et ce que cela apporte en sécurité et fait perdre en performances.

La différence entre verify-ca et verify-full dépend de la politique du CA racine. Si un CA publique est utilisé, verify-ca permet les connexions à un serveur que quelqu'un d'autre a pu enregistrer avec un CA accepté. Dans ce cas, verify-full devrait toujours être utilisé. Si un CA local est utilisé, voire même un certificat signé soi-même, utiliser verify-ca fournit souvent suffisamment de protection.

La valeur par défaut pour sslmode est prefer. Comme l'indique la table ci-dessus, cela n'a pas de sens d'un point de vue de la sécurité, et cela ne promet qu'une surcharge en terme de performance si possible. C'est uniquement fourni comme valeur par défaut pour la compatibilité ascendante, et n'est pas recommandé pour les déploiements de serveurs nécessitant de la sécurité.

Tableau 33.2 résume les fichiers liés à la configuration de SSL sur le client.

Si votre application initialise les bibliothèques libssl et/ou libcrypto et que libpq est construit avec le support de SSL, vous devez appeler la fonction PQinitOpenSSL pour indiquer à libpq que les bibliothèques libssl et/ou libcrypto ont été initialisées par votre application, de façon à ce que libpq n'initialise pas elle-aussi ces bibliothèques.