With <acronym>SSL</acronym> support compiled in, the <productname>PostgreSQL</productname> server can be started with support for encrypted connections using <acronym>TLS</acronym> protocols enabled by setting the parameter <xref linkend="guc-ssl"/> to <literal>on</literal> in <filename>postgresql.conf</filename>. The server will listen for both normal and <acronym>SSL</acronym> connections on the same TCP port, and will negotiate with any connecting client on whether to use <acronym>SSL</acronym>. By default, this is at the client's option; see <xref linkend="auth-pg-hba-conf"/> about how to set up the server to require use of <acronym>SSL</acronym> for some or all connections. SSLサポートを有効にしてコンパイルされた場合、PostgreSQLサーバは、postgresql.confにおいてsslパラメータをonにすることで、TLSプロトコルを使った暗号化された接続のサポートを有効にして起動することができます。 サーバは同じTCPポートで通常の接続とSSL接続の両方を待ち受け、クライアントとの接続にSSLを使用するかどうかを調停します。 デフォルトでは、これはクライアント側の選択肢です。 一部またはすべての接続でSSLの使用を必要とさせるためのサーバ側の設定方法に関しては21.1を参照してください。

To start in <acronym>SSL</acronym> mode, files containing the server certificate and private key must exist. By default, these files are expected to be named <filename>server.crt</filename> and <filename>server.key</filename>, respectively, in the server's data directory, but other names and locations can be specified using the configuration parameters <xref linkend="guc-ssl-cert-file"/> and <xref linkend="guc-ssl-key-file"/>. SSLモードで起動するには、サーバ証明書と秘密鍵を含むファイルが存在していなければなりません。 デフォルトでは、これらのファイルはserver.crtおよびserver.keyという名前で、それぞれがサーバのデータディレクトリに存在していることが想定されていますが、設定パラメータのssl_cert_fileとssl_key_fileによって他の名前、他の場所を指定することもできます。

On Unix systems, the permissions on <filename>server.key</filename> must disallow any access to world or group; achieve this by the command <command>chmod 0600 server.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 under which the <productname>PostgreSQL</productname> server runs should then be made a member of the group that has access to those certificate and key files. Unixシステムでは、server.keyの権限は所有者以外からのアクセスを許可してはなりません。 これはchmod 0600 server.keyというコマンドで実現できます。 あるいは、このファイルの所有者をrootにして、グループに読み取りアクセス権を与える（つまり、パーミッションを0640にする）ということもできます。 この設定は、証明書と鍵ファイルがオペレーティングシステムによって管理されるインストレーションのためのものです。 PostgreSQLサーバを実行するユーザは、証明書と鍵ファイルにアクセス権のあるグループのメンバーにする必要があります。

If the data directory allows group read access then certificate files may need to be located outside of the data directory in order to conform to the security requirements outlined above. Generally, group access is enabled to allow an unprivileged user to backup the database, and in that case the backup software will not be able to read the certificate files and will likely error. データディレクトリがグループアクセスを許可している場合、証明書ファイルは上記のセキュリティ上の要求を満たすためにデータディレクトリ外に置く必要があるかも知れません。 一般に、グループアクセスは権限を持たないユーザがデータベースをバックアップできるように有効化されます。 この場合、バックアップソフトウェアは証明書を読むことができず、おそらくエラーとなるでしょう。

If the private key is protected with a passphrase, the server will prompt for the passphrase and will not start until it has been entered. Using a passphrase by default disables the ability to change the server's SSL configuration without a server restart, but see <xref linkend="guc-ssl-passphrase-command-supports-reload"/>. Furthermore, passphrase-protected private keys cannot be used at all on Windows. 秘密鍵がパスフレーズで保護されている場合、サーバはパスフレーズの入力を促し、入力されるまでは起動しません。 パスフレーズを使用すると、サーバを再起動せずにサーバのSSL設定を変更する機能はデフォルトで無効になりますが、ssl_passphrase_command_supports_reloadを参照してください。 さらに、パスフレーズで保護された秘密鍵は、Windowsではまったく使用できません。

The first certificate in <filename>server.crt</filename> must be the server's certificate because it must match the server's private key. The certificates of <quote>intermediate</quote> certificate authorities can also be appended to the file. Doing this avoids the necessity of storing intermediate certificates on clients, assuming the root and intermediate certificates were created with <literal>v3_ca</literal> extensions. (This sets the certificate's basic constraint of <literal>CA</literal> to <literal>true</literal>.) This allows easier expiration of intermediate certificates. server.crtの最初の証明書は、サーバ証明書になり、秘密鍵とマッチしなければなりません。 「中間」認証局の証明書をファイルに追加することもできます。 これにより、ルートと中間証明書がv3_ca拡張により作成されていることが前提になりますが、中間証明書をクライアントに保存する必要が無くなります。 （これにより、CAの証明書の基本制約がtrueに設定されます。） これは、中間証明書の有効期限の扱いをより簡単にします。

It is not necessary to add the root certificate to <filename>server.crt</filename>. Instead, clients must have the root certificate of the server's certificate chain. server.crtにルート証明書を追加する必要はありません。 代わりに、クライアントはサーバ証明書のチェーンのルート証明書を持っていなければなりません。

<productname>PostgreSQL</productname> reads the system-wide <productname>OpenSSL</productname> configuration file. By default, this file is named <filename>openssl.cnf</filename> and is located in the directory reported by <literal>openssl version -d</literal>. This default can be overridden by setting environment variable <envar>OPENSSL_CONF</envar> to the name of the desired configuration file. PostgreSQLはシステム全体のOpenSSL設定ファイルを読み込みます。 デフォルトでは、このファイルはopenssl.cnfという名前で、openssl version -dが報告するディレクトリに設置されます。 このデフォルトはOPENSSL_CONF環境変数を設定することによって希望の名前に置き換えることができます。

<productname>OpenSSL</productname> supports a wide range of ciphers and authentication algorithms, of varying strength. While a list of ciphers can be specified in the <productname>OpenSSL</productname> configuration file, you can specify ciphers specifically for use by the database server by modifying <xref linkend="guc-ssl-ciphers"/> in <filename>postgresql.conf</filename>. OpenSSLは様々な強度を持つ、多様な暗号と認証アルゴリズムをサポートしています。 暗号のリストはOpenSSLの設定ファイルで指定できますが、使用するデータベースサーバ用にpostgresql.confのssl_ciphersで指定することができます。

To require the client to supply a trusted certificate, place certificates of the root certificate authorities (<acronym>CA</acronym>s) you trust in a file in the data directory, set the parameter <xref linkend="guc-ssl-ca-file"/> in <filename>postgresql.conf</filename> to the new file name, and add the authentication option <literal>clientcert=verify-ca</literal> or <literal>clientcert=verify-full</literal> to the appropriate <literal>hostssl</literal> line(s) in <filename>pg_hba.conf</filename>. A certificate will then be requested from the client during SSL connection startup. (See <xref linkend="libpq-ssl"/> for a description of how to set up certificates on the client.) 信頼できる証明書をクライアントに要求するには、信頼するルート認証局（CA）の証明書をデータディレクトリ内のファイルに置き、postgresql.confのssl_ca_fileパラメータを設定し、認証オプションclientcert=verify-caまたはclientcert=verify-fullをpg_hba.confの適切なhostssl行に追加します。 そうすると、SSL接続の開始時にクライアントへ証明書が要求されます。 （クライアント上での証明書の設定方法については34.19を参照してください。）

For a <literal>hostssl</literal> entry with <literal>clientcert=verify-ca</literal>, the server will verify that the client's certificate is signed by one of the trusted certificate authorities. If <literal>clientcert=verify-full</literal> is specified, the server will not only verify the certificate chain, but it will also check whether the username or its mapping matches the <literal>cn</literal> (Common Name) of the provided certificate. Note that certificate chain validation is always ensured when the <literal>cert</literal> authentication method is used (see <xref linkend="auth-cert"/>). clientcert=verify-ca指定付きのhostsslエントリでは、サーバは、クライアントの証明書が信頼する認証局のいずれかにより署名されていることを検証します。 clientcert=verify-fullが指定されていると、サーバは証明書チェーンを検証するだけでなく、ユーザ名あるいはユーザ名のマッピングが提供された証明書のcn (Common Name)に一致しているかどうかも検証します。 cert認証メソッドが使われている場合は認証チェーンの検証は常に行われることに注意してください。 （21.12参照。）

Intermediate certificates that chain up to existing root certificates can also appear in the <xref linkend="guc-ssl-ca-file"/> file if you wish to avoid storing them on clients (assuming the root and intermediate certificates were created with <literal>v3_ca</literal> extensions). Certificate Revocation List (CRL) entries are also checked if the parameter <xref linkend="guc-ssl-crl-file"/> or <xref linkend="guc-ssl-crl-dir"/> is set. 既存のルート証明書に連鎖する中間証明書は、クライアントに保存することを避けたい場合にssl_ca_fileに含めることができます（ルート証明書と中間証明書がv3_ca拡張で作成されている場合）。 ssl_crl_fileあるいはssl_crl_dirパラメータが設定されている場合、証明書失効リスト（CRL）項目も検査されます。

The <literal>clientcert</literal> authentication option is available for all authentication methods, but only in <filename>pg_hba.conf</filename> lines specified as <literal>hostssl</literal>. When <literal>clientcert</literal> is not specified, the server verifies the client certificate against its CA file only if a client certificate is presented and the CA is configured. 認証オプションclientcertはすべての認証方式について利用可能ですが、pg_hba.confのhostsslとして指定された行でのみ有効です。 clientcertが指定されていない場合でも、クライアント証明書が提示され、認証局が設定されているときに限ってサーバはその認証局ファイルに対してクライアント証明書の検証を行います。

There are two approaches to enforce that users provide a certificate during login. ユーザに対してログイン中に証明書を提供するように強制する二つのアプローチがあります。

The first approach makes use of the <literal>cert</literal> authentication method for <literal>hostssl</literal> entries in <filename>pg_hba.conf</filename>, such that the certificate itself is used for authentication while also providing ssl connection security. See <xref linkend="auth-cert"/> for details. (It is not necessary to specify any <literal>clientcert</literal> options explicitly when using the <literal>cert</literal> authentication method.) In this case, the <literal>cn</literal> (Common Name) provided in the certificate is checked against the user name or an applicable mapping. 最初のアプローチはpg_hba.confのhostsslにcert認証メソッドを使うことです。 そうすることによりSSL接続によるセキュリティが提供されるとともに、証明書自身が認証に使われます。 詳細は21.12をご覧ください。 （cert認証メソッドを使う際には明示的にclientcertオプションを指定する必要はありません。） この場合証明書が提供するcn (Common Name)がユーザ名あるいは適用可能なマッピングに対して検証されます。

The second approach combines any authentication method for <literal>hostssl</literal> entries with the verification of client certificates by setting the <literal>clientcert</literal> authentication option to <literal>verify-ca</literal> or <literal>verify-full</literal>. The former option only enforces that the certificate is valid, while the latter also ensures that the <literal>cn</literal> (Common Name) in the certificate matches the user name or an applicable mapping. 二番目のアプローチは、clientcert認証オプションにverify-caあるいはverify-fullを設定することによってhostsslエントリの認証メソッドにクライアント証明書の検証を組み合わせることです。 前者のオプションは証明書が有効であることだけを強制し、後者は更に証明書のcn (Common Name)がユーザ名あるいは適用可能なマッピングと一致することを強制します。

<xref linkend="ssl-file-usage"/> summarizes the files that are relevant to the SSL setup on the server. (The shown file names are default names. The locally configured names could be different.) 表 19.2にて、サーバにおけるSSLの設定に関連するファイルをまとめます。 （表示されているファイル名はデフォルトまたは一般的な名前です。異なる名前を個別に設定することもできます。）

The server reads these files at server start and whenever the server configuration is reloaded. On <systemitem class="osname">Windows</systemitem> systems, they are also re-read whenever a new backend process is spawned for a new client connection. サーバは、サーバ起動時及びサーバ設定がリロードされるたびに、これらのファイルを読み取ります。 Windowsシステム上では新しいクライアント接続のために新しいバックエンドプロセスが生成されるたびに再読み込みされます。

If an error in these files is detected at server start, the server will refuse to start. But if an error is detected during a configuration reload, the files are ignored and the old SSL configuration continues to be used. On <systemitem class="osname">Windows</systemitem> systems, if an error in these files is detected at backend start, that backend will be unable to establish an SSL connection. In all these cases, the error condition is reported in the server log. サーバ起動時にこれらのファイルのエラーが検出された場合、サーバは起動を拒否します。 ただし、設定のリロード中にエラーが検出された場合、ファイルは無視され、古いSSL設定が引き続き使用されます。 Windowsシステム上ではバックエンドの開始時にこれらのファイルのエラーが検出された場合、そのバックエンドはSSL接続を確立出来ません。 これらのすべてのケースでは、エラー状態がサーバログに記録されます。

To create a simple self-signed certificate for the server, valid for 365 days, use the following <productname>OpenSSL</productname> command, replacing <replaceable>dbhost.yourdomain.com</replaceable> with the server's host name: 365日有効なサーバ用の自己署名証明書を簡単に作るためには下記のOpenSSLコマンドを実行してください（dbhost.yourdomain.comをサーバのホスト名に置き換えてください）。

openssl req -new -x509 -days 365 -nodes -text -out server.crt \
  -keyout server.key -subj "/CN=dbhost.yourdomain.com"

Then do: 続けて以下も実行します。

chmod og-rwx server.key

because the server will reject the file if its permissions are more liberal than this. For more details on how to create your server private key and certificate, refer to the <productname>OpenSSL</productname> documentation. サーバの秘密鍵および証明書を作成するための詳しい方法についてはOpenSSLの文書を参照してください。

While a self-signed certificate can be used for testing, a certificate signed by a certificate authority (<acronym>CA</acronym>) (usually an enterprise-wide root <acronym>CA</acronym>) should be used in production. テストには自己署名証明書を使用できますが、運用時は認証局(CA)（通常は事業全体のCA）により署名された証明書を使用する必要があります。

To create a server certificate whose identity can be validated by clients, first create a certificate signing request (<acronym>CSR</acronym>) and a public/private key file: クライアントが身元を検証できるサーバ証明書を作成するには、まず最初に証明書署名要求(CSR) と公開／秘密鍵を作成します。

openssl req -new -nodes -text -out root.csr \
  -keyout root.key -subj "/CN=root.yourdomain.com"
chmod og-rwx root.key

Then, sign the request with the key to create a root certificate authority (using the default <productname>OpenSSL</productname> configuration file location on <productname>Linux</productname>): その後、鍵を使用して署名要求に署名しルート証明書を作成します（Linux上のデフォルトのOpenSSL設定ファイルの場所を使用）。

openssl x509 -req -in root.csr -text -days 3650 \
  -extfile /etc/ssl/openssl.cnf -extensions v3_ca \
  -signkey root.key -out root.crt

Finally, create a server certificate signed by the new root certificate authority: 最後に、新しいルート証明書によって署名されるサーバ証明書を作成します。

openssl req -new -nodes -text -out server.csr \
  -keyout server.key -subj "/CN=dbhost.yourdomain.com"
chmod og-rwx server.key

openssl x509 -req -in server.csr -text -days 365 \
  -CA root.crt -CAkey root.key -CAcreateserial \
  -out server.crt

<filename>server.crt</filename> and <filename>server.key</filename> should be stored on the server, and <filename>root.crt</filename> should be stored on the client so the client can verify that the server's leaf certificate was signed by its trusted root certificate. <filename>root.key</filename> should be stored offline for use in creating future certificates. server.crtとserver.keyをサーバに格納し、root.crtをクライアントに格納します。 クライアントはサーバのリーフ証明書が信頼されたルート証明書によって署名されたことを確認できます。 root.keyは将来の証明書の作成に使用するために、オフラインで保存する必要があります。

It is also possible to create a chain of trust that includes intermediate certificates: 中間証明書が含まれる信頼の連鎖を作成することも可能です。

# root
openssl req -new -nodes -text -out root.csr \
  -keyout root.key -subj "/CN=root.yourdomain.com"
chmod og-rwx root.key
openssl x509 -req -in root.csr -text -days 3650 \
  -extfile /etc/ssl/openssl.cnf -extensions v3_ca \
  -signkey root.key -out root.crt

# intermediate
openssl req -new -nodes -text -out intermediate.csr \
  -keyout intermediate.key -subj "/CN=intermediate.yourdomain.com"
chmod og-rwx intermediate.key
openssl x509 -req -in intermediate.csr -text -days 1825 \
  -extfile /etc/ssl/openssl.cnf -extensions v3_ca \
  -CA root.crt -CAkey root.key -CAcreateserial \
  -out intermediate.crt

# leaf
openssl req -new -nodes -text -out server.csr \
  -keyout server.key -subj "/CN=dbhost.yourdomain.com"
chmod og-rwx server.key
openssl x509 -req -in server.csr -text -days 365 \
  -CA intermediate.crt -CAkey intermediate.key -CAcreateserial \
  -out server.crt

<filename>server.crt</filename> and <filename>intermediate.crt</filename> should be concatenated into a certificate file bundle and stored on the server. <filename>server.key</filename> should also be stored on the server. <filename>root.crt</filename> should be stored on the client so the client can verify that the server's leaf certificate was signed by a chain of certificates linked to its trusted root certificate. <filename>root.key</filename> and <filename>intermediate.key</filename> should be stored offline for use in creating future certificates. server.crtとintermediate.crtは証明書ファイルに束ねて連結し、サーバに格納する必要があります。 server.keyもまたサーバに格納される必要があります。 サーバのリーフ証明書が信頼されたルート証明書にリンクされた一連の証明書によって署名されていることをクライアントが確認できるように、root.crtをクライアントに格納する必要があります。 root.keyとintermediate.keyは将来の証明書を作成に使用するためにオフラインで格納する必要があります。