Azure Database for PostgreSQL での TLS を使用したセキュリティで保護された接続

Azure Database for PostgreSQL では、トランスポート層セキュリティ (TLS) を使用して、クライアントアプリケーションを Azure Database for PostgreSQL フレキシブルサーバーインスタンスに接続します。 TLS は、データベースサーバーとクライアントアプリケーション間の暗号化されたネットワーク接続を保証する業界標準のプロトコルです。 TLS は、Secure Sockets Layer (SSL) の更新されたプロトコルです。 SSL と TLS という用語は引き続き同じ意味で使用されます。

Important

2025 年 11 月 11 日から、次の一覧の Azure リージョンは、新しい中間 CA 証明書を使用する TLS/SSL 証明書ローテーションに向けて計画されています。

米国中西部
東アジア
英国南部

2026 年 1 月 19 日以降、このローテーションは、Azure Government とその他のすべてのリージョンを含む、残りのすべての Azure リージョンに拡張される予定です。

トラブルシューティングの詳細については、「証明書のピン留めの問題」を参照してください。

証明書チェーン

証明書チェーンは、TLS/SSL 証明書と CA 証明書を含む証明書の順序付きリストです。受信者は、送信者とすべての CA が信頼できるかどうかを確認できます。チェーンまたはパスは、TLS/SSL 証明書で始まります。チェーン内の各証明書は、チェーン内の次の証明書によって識別されるエンティティによって署名されます。

チェーンは ルート CA 証明書で終了します。この証明書は、常に CA 自体によって署名されます。チェーン内のすべての証明書の署名は、ルート CA 証明書まで検証する必要があります。

TLS/SSL 証明書とチェーン内のルート CA 証明書の間に存在するすべての証明書は、中間証明書と呼ばれます。

TLS バージョン

世界中のいくつかの政府機関は、ネットワークセキュリティに関する TLS のガイドラインを維持しています。米国では、これらの組織には、保健福祉省と国立標準技術研究所が含まれます。 TLS が提供するセキュリティのレベルは、TLS プロトコルのバージョンとサポートされている暗号スイートの影響を最も受ける。

暗号スイートは、暗号、キー交換アルゴリズム、ハッシュアルゴリズムを含む一連のアルゴリズムです。これらは、セキュリティで保護された TLS 接続を確立するために一緒に使用されます。ほとんどの TLS クライアントとサーバーは、複数の代替手段をサポートしています。一般的な TLS バージョンと暗号スイートを選択するには、セキュリティで保護された接続を確立するときにネゴシエートする必要があります。

Azure Database for PostgreSQL では、TLS バージョン 1.2 以降がサポートされています。 RFC 8996 では、インターネットエンジニアリングタスクフォース (IETF) は、TLS 1.0 と TLS 1.1 を使用してはならないと明示的に述べています。どちらのプロトコルも 2019 年末までに非推奨となりました。

TLS 1.0 や TLS 1.1 など、以前のバージョンの TLS プロトコルを使用するすべての受信接続は、既定で拒否されます。

IETF は 2018 年 8 月に RFC 8446 で TLS 1.3 仕様をリリースしました。TLS 1.3 は現在、最も一般的で推奨される TLS バージョンです。 TLS 1.3 は TLS 1.2 よりも高速で安全です。

注

SSL 証明書と TLS 証明書は、最新の暗号化プロトコルで接続がセキュリティで保護されていることを証明します。ネットワーク上の接続を暗号化することで、転送中にデータへの不正アクセスを防ぐことができます。最新バージョンの TLS を使用して、Azure Database for PostgreSQL フレキシブルサーバーインスタンスへの接続を暗号化することを強くお勧めします。

お勧めしませんが、必要に応じて、Azure Database for PostgreSQL フレキシブルサーバーインスタンスへの接続に対して TLS\SSL を無効にすることができます。 require_secure_transport サーバーパラメーターをOFFに更新できます。また、 ssl_min_protocol_version および ssl_max_protocol_version サーバーパラメーターを設定して、TLS バージョンを設定することもできます。

証明書認証は、認証に SSL クライアント証明書を使用して実行されます。このシナリオでは、PostgreSQL サーバーは、提示されたクライアント証明書の共通名 (CN) 属性を、要求されたデータベースユーザーと比較します。

現時点では、Azure Database for PostgreSQL では次の機能はサポートされていません。

SSL 証明書ベースの認証。
カスタム SSL\TLS 証明書。

注

Microsoft は、Azure Database for PostgreSQL など、さまざまな Azure サービスに対してルート CA の変更を行いました。詳細については、「 Azure TLS 証明書の変更」および「クライアントでの SSL の構成」セクションを参照してください。

現在の TLS\SSL 接続の状態を確認するには、 sslinfo 拡張機能を読み込み、 ssl_is_used() 関数を呼び出して SSL が使用されているかどうかを確認します。接続で SSL が使用されている場合、この関数は t を返します。それ以外の場合は、 fを返します。また、次のクエリを使用して、プロセス、クライアント、アプリケーションによる Azure Database for PostgreSQL フレキシブルサーバーインスタンスの SSL 使用状況に関するすべての情報を収集することもできます。

SELECT datname as "Database name", usename as "User name", ssl, client_addr, application_name, backend_type
   FROM pg_stat_ssl
   JOIN pg_stat_activity
   ON pg_stat_ssl.pid = pg_stat_activity.pid
   ORDER BY ssl;

テストでは、 openssl コマンドを直接使用することもできます。

openssl s_client -starttls postgres -showcerts -connect <your-postgresql-server-name>:5432

このコマンドは、TLS のバージョンや暗号などの低レベルのプロトコル情報を出力します。オプション -starttls postgresを使用する必要があります。それ以外の場合、このコマンドは SSL が使用されていないことを報告します。このコマンドを使用するには、少なくとも OpenSSL 1.1.1 が必要です。

クライアントから Azure Database for PostgreSQL フレキシブルサーバーインスタンスへの接続保護のために最新の最も安全な TLS バージョンを適用するには、 ssl_min_protocol_version を 1.3 に設定します。この 設定では 、Azure Database for PostgreSQL フレキシブルサーバーインスタンスに接続するクライアントが 、このバージョンのプロトコルを 使用して安全に通信する必要があります。古いクライアントは、このバージョンをサポートしていないため、サーバーと通信できない場合があります。

クライアントで SSL を構成する

既定では、PostgreSQL はサーバー証明書の検証を実行しません。このため、クライアントが知らなくても、サーバー ID のスプーフィング (DNS レコードの変更やサーバー IP アドレスの引き継ぎなど) が可能です。すべての SSL オプションでは、暗号化とキー交換の形式でオーバーヘッドが発生するため、パフォーマンスとセキュリティの間でトレードオフが生じます。

スプーフィングを防ぐには、クライアントで SSL 証明書の検証を使用する必要があります。

クライアントを SSL 用に構成するための接続パラメーターは多数あります。いくつかの重要な要素は次のとおりです。

ssl: SSL を使用して接続します。このプロパティには、それに関連付けられた値は必要ありません。単に存在する場合は、SSL 接続を指定します。将来のバージョンとの互換性を確保するために、 true 値をお勧めします。このモードでは、SSL 接続を確立するときに、クライアントドライバーがサーバーの ID を検証して中間者攻撃を防ぎます。サーバー証明書が信頼された機関によって署名されていること、および接続先のホストが証明書のホスト名と同じであることを確認します。

sslmode: 暗号化が必要で、接続を暗号化できない場合に接続を失敗させる場合は、 sslmode=require設定します。この設定により、サーバーがこのホスト/IP アドレスの SSL 接続を受け入れるように構成され、サーバーがクライアント証明書を認識します。サーバーが SSL 接続を受け入れない場合、またはクライアント証明書が認識されない場合、接続は失敗します。次の表に、この設定の値を示します。

SSL モード	Explanation
`disable`	暗号化は使用されません。
`allow`	暗号化は、サーバー設定で必要または適用される場合に使用されます。
`prefer`	暗号化は、サーバー設定で許可されている場合に使用されます。
`require`	暗号化が使用されます。これにより、サーバーがこのホスト IP アドレスの SSL 接続を受け入れるように構成され、サーバーがクライアント証明書を認識します。
`verify-ca`	暗号化が使用されます。クライアントに格納されている証明書に対してサーバー証明書の署名を確認します。
`verify-full`	暗号化が使用されます。クライアントに格納されている証明書に対して、サーバー証明書の署名とホスト名を確認します。

使用される既定の sslmode モードは、libpq ベースのクライアント (psql など) と JDBC によって異なります。 libpq ベースのクライアントは、既定で prefer。 JDBC クライアントの既定値は verify-full です。

sslcert、 sslkey、および sslrootcert: これらのパラメーターは、クライアント証明書、PKCS-8 クライアントキー、およびルート証明書の既定の場所をオーバーライドできます。既定では、 /defaultdir/postgresql.crt、 /defaultdir/postgresql.pk8、 /defaultdir/root.crtで、 defaultdir は Linux システムで ${user.home}/.postgresql/ され、Windows では %appdata%/postgresql/ されます。

CA は、証明書の発行を担当する機関です。信頼された証明機関は、誰かが自分の言う人であることを確認する権利を持つエンティティです。このモデルを機能させるには、すべての参加者が信頼できる CA のセットに同意する必要があります。すべてのオペレーティングシステムとほとんどの Web ブラウザーには、信頼できる CA のセットが付属しています。

verify-caおよびverify-fullsslmode構成設定を使用することは、証明書のピン留めとも呼ばれます。この場合、PostgreSQL サーバー上のルート CA 証明書は、証明書の署名と、クライアント上の証明書に対するホスト名と一致する必要があります。

PostgreSQL サーバー証明書で CA が変更または期限切れになったときに、クライアントに格納されている証明書を定期的に更新することが必要になる場合があります。 CA をピン留めしているかどうかを確認するには、証明書のピン留めと Azure サービスに関するページを参照してください。

クライアントでの SSL\TLS 構成の詳細については、 PostgreSQL のドキュメントを参照してください。

verify-caおよびverify-fullsslmode構成設定 (つまり、証明書のピン留め) を使用するクライアントの場合、クライアント証明書ストアに 3 つのルート CA 証明書を展開する必要があります。

DigiCert グローバルルート G2 と Microsoft RSA ルート CA 2017 ルート CA 証明書。サービスは Digicert から Microsoft CA に移行されるためです。
従来の互換性のための Digicert グローバルルート CA。

証明書のピン留めシナリオでルート CA 証明書をダウンロードし、アプリケーションクライアントを更新する

証明書のピン留めシナリオでクライアントアプリケーションを更新するには、証明書をダウンロードします。

証明書をクライアント証明書ストアにインポートするには、上記の URI から証明書ファイルをダウンロードした後で、証明書 .crt ファイルを .pem 形式に変換する必要がある場合があります。 OpenSSL ユーティリティを使用して、次のファイル変換を実行できます。

openssl x509 -inform DER -in certificate.crt -out certificate.pem -outform PEM

クライアントアプリケーション証明書ストアを新しいルート CA 証明書で更新する方法については、「アプリケーションクライアントのクライアント TLS 証明書を更新する」を参照してください。

Important

一部の Postgres クライアントライブラリでは、 sslmode=verify-full 設定を使用しているときに、中間証明書でクロス署名されたルート CA 証明書で接続エラーが発生する可能性があります。その結果、代替の信頼パスになります。この場合は、 sslrootcert パラメーターを明示的に指定することをお勧めします。または、 PGSSLROOTCERT 環境変数を、microsoft RSA Root CA 2017 ルート CA 証明書が配置されているローカルパスに設定します(既定値の %APPDATA%\postgresql\root.crt)。

クライアントアプリケーションから Azure Database for PostgreSQL フレキシブルサーバーインスタンスへの接続の損失が発生する - サポートチケットが開かれます。
中間証明書がローテーションされた場合は、クライアント証明書ストアを新しい中間証明書で更新する必要がある場合があります。
中間証明書をピン留めしているかどうかを確認する方法については、「証明書のピン留めと Azure サービス」を参照してください。

証明書のピン留めシナリオを使用したレプリカの読み取り

Microsoft RSA Root CA 2017 へのルート CA 移行では、新しく作成されたレプリカを、先ほど作成したプライマリサーバーよりも新しいルート CA 証明書に配置できます。 verify-caおよびverify-fullsslmode構成設定 (つまり、証明書のピン留め) を使用するクライアントの場合、中断された接続では、次の 3 つのルート CA 証明書を受け入れる必要があります。

現時点では、Azure Database for PostgreSQL では証明書ベースの認証はサポートされていません。

証明書のピン留めシナリオで psql に接続してクライアント証明書をテストする

クライアントから psql コマンドラインを使用して、証明書のピン留めシナリオでサーバーへの接続をテストできます。

$ psql "host=hostname.postgres.database.azure.com port=5432 user=myuser dbname=mydatabase sslmode=verify-full sslcert=client.crt sslkey=client.key sslrootcert=ca.crt"

SSL パラメーターと証明書パラメーターの詳細については、 psql のドキュメントを参照してください。

TLS/SSL 接続をテストする

クライアントアプリケーションから SSL 対応サーバーにアクセスする前に、psql 経由でアクセスできることを確認してください。 SSL 接続を確立した場合、次の例のような出力が表示されます。

psql (14.5)SSL 接続 (プロトコル: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)「help」と入力してください。

sslinfo 拡張機能を読み込み、ssl_is_used()関数を呼び出して、SSL が使用されているかどうかを判断することもできます。接続で SSL が使用されている場合、この関数は t を返します。それ以外の場合は、 fを返します。

暗号スイート

暗号スイートは、一連の暗号アルゴリズムです。 TLS/SSL プロトコルでは、暗号スイートのアルゴリズムを使用してキーを作成し、情報を暗号化します。

暗号スイートは、一見ランダムな情報の長い文字列として表示されますが、その文字列の各セグメントには重要な情報が含まれています。一般に、このデータ文字列にはいくつかの重要なコンポーネントが含まれています。

プロトコル (つまり、TLS 1.2 または TLS 1.3)
キー交換または契約アルゴリズム
デジタル署名 (認証) アルゴリズム
一括暗号化アルゴリズム
メッセージ認証コードアルゴリズム (MAC)

TLS/SSL のバージョンが異なると、異なる暗号スイートがサポートされます。 TLS 1.2 暗号スイートは TLS 1.3 接続とネゴシエートできません。その逆も同様です。

現時点では、Azure Database for PostgreSQL では、 HIGH:!aNULL カテゴリに分類される TLS 1.2 プロトコルバージョンを使用した多くの暗号スイートがサポートされています。

Troubleshoot

このトラブルシューティングセクションのガイダンスを使用して、一般的な TLS/SSL の問題をすばやく特定して解決します。まず、問題を再現し、診断データ (クライアント側のエラーメッセージ、psql 出力、OpenSSL s_client出力、およびサーバーログ) を収集してから、サーバーパラメーター (require_secure_transport、ssl_min_protocol_version、ssl_max_protocol_version)、証明書チェーン、およびクライアント sslmode/sslrootcert 設定を確認して、プロトコルバージョン、暗号スイート、または不足している証明書またはローテーションされた証明書の不一致を特定します。

TLS/SSL 接続エラー

TLS/SSL プロトコルバージョンの互換性をトラブルシューティングする最初の手順は、ユーザーがクライアントからの TLS 暗号化の下で Azure Database for PostgreSQL フレキシブルサーバーインスタンスにアクセスしようとしたときに表示されるエラーメッセージを特定することです。アプリケーションとプラットフォームによっては、エラーメッセージが異なる場合があります。多くの場合、基になる問題を示しています。
TLS/SSL プロトコルのバージョンの互換性を確認するには、データベースサーバーとアプリケーションクライアントの TLS/SSL 構成を調べて、互換性のあるバージョンと暗号スイートがサポートされていることを確認します。
データベースサーバーとクライアントの TLS/SSL バージョンと暗号スイートの間の不一致やギャップを分析します。特定のオプションを有効または無効にするか、ソフトウェアをアップグレードまたはダウングレードするか、証明書またはキーを変更して解決してみてください。たとえば、セキュリティと互換性の要件に応じて、サーバーまたはクライアントで特定の TLS/SSL バージョンを有効または無効にする必要がある場合があります。たとえば、セキュリティで保護されておらず非推奨と見なされる TLS 1.0 と TLS 1.1 を無効にし、より安全でモダンな TLS 1.2 と TLS 1.3 を有効にする必要がある場合があります。
Microsoft RSA Root CA 2017 で発行された最新の証明書は、Digicert Global Root G2 CA によってクロス署名されたチェーン内の中間証明書を持っています。一部の Postgres クライアントライブラリでは、 sslmode=verify-full または sslmode=verify-ca 設定を使用しているときに、中間証明書でクロス署名されたルート CA 証明書で接続エラーが発生する可能性があります。その結果、代替の信頼パスになります。

これらの問題を回避するには、3 つの必要な証明書をすべてクライアント証明書ストアに追加するか、 sslrootcert パラメーターを明示的に指定します。または、 PGSSLROOTCERT 環境変数を、Microsoft RSA ルート CA 2017 ルート CA 証明書が配置されているローカルパスに設定します(既定値の %APPDATA%\postgresql\root.crtから)。

証明書のピン留めの問題

注

クライアントアプリケーション接続文字列で sslmode=verify-full または sslmode=verify-ca 設定を使用していない場合、証明書のローテーションは影響を受けません。そのため、このセクションの手順に従う必要はありません。

アプリケーションで証明書のピン留めを使用しているかどうかを確認します。
信頼されたルートストアにある証明書の一覧を生成する
1. たとえば、 Java キーストアで信頼できる証明書の一覧をプログラムで取得できます。
2. たとえば、 cacerts java キーストアを調べて、必要な証明書が既に含まれているかどうかを確認できます。
個々の中間証明書または個々の PostgreSQL サーバー証明書がある場合は、証明書のピン留めを使用しています。
証明書のピン留めを削除するには、信頼されたルートストアからすべての証明書を削除し、新しい証明書を追加します。
1. 更新された証明書は、Microsoft の公式リポジトリ (Azure 証明機関の詳細) からダウンロードできます。
  1. 現在のチェーン:
    1. DigiCert グローバルルート G2
    2. Microsoft Azure RSA TLS Issuing CA 03 / 04 / 07 / 08
  2. 新しいチェーン:
    1. DigiCert グローバルルート G2
    2. Microsoft TLS RSA Root G2
    3. Microsoft TLS G2 RSA CA OCSP 02 / 04 / 06 / 08 / 10 / 12 / 14 / 16

これらの手順を実行しても問題が発生する場合は、 Microsoft サポートにお問い合わせください。タイトルに ICA Rotation 2026 を含めます。

フィードバック

このページはお役に立ちましたか?

Last updated on 2025-11-01