By default, <productname>PostgreSQL</productname> will not perform any verification of the server certificate. This means that it is possible to spoof the server identity (for example by modifying a DNS record or by taking over the server IP address) without the client knowing. In order to prevent spoofing, the client must be able to verify the server's identity via a chain of trust. A chain of trust is established by placing a root (self-signed) certificate authority (<acronym>CA</acronym>) certificate on one computer and a leaf certificate <emphasis>signed</emphasis> by the root certificate on another computer. It is also possible to use an <quote>intermediate</quote> certificate which is signed by the root certificate and signs leaf certificates. デフォルトではPostgreSQLはサーバ証明書の検証をまったく行いません。 これは、（例えば、DNSレコードを変更したり、もしくはサーバのIPアドレスを乗っ取ったりして）クライアントに知られずにサーバの身元をなりすませることを意味します。 なりすましを防止するには、クライアントは、トラストチェーン(chain of trust)を通じて、サーバの身元を検証できなければなりません。 トラストチェーンは、ルート（自己署名）認証局（CA）証明書をあるコンピュータに設置し、そのルート証明書によって署名されたリーフ証明書を他のコンピュータに設置することによって確立されます。 また、ルート証明書によって署名された「中間」証明書を使って、リーフ証明書に署名することによっても可能です。

To allow the client to verify the identity of the server, place a root certificate on the client and a leaf certificate signed by the root certificate on the server. To allow the server to verify the identity of the client, place a root certificate on the server and a leaf certificate signed by the root certificate on the client. One or more intermediate certificates (usually stored with the leaf certificate) can also be used to link the leaf certificate to the root certificate. クライアントがサーバの身元を検証するためには、ルート証明書をクライアントに設置し、そのルート証明書によって署名されたリーフ証明書をサーバに設置します。 サーバがクライアントの身元を検証するためには、ルート証明書をサーバに設置し、そのルート証明書によって署名されたリーフ証明書をクライアントに設置します。 一つ以上の中間証明書（通常リーフ証明書とともに格納されます）を使って、リーフ証明書をルート証明書につなげることもできます。

Once a chain of trust has been established, there are two ways for the client to validate the leaf certificate sent by the server. If the parameter <literal>sslmode</literal> is set to <literal>verify-ca</literal>, libpq will verify that the server is trustworthy by checking the certificate chain up to the root certificate stored on the client. If <literal>sslmode</literal> is set to <literal>verify-full</literal>, libpq will <emphasis>also</emphasis> verify that the server host name matches the name stored in the server certificate. The SSL connection will fail if the server certificate cannot be verified. <literal>verify-full</literal> is recommended in most security-sensitive environments. トラストチェーンがひとたび確立されれば、クライアントがサーバから送信されたリーフ証明書を検証する二つの方法があります。 パラメータsslmodeがverify-caに設定されている場合、libpqはクライアントに格納されたルート証明書までの証明書連鎖を検査することで、サーバが信用に足るかを検証します。 sslmodeがverify-fullに設定されていると、libpqは同時にサーバホスト名が証明書のそれと一致するかを検証します。 SSL接続はサーバ証明書が検証されない場合失敗します。 安全性に慎重を期するほとんどのサーバ環境ではverify-fullを推奨します。

In <literal>verify-full</literal> mode, the host name is matched against the certificate's Subject Alternative Name attribute(s) (SAN), or against the Common Name attribute if no SAN of type <literal>dNSName</literal> is present. If the certificate's name attribute starts with an asterisk (<literal>*</literal>), the asterisk will be treated as a wildcard, which will match all characters <emphasis>except</emphasis> a dot (<literal>.</literal>). This means the certificate will not match subdomains. If the connection is made using an IP address instead of a host name, the IP address will be matched (without doing any DNS lookups) against SANs of type <literal>iPAddress</literal> or <literal>dNSName</literal>. If no <literal>iPAddress</literal> SAN is present and no matching <literal>dNSName</literal> SAN is present, the host IP address is matched against the Common Name attribute. verify-fullモードでは、ホスト名を証明書のサブジェクト別名(Subject Alternative Name(SAN))属性と、あるいはdNSNameタイプのサブジェクト別名がないときはコモンネーム属性とマッチさせます。 証明書の名前属性がアスタリスク（*）で始まると、それはワイルドカードとして取り扱われ、ドット（.）を除くすべての文字とマッチします。 これは、証明書がサブドメインとマッチしないことを意味します。 もし接続がホスト名ではなくIPアドレスを使用するのであれば、タイプiPAddressまたはdNSNameのSANに対してIPアドレスが照合されます(DNS検索は実行されません)。iPAddressSANが存在せず、マッチングdNSNameSANが存在しない場合、ホストIPアドレスはコモンネーム属性に対して照合されます。

To allow server certificate verification, one or more root certificates must be placed in the file <filename>~/.postgresql/root.crt</filename> in the user's home directory. (On Microsoft Windows the file is named <filename>%APPDATA%\postgresql\root.crt</filename>.) Intermediate certificates should also be added to the file if they are needed to link the certificate chain sent by the server to the root certificates stored on the client. サーバ証明書の検証を可能にするには、1つ以上のルート証明書を、ユーザのホームディレクトリの~/.postgresql/root.crtファイルに置かなければなりません。 （Microsoft Windowsの場合、このファイルの名前は%APPDATA%\postgresql\root.crtです。） サーバより送信された証明書連鎖から、クライアントに格納されたルート証明書にリンクするために（中間証明書が）必要なら、中間証明書もそのファイルに追加する必要があります。

Certificate Revocation List (CRL) entries are also checked if the file <filename>~/.postgresql/root.crl</filename> exists (<filename>%APPDATA%\postgresql\root.crl</filename> on Microsoft Windows). ~/.postgresql/root.crlファイル（Microsoft Windowsでは%APPDATA%\postgresql\root.crl）が存在する場合、証明書失効リスト（CRL）の項目もまた検査されます。

The location of the root certificate file and the CRL can be changed by setting the connection parameters <literal>sslrootcert</literal> and <literal>sslcrl</literal> or the environment variables <envar>PGSSLROOTCERT</envar> and <envar>PGSSLCRL</envar>. <literal>sslcrldir</literal> or the environment variable <envar>PGSSLCRLDIR</envar> can also be used to specify a directory containing CRL files. ルート証明書ファイルとCRLの格納場所を接続パラメータsslrootcertとsslcrl、もしくは環境変数PGSSLROOTCERTとPGSSLCRLで変更することができます。 sslcrldirまたは環境変数PGSSLCRLDIRを使用して、CRLファイルを含むディレクトリを指定することもできます。

If the server attempts to verify the identity of the client by requesting the client's leaf certificate, <application>libpq</application> will send the certificate(s) stored in file <filename>~/.postgresql/postgresql.crt</filename> in the user's home directory. The certificates must chain to the root certificate trusted by the server. A matching private key file <filename>~/.postgresql/postgresql.key</filename> must also be present. On Microsoft Windows these files are named <filename>%APPDATA%\postgresql\postgresql.crt</filename> and <filename>%APPDATA%\postgresql\postgresql.key</filename>. The location of the certificate and key files can be overridden by the connection parameters <literal>sslcert</literal> and <literal>sslkey</literal>, or by the environment variables <envar>PGSSLCERT</envar> and <envar>PGSSLKEY</envar>. サーバが、クライアントのリーフ証明書を要求することによってクライアントの身元を検証しようとする場合、libpqはユーザのホームディレクトリにある~/.postgresql/postgresql.crtファイルに格納された証明書を送信します。 証明書は、サーバが信頼するルート証明書につながらなければなりません。 対応する~/.postgresql/postgresql.key秘密キーファイルも存在しなければなりません。 秘密キーファイルは他者やグループからのアクセスを許可してはいけません。 Microsoft Windowsでは、このファイルの名前はそれぞれ%APPDATA%\postgresql\postgresql.crtと%APPDATA%\postgresql\postgresql.keyです。 証明書とキーファイルの格納場所はsslcertおよびsslkey接続パラメータ、またはPGSSLCERTおよびPGSSLKEY環境変数で上書きされます。

On Unix systems, the permissions on the private key file must disallow any access to world or group; achieve this by a command such as <command>chmod 0600 ~/.postgresql/postgresql.key</command>. Alternatively, the file can be owned by root and have group read access (that is, <literal>0640</literal> permissions). That setup is intended for installations where certificate and key files are managed by the operating system. The user of <application>libpq</application> should then be made a member of the group that has access to those certificate and key files. (On Microsoft Windows, there is no file permissions check, since the <filename>%APPDATA%\postgresql</filename> directory is presumed secure.) Unixシステムにおいて、秘密鍵ファイル権限はグループ、他者へのアクセスをすべて拒否しなければなりません。 これはchmod 0600~/.postgresql/postgresql.keyといったコマンドによって行います。 あるいは、このファイルをrootが所有し、グループの読み取りアクセス権（つまり0640のアクセス権）を持つこともできます。 このセットアップは、証明書と鍵ファイルがオペレーティングシステムによって管理されているインストールを対象としています。 libpqのユーザは、これらの証明書と鍵ファイルへのアクセス権を持つグループのメンバになる必要があります。 （Microsoft Windowsにおいては、%APPDATA%\postgresqlディレクトリが安全であると考えられるため、ファイルの権限の検査は行われません。）

The first certificate in <filename>postgresql.crt</filename> must be the client's certificate because it must match the client's private key. <quote>Intermediate</quote> certificates can be optionally appended to the file &mdash; doing so avoids requiring storage of intermediate certificates on the server (<xref linkend="guc-ssl-ca-file"/>). postgresql.crt中の最初の証明書は、クライアント証明書でなければなりません。 クライアントの秘密鍵と一致していなければならないからです。 オプションで、ファイルに「中間」証明書を追加することができます。 そうすることによって、サーバ上に中間証明書（ssl_ca_file）の格納が不要になります。

The certificate and key may be in PEM or ASN.1 DER format. 証明書とキーはPEMまたはASN.1 DER形式です。

The key may be stored in cleartext or encrypted with a passphrase using any algorithm supported by <productname>OpenSSL</productname>, like AES-128. If the key is stored encrypted, then the passphrase may be provided in the <xref linkend="libpq-connect-sslpassword"/> connection option. If an encrypted key is supplied and the <literal>sslpassword</literal> option is absent or blank, a password will be prompted for interactively by <productname>OpenSSL</productname> with a <literal>Enter PEM pass phrase:</literal> prompt if a TTY is available. Applications can override the client certificate prompt and the handling of the <literal>sslpassword</literal> parameter by supplying their own key password callback; see <xref linkend="libpq-pqsetsslkeypasshook-openssl"/>. キーは平文テキストで、あるいは、OpenSSLで対応しているAES-128など任意のアルゴリズムを使ってパスフレーズで暗号化して、格納できます。 キーが暗号化されて格納された場合、パスフレーズはsslpassword接続オプションで供給してもよいです。 暗号化されたキーが供給されて、かつ、sslpasswordが無いか空欄の場合、TTYが利用可能であればパスワードはOpenSSLによりEnter PEM pass phrase:プロンプトで対話的に入力が要求されます。 アプリケーションはクライアント証明書のプロンプトとsslpasswordパラメータの操作を、自身のキーパスワードコールバックを供給することで置き換えできます。 PQsetSSLKeyPassHook_OpenSSLを参照してください。

For instructions on creating certificates, see <xref linkend="ssl-certificate-creation"/>. 証明書の作成手順については、19.9.5をご覧ください。

The different values for the <literal>sslmode</literal> parameter provide different levels of protection. SSL can provide protection against three types of attacks: sslmodeパラメータ値を変更することで、異なったレベルの保護を提供します。 SSLは以下の３種類の攻撃に対する保護を提供することができます。

For a connection to be known SSL-secured, SSL usage must be configured on <emphasis>both the client and the server</emphasis> before the connection is made. If it is only configured on the server, the client may end up sending sensitive information (e.g., passwords) before it knows that the server requires high security. In libpq, secure connections can be ensured by setting the <literal>sslmode</literal> parameter to <literal>verify-full</literal> or <literal>verify-ca</literal>, and providing the system with a root certificate to verify against. This is analogous to using an <literal>https</literal> <acronym>URL</acronym> for encrypted web browsing. SSLで信頼できるとされる接続では、SSLの使用を接続確立前にクライアントとサーバの双方において設定されなければなりません。 サーバのみに構成されると、クライアントはサーバが高度なセキュリティを必要とすることが判る以前に、（例えばパスワードのような）機密事項を扱う情報を結局送ることになります。 libpqにおいて、sslmodeパラメータをverify-fullまたはverify-caに設定し、そして対象を検証するためルート証明書をシステムに提供することで、安全な接続を確実に行うことができます。 これは暗号化されたweb閲覧に対するhttps URLの使用とよく似ています。

Once the server has been authenticated, the client can pass sensitive data. This means that up until this point, the client does not need to know if certificates will be used for authentication, making it safe to specify that only in the server configuration. 一度サーバが認証されると、クライアントは機密事項を扱うデータを送ることができます。 この意味は、これまでクライアントは認証に証明書が使われているかどうかを知る必要がなく、サーバ構成においてのみこのことを指定しても安全だと言うことです。

All <acronym>SSL</acronym> options carry overhead in the form of encryption and key-exchange, so there is a trade-off that has to be made between performance and security. <xref linkend="libpq-ssl-sslmode-statements"/> illustrates the risks the different <literal>sslmode</literal> values protect against, and what statement they make about security and overhead. すべてのSSLオプションでは暗号化の形式と鍵交換といったオーバーヘッドがかかります。 このため性能と安全性との間で決定されるべきトレードオフがあります。 表 34.1は異なるsslmode値が防御する危険性と、安全性とオーバーヘッドに対する声明を示したものです。

The difference between <literal>verify-ca</literal> and <literal>verify-full</literal> depends on the policy of the root <acronym>CA</acronym>. If a public <acronym>CA</acronym> is used, <literal>verify-ca</literal> allows connections to a server that <emphasis>somebody else</emphasis> may have registered with the <acronym>CA</acronym>. In this case, <literal>verify-full</literal> should always be used. If a local <acronym>CA</acronym> is used, or even a self-signed certificate, using <literal>verify-ca</literal> often provides enough protection. verify-caとverify-fullの差異はルートCAの規定に依存します。 公的なCAが使用されるとき、verify-caはそのCAで他の誰かが登録したかもしれないサーバへの接続を許可します。 この場合、verify-fullが常に使用されなければなりません。 独自CAが使用されるとき、または自己署名証明書であったとしてもverify-caは十分な防御策を提供します。

The default value for <literal>sslmode</literal> is <literal>prefer</literal>. As is shown in the table, this makes no sense from a security point of view, and it only promises performance overhead if possible. It is only provided as the default for backward compatibility, and is not recommended in secure deployments. sslmodeのデフォルト値はpreferです。 表で示したように、これはセキュリティの視点では意味がなく、可能であれば性能上のオーバーヘッドを保証するだけです。 これは後方互換性を提供するためのみにデフォルトとなっているもので、安全性確保の観点からは推奨されません。

<xref linkend="libpq-ssl-file-usage"/> summarizes the files that are relevant to the SSL setup on the client. 表 34.2にクライアントにおけるSSL設定に関連するファイルをまとめます。

If your application initializes <literal>libssl</literal> and/or <literal>libcrypto</literal> libraries and <application>libpq</application> is built with <acronym>SSL</acronym> support, you should call <xref linkend="libpq-PQinitOpenSSL"/> to tell <application>libpq</application> that the <literal>libssl</literal> and/or <literal>libcrypto</literal> libraries have been initialized by your application, so that <application>libpq</application> will not also initialize those libraries. However, this is unnecessary when using <productname>OpenSSL</productname> version 1.1.0 or later, as duplicate initializations are no longer problematic. 使用するアプリケーションがlibsslとlibcryptoの両方またはいずれか一方のライブラリを初期化し、libpqがSSLサポート付きで構築された場合、libsslとlibcryptoの両方またはいずれか一方のライブラリはアプリケーションによって初期化されたことをlibpqに伝えるためPQinitOpenSSLを呼び出さなければなりません。 これにより、libpqはこれらのライブラリを初期化しなくなります。 ただし、OpenSSLバージョン1.1.0以降を使用している場合は、重複の初期化に問題がなくなるため、これは不要です。