デフォルトではPostgreSQLはサーバ証明書の検証をまったく行いません。 これは、（例えば、DNSレコードを変更したり、もしくはサーバのIPアドレスを接収したりして）クライアントに知られずにサーバの属性をなりすませることを意味します。 なりすましを防止するにはSSL証明書検証を使用しなければなりません。

パラメータsslmodeがverify-caに設定されている場合、libpqは信頼される認証局(CA)までの証明書連鎖を検査することで、サーバが信用に足るかを検証します。 sslmodeがverify-fullに設定されていると、libpqは同時にサーバホスト名が証明書のそれと一致するかを検証します。 SSL接続はサーバ証明書が検証されない場合失敗します。 安全性に慎重を期するほとんどのサーバ環境ではverify-fullを推奨します。

verify-fullモードでは、ホスト名を証明書のサブジェクト別名(Subject Alternative Name)属性と、あるいはdNSNameタイプのサブジェクト別名がないときはコモンネーム属性とマッチさせます。 証明書の名前属性がアスタリスク（*）で始まると、それはワイルドカードとして取り扱われ、ドット（.）を除くすべての文字とマッチします。 これは、証明書がサブドメインとマッチしないことを意味します。 もし接続がホスト名ではなくIPアドレスを使用するのであれば、（いかなるDNS検索もせず）IPアドレスがマッチさせられます。

サーバ証明書の検証を可能にするには、1つ以上の信頼するCAの証明書を、ユーザのホームディレクトリの~/.postgresql/root.crtファイルに置かなければなりません。 中間CAがroot.crtにあるのであれば、そのファイルはそのルートCAへの証明書チェーンも含まなければなりません。 （Microsoft Windowsの場合、このファイルの名前は%APPDATA%\postgresql\root.crtです。）

~/.postgresql/root.crlファイル（Microsoft Windowsでは%APPDATA%\postgresql\root.crl）が存在する場合、証明書失効リスト（CRL）の項目もまた検査されます。

ルート証明書ファイルとCRLの格納場所を接続パラメータsslrootcertとsslcrl、もしくは環境変数PGSSLROOTCERTとPGSSLCRLで変更することができます。

サーバが信頼できるクライアント証明書を要求する場合、libpqはユーザのホームディレクトリにある~/.postgresql/postgresql.crtファイルに格納された証明書を送信します。 証明書はサーバで信頼された認証局（CA）のいずれかで署名されなければなりません。 対応する~/.postgresql/postgresql.key秘密キーファイルも存在しなければなりません。 秘密キーファイルは他者やグループからのアクセスを許可してはいけません。 chmod 0600 ~/.postgresql/postgresql.keyコマンドでこれを実現してください。 Microsoft Windowsでは、このファイルの名前はそれぞれ%APPDATA%\postgresql\postgresql.crtと%APPDATA%\postgresql\postgresql.keyであり、このディレクトリは安全であると想定されますので、特別な権限検査は行われません。 証明書とキーファイルの格納場所はsslcertおよびsslkey接続パラメータ、またはPGSSLCERTおよびPGSSLKEY環境変数で上書きされます。

クライアント証明書が、サーバにより直接信頼された認証局ではなく、「中間」認証局で署名されている場合があります。 こうした証明書を使用するためには、署名した認証局の証明書を、さらにその親の認証局の証明書を、サーバにより信頼される「ルート」もしくは「中間」認証局までpostgresql.crtファイルに追加してください。 サーバにより信頼されるとは、すなわちサーバのroot.crtファイルにある証明書により署名されているということです。

クライアントの~/.postgresql/root.crtには、サーバ証明書の署名に関して信頼できるとみなされる、最上位のCAが列挙されていることに注意してください。 原理的にはクライアント証明書を署名するCAを列挙する必要はありませんが、ほとんどの場合において、そのCAは同時にサーバ証明書に対しても信頼されています。

sslmodeパラメータ値を変更することで、異なったレベルの保護を提供します。 SSLは以下の３種類の攻撃に対する保護を提供することができます。

信頼できるとされる接続では、SSLの使用を接続確立前にクライアントとサーバの双方において設定されなければなりません。 サーバのみに構成されると、クライアントはサーバが高度なセキュリティを必要とすることが判る以前に、（例えばパスワードのような）機密事項を扱う情報を結局送ることになります。 libpqにおいて、sslmodeパラメータをverify-fullまたはverify-caに設定し、そして対象を検証するためルート証明書をシステムに提供することで、安全な接続を確実に行うことができます。 これは暗号化されたweb閲覧に対するhttps URLの使用とよく似ています。

一度サーバが認証されると、クライアントは機密事項を扱うデータを送ることができます。 この意味は、これまでクライアントは認証に証明書が使われているかどうかを知る必要がなく、サーバ構成においてのみこのことを指定しても安全だと言うことです。

すべてのSSLオプションでは暗号化の形式と鍵交換といったオーバヘッドがかかります。 このため性能と安全性との間で決定されるべきトレードオフがあります。 表31.1「SSLモードの説明」は異なるsslmode値が防御する危険性と、安全性とオーバヘッドに対する声明を示したものです。

verify-caとverify-fullの差異はルートCAの規定に依存します。 公的なCAが使用されるとき、verify-caはそのCAで他の誰かが登録したかもしれないサーバへの接続を許可します。 この場合、verify-fullが常に使用されなければなりません。 独自CAが使用されるとき、または自己署名証明書であったとしてもverify-caは十分な防御策を提供します。

sslmodeのデフォルト値はpreferです。 表で示したように、これはセキュリティの視点では意味がなく、可能であれば性能上のオーバヘッドを保証するだけです。 これは後方互換性を提供するためのみにデフォルトとなっているもので、安全性確保の観点からは推奨されません。

表31.2「libpq/クライアントにおけるSSLファイルの使用方法」にクライアントにおけるSSL設定に関連するファイルをまとめます。

使用するアプリケーションがlibsslとlibcryptoの両方またはいずれか一方のライブラリを初期化し、libpqがSSLサポート付きで構築された場合、libsslとlibcryptoの両方またはいずれか一方のライブラリはアプリケーションによって初期化されたことをlibpqに伝えるためPQinitOpenSSLを呼び出さなければなりません。 これにより、libpqはこれらのライブラリを初期化しなくなります。 SSL APIの詳細はhttp://h71000.www7.hp.com/doc/83final/BA554_90007/ch04.htmlを参照してください。