1. セキュリティ・ガイド
  2. ネットワーク上のデータの保護
  3. Transport Layer Security暗号化の構成

21 Transport Layer Security暗号化の構成

Transport Layer Security (TLS) (旧称Secure Sockets Layer (SSL))により、Webアプリケーションとサーバー間のインターネットでのデータの暗号化が容易になります。

親トピック: ネットワーク上のデータの保護

21.1 トランスポート・レイヤー・セキュリティ・バージョン1.3への移行

Transport Layer Security (TLS)のバージョン1.3では、以前のバージョンよりもはるかに強力なセキュリティが提供されていますが、環境がこのTLSバージョンを正しく使用していることを確認するために、特定のタスクを実行する必要があります。

親トピック: Transport Layer Security暗号化の構成

21.1.1 トランスポート・レイヤー・セキュリティ・バージョン1.3をサポートするために必要な構成ファイル変更

Transport Layer Security (TLS)バージョン1.3の拡張は、現在のTLS構成に影響を与えます。

次のTLS 1.2機能はTLS 1.3では使用できません。このトピックでは、これらの機能の削除によって影響を受けるTLS構成に対処する方法について説明します。

  • キー交換用の静的RSAハンドシェイクはサポートされなくなりました。ただし、デジタル署名のユースケースはTLS 1.3でも引き続きサポートされています。

    この変更に対処するには: 構成ファイルで、TLS暗号スイートへの参照を空白のままにします。これにより、自動検出で最新バージョンに設定できます。または、SSL_CIPHER_SUITESパラメータを使用して構成ファイルでTLS1.3暗号スイートを明示的に呼び出すこともできます。CBCモードの暗号はサポートされません。

  • Oracle Database 23c以降、CBCモードの暗号はサポートされなくなりました。

    この変更に対処するには: 構成ファイルからCBCモードの暗号化を削除します。

  • 暗号スイートAES-CBC、RC4、SHA1、MD5、DES、3DESはサポートされなくなりました。

    この変更に対処するには、構成ファイルからこれらの暗号スイートへの参照を削除します。

関連トピック

親トピック: トランスポート・レイヤー・セキュリティ・バージョン1.3への移行

21.1.2 トランスポート・レイヤー・セキュリティ・バージョン1.3の新しい機能への対処

Transport Layer Security (TLS)バージョン1.3は、以前のバージョンのTLSよりも大幅に改善されています。

  • TLS 1.3では、Perfect Forward Secrecy (PFS)がデフォルトでサポートされています。TLS 1.2でPFSを有効にするには、RSA鍵交換の使用を中止し、TLS 1.2でエフェメラル楕円曲線Diffie-Hellman暗号に切り替えます。

    この変更に対処するには: 構成ファイルで、TLS暗号スイートへの参照を空白のままにします。これにより、自動検出で最新バージョンに設定できます。または、SSL_CIPHER_SUITESパラメータを使用して構成ファイルでTLS1.3暗号スイートを明示的に呼び出すこともできます。CBCモードの暗号はサポートされません。

  • より高速なTLSハンドシェイク、より強力な暗号スイート。

    この変更に対処するには: TLS 1.3の採用時の暗黙的なメリットを考慮して、変更する必要はありません。

関連トピック

親トピック: トランスポート・レイヤー・セキュリティ・バージョン1.3への移行

21.2 Transport Layer SecurityおよびSecure Sockets Layer

Transport Layer Security (TLS)は、コンピュータ・ネットワークの保護に使用される暗号化プロトコルです。

親トピック: Transport Layer Security暗号化の構成

21.2.1 Transport Layer SecurityとSecure Sockets Layerの違い

Transport Layer Security (TLS)暗号化プロトコルは、旧Secure Sockets Layer (SSL)プロトコルの上に構築されました。

SSLは最初にNetscape社によって開発されましたが、Internet Engineering Task Force (IETF)がその開発を引き継ぎ、名前をTransport Layer Security (TLS)に変更しました。TLSはIETF標準です。

Oracle DatabaseではTLSが実装されているため、Oracle Databaseセキュリティ・ガイドでは、Secure Sockets LayerおよびSSLのかわりに、Transport Layer SecurityおよびTLSという用語が使用されています。ただし、Oracle Databaseライブラリ内の他のドキュメントでは、以前のSecure Socket LayerおよびSSLという用語が引き続き使用されている場合があります。これらのプロトコルの使用方法または構成方法に違いがある場合、Oracle Databaseセキュリティ・ガイドでは、記述内容がSSLに該当するか、TLSに該当するかを明記します。

Oracle Databaseソフトウェアでは、古い用語の一部が引き続き使用されています。たとえば、netmgrツールでは、引き続きSecure Socket LayerおよびSSLの用語が使用されています。SSL_SERVER_CERT_DNなどの多くのSSLパラメータでは、古い用語が使用されています。暗号スイートの名前とエラー・メッセージ内の言い回しにも、SSL用語が使用されています。ただし、これらのすべての機能は、Transport Layer Securityと連携して、適用されます。

親トピック: Transport Layer SecurityおよびSecure Sockets Layer

21.2.2 マルチテナント環境でのTransport Layer Securityの使用

Transport Layer Security (TLS)はアプリケーション・コンテナに使用できます。

アプリケーション・コンテナにTransport Layer Security (TLS)を使用する場合は、各PDBでそれ固有のウォレット、およびTLS認証用のそれ固有の証明書を使用できることを確認する必要があります。
  1. ウォレットを使用するPDBに接続します。
  2. ウォレットをwalletディレクトリのサブディレクトリに置きます。サブディレクトリの名前は、ウォレットを使用するPDBのGUIDです。
    各PDBには個別のsqlnet.oraファイルがないため、これを行う必要があります。たとえば、sqlnet.oraのWALLET_LOCATIONパラメータが次のように設定されているとします。
    (SOURCE=(METHOD=FILE)(METHOD_DATA=
   (DIRECTORY=/home/oracle/wallet)))

    各PDBのウォレットを/home/oracle/wallet/PDB_GUIDディレクトリに置きます。既存のPDBおよびそのGUIDを確認するには、DBA_PDBSデータ・ディクショナリ・ビューを問い合せます。

    WALLET_LOCATIONパラメータが指定されていない場合、デフォルトのウォレット・パスのリーフ・サブディレクトリにPDBウォレットを置く必要があります。サブディレクトリの名前はPDBのGUID、リーフ・サブディレクトリの名前はtlsです。例: 

    $ORACLE_BASE/admin/db_unique_name/PDB_GUID/tls

    ノート:

    パラメータWALLET_LOCATIONは、Oracle DatabaseサーバーのOracle Database 23cでの使用は非推奨です。Oracle Databaseクライアントでの使用は非推奨ではありません。

    Oracle Databaseサーバーには、WALLET_LOCATIONを使用するかわりにWALLET_ROOTシステム・パラメータを使用することをお薦めします。

    または、ORACLE_BASE環境変数が設定されていない場合は、Oracleホームを使用できます。 

    $ORACLE_HOME/admin/db_unique_name/PDB_GUID/tls

    これらのデフォルトの場所は、LDAPの認証用にウォレットを特定するためにOracle Enterprise User Securityによって使用されるデフォルトに対応します。

    PDBで個別のサーバー証明書を使用できるようにするには、$WALLET_LOCATION/PDB_GUID/tlsディレクトリの下にサブディレクトリを作成し、そのサーバー証明書を含むウォレットをこのサブディレクトリにコピーします。

  3. PDBをクローズしてから再度オープンします。
    ALTER PLUGGABLE DATABASE pdb_name CLOSE IMMEDIATE;
ALTER PLUGGABLE DATABASE pdb_name OPEN;

親トピック: Transport Layer SecurityおよびSecure Sockets Layer

21.3 Oracle環境におけるTransport Layer Securityの機能: TLSハンドシェイク

Transport Layer Securityによるネットワーク接続を開始する場合、クライアントとサーバーは、認証を行う前にTLSハンドシェイクを実行します。

ハンドシェイク・プロセスは次のようになります。

  1. クライアントとサーバーは、どの暗号スイートを使用するかを設定します。これには、データ転送に使用する暗号化アルゴリズムも含まれます。

  2. サーバーは証明書をクライアントに送信し、クライアントは、サーバーの証明書が信頼できるCAによって署名されていることを検証します。このステップにより、サーバーの身元が検証されます。

  3. 同様に、クライアント認証が必要な場合は、クライアントが自分自身の証明書をサーバーに送信し、サーバーは、クライアントの証明書が信頼できるCAによって署名されているかどうかを検証します。

  4. クライアントとサーバーが、公開キー暗号化を使用してキー情報を交換します。この情報に基づき、双方でセッション・キーが生成されます。キーは少なくとも二者(通常はクライアントとサーバー)によって共有され、単一の通信セッション中のデータ暗号化に使用されます。セッション・キーは通常、ネットワーク・トラフィックを暗号化するために使用されます。クライアントとサーバーはセッションの開始時にセッション・キーをネゴシエーションすることができ、そのキーはそのセッションの関係者間のすべてのネットワーク・トラフィックを暗号化するために使用されます。クライアントとサーバーが新しいセッションで再び通信する場合は、新しいセッション・キーをネゴシエーションします。クライアントとサーバーとの間の以降の通信はすべて、このセッション・キーと、ネゴシエーションにより決定した暗号スイートを使用して、暗号化または復号化されます。

認証プロセスは次のとおりです。

  1. クライアントで、ユーザーがTLSを使用してサーバーへのOracle Net接続を開始します。

  2. TLSは、クライアントとサーバー間のハンドシェイクを実行します。

  3. ハンドシェイクが成功すると、サーバーは、そのデータベースにアクセスするために必要な認可をユーザーが所有していることを検証します。

関連トピック

親トピック: Transport Layer Security暗号化の構成

21.4 Oracle環境における公開キー・インフラストラクチャ

公開キー・インフラストラクチャ(PKI)は、組織全体のセキュリティ基盤を提供するネットワーク・コンポーネントの基質であり、信頼アサーションに基づいています。

親トピック: Transport Layer Security暗号化の構成

21.4.1 公開キーの暗号化について

従来の秘密キーまたは対称キーの暗号化では、安全な通信を確立する目的で2者以上が共有する1つの秘密キーが必要です。

このキーは、ユーザー間で送信される保護メッセージの暗号化および復号化に使用されるため、各ユーザーへは事前に安全な方法でキーを配布する必要があります。この方法における問題点は、キーを安全に転送し、格納することが困難なことです。

公開キーの暗号化による公開キー/秘密キーのペアおよびキー配布のための安全な方法を採用することで、この問題は解決します。対応する秘密キーの所有者のみが復号化できるメッセージは、自由に使用できる公開キーによって暗号化できます。秘密キーは、その他のセキュリティ資格証明とともに、ウォレットと呼ばれる暗号化されたコンテナに、安全に格納されます。

公開キーのアルゴリズムでは、メッセージの秘密は保証されますが、安全な通信は必ずしも保証されません。その理由は、通信者間の識別が検証されないためです。安全な通信を確立するには、メッセージの暗号化に使用される公開キーが相手の受信者に実際に属していることを確認することが重要です。そうしないと、第三者が通信を傍受し、公開キーのリクエストに割り込み、正当なキーを独自の公開キーに置き換えることが可能になります(第三者攻撃)。

この攻撃を回避するには、公開キーの所有者の確認(認証と呼ばれるプロセス)が必要です。認証は、通信する双方の委託するサード・パーティの認証局(CA)によって行われます。

CAは、エンティティの名前、公開キーおよび他のセキュリティ資格証明を含む公開キー証明書を発行します。通常、このような資格証明には、CA名、CAの署名および証明書の有効日(開始日、終了日)が含まれています。

CAでは独自の秘密キーを使用してメッセージを暗号化します。一方、そのメッセージの復号化には公開キーが使用されるため、メッセージがCAによって暗号化されたものであるかどうかが確認されます。CA公開キーは広く一般に知られているため、アクセスするたびに認証する必要はありません。このようなCA公開キーはウォレットに格納されます。

親トピック: Oracle環境における公開キー・インフラストラクチャ

21.4.2 Oracle環境における公開キー・インフラストラクチャ・コンポーネント

Oracle環境の公開キー・インフラストラクチャ(PKI)のコンポーネントには、認証局、証明書、証明書失効リストおよびウォレットなどがあります。

  • 認証局
    認証局(CA)は、ユーザー、データベース、管理者、クライアント、サーバーなどのエンティティの識別情報を証明する、信頼できるサード・パーティです。
  • 証明書
    証明書は、エンティティの公開キーが、信頼できる認証局(CA)によって署名されたときに作成されます。
  • 証明書失効リスト
    公開キー・ペアをユーザーIDにバインドする証明書にCAが署名すると、証明書は指定された期間有効になります。
  • ウォレット
    ウォレットとは、認証および署名資格証明(Transport Layer Security (TLS)で必要な秘密キー、証明書、信頼できる証明書など)が格納されるコンテナです。

親トピック: Oracle環境における公開キー・インフラストラクチャ

21.4.2.1 認証局

認証局(CA)は、ユーザー、データベース、管理者、クライアント、サーバーなどのエンティティの識別情報を証明する、信頼できるサード・パーティです。

エンティティが証明書を要求すると、CAはその識別情報を検証し、CAの秘密キーを使用して署名した証明書を発行します。

CAごとに、証明書の発行時の識別情報要件が異なる可能性があります。CAの中には、要求者の識別情報をドライバのライセンスを使用して確認したり、要求者の指紋で識別情報を確認したり、証明書リクエスト・フォームが認証されていることを必要とするものがあります。

CAは、公開キーが含まれている独自の証明書を発行します。各ネットワーク・エンティティには、信頼できるCA証明書のリストがあります。通信する前に、ネットワーク・エンティティは証明書を交換し、相互の証明書がそれぞれの信頼できるCA証明書リストのいずれかのCAによって署名されていることを確認します。

ネットワーク・エンティティは、同じCAから、または異なるCAから証明書を取得できます。

21.4.2.2 証明書

証明書は、エンティティの公開キーが、信頼できる認証局(CA)によって署名されたときに作成されます。

この証明書は、そのエンティティの識別情報が正しいこと、および公開キーがそのエンティティに実際に属していることを保証します。

証明書には、エンティティの名前、公開キー、有効期限、さらにシリアル番号および証明連鎖情報が含まれています。(証明書チェーンは、エンド・ユーザーまたはサブスクライバの証明書とその認証局の証明書を含む、順序付けられた証明書のリストです。)また、証明書に関連付けられた権限に関する情報が含まれている場合もあります。

ネットワーク・エンティティが証明書を受信すると、それが信頼できる証明書、つまり信頼できる認証局によって発行および署名された証明書であるか検証します。証明書は、期限切れになるか失効するまで有効です。

21.4.2.3 証明書失効リスト

公開キー・ペアをユーザーIDにバインドする証明書にCAが署名すると、証明書は指定された期間有効になります。

ただし、ユーザー名の変更や秘密キーの漏えいなどの特定のイベントが発生した場合は、有効期間が終了する前に証明書が無効になることがあります。この場合は、CAによって証明書が失効され、そのシリアル番号が証明書失効リスト(CRL)に追加されます。CAは、特定の公開キーが、関連付けられているユーザーIDの確認に使用できなくなると、定期的にCRLを発行してユーザーに警告します。

サーバーまたはクライアントはOracle環境でユーザー証明書を受信すると、その有効期限、署名および失効ステータスをチェックして証明書を検証できます。証明書失効ステータスは、発行されたCRLに照らして検証することでチェックされます。証明書失効ステータス・チェックが有効になっている場合、サーバーはこの機能の構成方法に応じて適切なCRLを検索します。サーバーは、次の場所で(この順番で) CRLを検索します。

  1. ローカル・ファイル・システム

  2. Oracle Internet Directory

  3. CRL配布ポイント(CRL DP)。証明書が発行されたときの、CRL Distribution Point (CRL DP) X.509バージョン3の証明書拡張で指定されている場所。CRL DPは、X.509バージョン3証明書標準で指定されるオプションの拡張子であり、証明書の失効情報が格納される区分CRLの位置を示します。通常、この拡張子の値はURLの形式です。CRL DPによって、1つの認証局ドメイン内の失効情報を複数のCRLにポストできます。CRL DPによって、失効情報はより管理しやすい部分に細分化され、CRLが膨大に増加するのが回避されるため、パフォーマンスが向上します。たとえば、CRL DPを証明書に指定し、その証明書の失効情報をダウンロードできる、Webサーバー上のファイルを指すようにできます。

ノート:

他のOracle製品でCRLを使用するには、その製品のドキュメントを参照してください。CRLによる証明書の検証の実装は、Oracle Database 12cリリース1 (12.1)以降のSSLアダプタでのみ使用できます。

21.4.2.4 ウォレット

ウォレットとは、認証および署名資格証明(Transport Layer Security (TLS)で必要な秘密キー、証明書、信頼できる証明書など)が格納されるコンテナです。

システムの証明書ストアにCA証明書があるクライアントでウォレットなしの一方向TLS構成を使用する場合、ウォレットはオプションです。

Oracle環境では、TLS通信を行うどのエンティティにも、X.509バージョン3の証明書、秘密キーおよび信頼できる証明書のリストが必要です。ただし、Diffie-Hellmanは例外です。

セキュリティ管理者は、orapkiユーティリティを使用してサーバーのセキュリティ資格証明を管理します。ウォレットの所有者は、クライアントのセキュリティ資格証明の管理に使用します。次の操作を実行できます。

  • 公開キーと秘密キーのペアの生成および証明書リクエストの作成

  • 秘密キーと一致するユーザー証明書の格納

  • 信頼できる証明書の構成

21.5 Transport Layer Security暗号化と認証方式の併用

TLSをデータベースのユーザー名とパスワード、RADIUSおよびKerberosと同時に使用するようにOracle Databaseを構成できます。

親トピック: Transport Layer Security暗号化の構成

21.5.1 アーキテクチャ: Oracle DatabaseとTransport Layer Security

Oracle DatabaseとTLSとの連携のアーキテクチャを理解することが重要です。

Transport Layer SecurityアーキテクチャのOracle Databaseの実装を示す図23-4では、Oracle DatabaseがTLSの上位のセッション・レイヤーで動作し、トランスポート・レイヤーでTCP/IPを使用していることを示しています。セッション・レイヤーは、プレゼンテーション・レイヤー・エンティティが必要とするサービスを提供するネットワーク・レイヤーであり、プレゼンテーション・レイヤー・エンティティがダイアログの編成と同期およびデータ交換の管理を行えるようにします。このレイヤーは、クライアントとサーバー間でネットワーク・セッションを確立、管理および終了する。トランスポート・レイヤーは、データ・フロー制御とエラー・リカバリ方式を通じてエンドツーエンドの信頼性を維持するネットワーキング・レイヤーです。

このように機能が分離されているため、TLSを他のサポートされているプロトコルと同時に利用できます。

関連トピック

親トピック: Transport Layer Security暗号化と認証方式の併用

21.5.2 Transport Layer Securityと他の認証方式の併用

Transport Layer Securityは、Oracle Databaseでサポートされているその他の認証方式との併用が可能です。

図21-1に、Transport Layer Securityが別の認証方式と併用されている構成を示します。

図21-1 Transport Layer Securityと他の認証方式との関係

図21-1の説明が続きます
「図21-1 Transport Layer Securityと他の認証方式との関係」の説明

この例では、最初のハンドシェイク(サーバー認証)を確立するためにTransport Layer Securityが使用され、クライアントの認証に別の認証方式が使用されています。このプロセスは、次のとおりです。

  1. クライアントがOracleデータベース・サーバーに接続しようとします。

  2. Transport Layer Securityによってハンドシェイクが実行され、その間にサーバーがクライアントに対して自己認証を行い、クライアントとサーバーの両方が使用する暗号スイートを設定します。

  3. Transport Layer Securityハンドシェイクが正常に完了すると、ユーザーはデータベースにアクセスしようとします。

  4. Oracleデータベース・サーバーは、TLS以外の認証方法を使用する認証サーバーでユーザーを認証します。たとえば、パスワード、Kerberos、RADIUS、クラウド・アイデンティティ・トークン(Oracle Cloud Infrastructure (OCI) Identity and Access Management (IAM)、Microsoft Azure AD)などの認証方法です。

  5. その認証方法による検証が完了すると、Oracleデータベース・サーバーによってアクセス権と認可がユーザーに付与され、ユーザーはTLSを使用してデータベースに安全にアクセスできるようになります。

関連トピック

親トピック: Transport Layer Security暗号化と認証方式の併用

21.6 Transport Layer Securityとファイアウォール

Oracle Databaseは、アプリケーション・プロキシベースのファイアウォールとステートフル・パケット・インスペクション・ファイアウォールの2つをサポートしています。

ファイアウォールは次のとおりです。

  • アプリケーション・プロキシベースのファイアウォール: Network Associates GauntletやAxent Raptorなど。

  • ステートフル・パケット・インスペクション・ファイアウォール: Check Point Firewall-1やCisco PIX Firewallなど。

TLSを有効にした場合、ステートフル・インスペクション・ファイアウォールは暗号化されたパケットを復号化しないため、アプリケーション・プロキシ・ファイアウォールと同じように動作します。

ファイアウォールは暗号化されたトラフィックを検査しません。ファイアウォールは、イントラネット・サーバーのTLSポート宛てのデータを検出すると、アクセス・ルールに基づいてターゲットIPアドレスを確認し、許可されたTLSポートに対してはTLSパケットを通過させ、他のすべてのパケットは拒否します。

親トピック: Transport Layer Security暗号化の構成

21.7 Transport Layer Security使用時の問題

他のOracle製品との通信や、サポート対象の認証方式および暗号化方式のタイプといった、TLSの使用に関する問題に注意する必要があります。

TLSを使用する場合は、次のことを考慮してください。

  • TLSを使用すると、Oracle Internet Directoryなどの他のOracle製品との安全な通信が可能になります。

  • TLSは認証と暗号化を提供するため、暗号化のみを提供するネイティブ・ネットワーク暗号化よりも安全です。ネイティブ・ネットワーク暗号化は、TLSが実行する認証をスキップするため、ユーザー・アクセスには若干高速になります。

ノート:

TLS暗号化を構成する場合は、非TLS暗号化を無効にする必要があります。

関連トピック

親トピック: Transport Layer Security暗号化の構成

21.8 Transport Layer Securityのパラメータ

Oracleには、Transport Layer Securityを制御するパラメータが用意されています。

親トピック: Transport Layer Security暗号化の構成

21.8.1 Transport Layer Securityのパラメータの構成方法

Transport Layer Security (TLS)のパラメータの構成方法は2つあります。

  • 静的: Oracleでは、sqlnet.oraおよびlistener.oraファイルのSSL_VERSIONおよびSSL_CIPHER_SUITESパラメータの値を指定しないことをお薦めします。これらの値を省略すると、(使用可能な最上位バージョンが選択されていることが保証される) TLSバージョンおよび関連する暗号スイートの自動検出が容易になります。Oracle Databaseでは、TLS_AES_256_GCM_SHA384暗号がデフォルトとして使用されます。

    TLS 1.3を明示的に強制する環境の場合、パラメータ値は次のとおりです。

    • SSL_VERSION = TLSv1.3
    • SSL_CIPHER_SUITES = (TLS_AES_256_GCM_SHA384 ,TLS_AES_128_GCM_SHA256, TLS_AES_128_CCM_SHA256, TLS_CHACHA20_POLY1305_SHA256)

    FIPS準拠の暗号は次のとおりです。

    • TLS_AES_256_GCM_SHA384
    • TLS_AES_128_GCM_SHA256
    • TLS_AES_128_CCM_SHA256

  • 動的: TNS接続文字列で使用されるTLSパラメータであり、sqlnet.oraの同じパラメータまたは類似のパラメータよりも優先されます。

親トピック: Transport Layer Securityのパラメータ

21.8.2 Transport Layer Securityの暗号スイートと認証パラメータ

Oracleは、Transport Layer Security (TLS)に応じた各種の暗号スイートと認証パラメータを用意しています。

次の表に、TLSの暗号スイートと認証の設定に使用できるパラメータを示します。

表21-1 TLSのパラメータ

パラメータ 説明

AUTHENTICATION

1つ以上の認証サービスを有効にする動的パラメータ

SQLNET.AUTHENTICATION_SERVICES

1つ以上の認証サービスを有効にする静的パラメータ

SSL_ALLOW_WEAK_DN_MATCH

サーバー側の証明書の検証中に、以前の弱い識別名(DN)の照合動作を許可します

SSL_CLIENT_AUTHENTICATION

TLSを使用してクライアントを認証するかどうかを指定します

SSL_CIPHER_SUITES

TLSで使用される暗号化とデータ整合性の組合せを制御する動的および静的パラメータ

SSL_SERVER_CERT_DN

データベース・サーバーの識別名(DN)を指定します

SSL_SERVER_DN_MATCH

識別名(DN)一致によるサーバー側証明書の検証を強制します

SSL_VERSION

Oracle Databaseが接続のために使用する有効なTLSバージョンをリストします

関連トピック

親トピック: Transport Layer Securityのパラメータ

21.8.3 Oracleウォレット・ロケーション

セキュリティ資格証明をプロセス領域にロードするためにOracleウォレットにアクセスする必要があるアプリケーションに対して、ウォレット・ロケーション・パラメータを指定する必要があります。

表21-2に、ウォレット・ロケーションを指定する必要がある構成ファイルを示します。

  • sqlnet.ora

  • listener.ora

表21-2 ウォレット・ロケーション・パラメータ

静的な構成 動的な構成 
WALLET_LOCATION =
(SOURCE=
  (METHOD=File)
  (METHOD_DATA=
     (DIRECTORY=your_wallet_dir)
      )

)

 
WALLET_LOCATION=your_wallet_dir

デフォルトのウォレット・ロケーションはORACLE_HOMEディレクトリです。

ノート:

パラメータWALLET_LOCATIONは、Oracle DatabaseサーバーのOracle Database 23cでの使用は非推奨です。Oracle Databaseクライアントでの使用は非推奨ではありません。

Oracle Databaseサーバーには、WALLET_LOCATIONを使用するかわりにWALLET_ROOTシステム・パラメータを使用することをお薦めします。

親トピック: Transport Layer Securityのパラメータ

21.8.4 Oracleウォレットの検索順序

Oracle Databaseは、Transport Layer Security (TLS)環境でサーバーのウォレットを検索するための複数のルートを用意しています。

Oracle Databaseサーバーは、次の場所を次の順序で検索して、ウォレットを取得します。

  1. init.oraファイルのWALLET_ROOT
  2. sqlnet.oraファイルのWALLET_LOCATION
  3. $TNS_ADMIN環境変数設定
  4. デフォルトのウォレット・ロケーション:
    • Linux: /etc/ORACLE/WALLETS/user_name
    • Windows: C:\Users\user_name\\ORACLE\WALLETS

TNSリスナーは、次の順序でこれらの場所を検索してウォレット・ロケーションを取得します。

  1. listener.oraファイルのWALLET_LOCATION
  2. $TNS_ADMIN環境変数設定
  3. デフォルトのウォレット・ロケーション:
    • Linux: /etc/ORACLE/WALLETS/user_name
    • Windows: C:\Users\user_name\\ORACLE\WALLETS

Oracle Databaseクライアントは、次の場所を次の順序で検索して、ウォレットを取得します。

  1. 接続文字列
  2. sqlnet.oraファイルのWALLET_LOCATION
  3. $TNS_ADMIN環境変数設定
  4. デフォルトのウォレット・ロケーション:
    • Linux: /etc/ORACLE/WALLETS/user_name
    • Windows: C:\Users\user_name\\ORACLE\WALLETS
  5. 証明書ストアの場所にあるシステム・ウォレット。デフォルトの証明書ストアの場所はプラットフォームによって異なります。Windowsの場合は、Microsoft Windows用のMicrosoft証明書ストアにあります。Linuxの場合、その場所は次のとおりです。
    • RHEL/Oracle Linux: /etc/pki/tls/cert.pem
    • Debian/Ubuntu/Gentoo: /etc/ssl/certs/ca-certificates.crt
    • Fedora/RHEL: /etc/pki/tls/certs/ca-bundle.crt
    • OpenSUSE: /etc/ssl/ca-bundle.pem
    • OpenELEC: /etc/pki/tls/cacert.pem
    • CentOS/RHEL7: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
    • Alpine Linux: /etc/ssl/cert.pem

親トピック: Transport Layer Securityのパラメータ

21.9 クライアント・ウォレットを使用しないTransport Layer Security接続

データベース・サーバーに対して共通のルート証明書を使用するTransport Layer Security (TLS)接続には、クライアント・ウォレットは必要ありません。

親トピック: Transport Layer Security暗号化の構成

21.9.1 クライアント・ウォレットを使用しないTransport Layer Security接続について

環境が特定の要件を満たしている場合、クライアント・ウォレットを使用しないTransport Layer Security (TLS)接続を構成できます。

環境が次の要件を満たしている場合は、クライアント・ウォレットを使用しないTLS接続を使用することを検討してください。

  • クライアント証明書は、データベースへのユーザー認証の手段として使用されません。TLS接続を確立するために必要なのはサーバー証明書のみです。
  • サーバー証明書は、システムのデフォルトの証明書ストアに使用可能な証明書(共通のルート証明書)を持つ認証局(CA)によって発行されました。
  • Oracle Databaseサーバーとリスナーは、クライアント認証が無効な状態で構成されます。(SSL_CLIENT_AUTHENTICATION=FALSEを設定)。

データベース・サーバーに対するルート証明書がローカルのシステム証明書ストア内にすでに存在していれば、これが最も一般的なタイプの構成になります。この構成は、クラウド・データベースとオンプレミス・データベースの両方に使用できます。この構成により、クライアントで独自のウォレットを構成することなく、サーバー証明書を検証できます。

次のことに注意してください。

  • CおよびInstant Clientのデータベース・ドライバ(したがってSQL*Plus)の場合、ウォレットレス機能はすべてのプラットフォームで使用できます。
  • JDBCシン・ドライバの場合、ウォレットレス機能はすべてのプラットフォームで使用できます。

関連トピック

親トピック: クライアント・ウォレットを使用しないTransport Layer Security接続

21.9.2 クライアント・ウォレットを使用しないTransport Layer Security接続の構成

クライアント・ウォレットを使用しないTransport Layer Security (TLS)を構成する前に、データベースでクライアント認証が必要ないことを確認する必要があります。

CおよびInstant Clientのデータベース・ドライバ(およびSQL*Plus)の場合、ウォレットレス機能はMicrosoft WindowsおよびLinuxのx64でのみ使用できます。JDBCシン・ドライバの場合、ウォレットレス機能はすべてのプラットフォームで使用できます。
  1. Oracleデータベースが存在するサーバーにログインします。
  2. sqlnet.oraファイルのSSL_CLIENT_AUTHENTICATIONの設定を確認します。

    SSL_CLIENT_AUTHENTICATIONのデフォルトはTRUEであり、mTLS (クライアント・ウォレット内のクライアント証明書を必要とする相互TLS)が必要になります次の設定があります。

    • OFF/FALSEは一方向TLSを有効にするmTLSを無効にします。
    • ON/TRUEは一方向TLSを無効にするmTLSを有効にします。
    • OPTIONALを使用すると、サーバーは次のように動作できます。
      • クライアントが証明書を送信すると、接続はクライアントの認証後にmTLS接続として完了します。
      • クライアントが証明書を送信していないと、接続は一方向TLS接続として完了します。

    デフォルトでは、sqlnet.oraファイルは、$ORACLE_HOME/dbsディレクトリ、またはTNS_ADMIN環境変数によって設定されている場所にあります。

  3. WALLET_ROOTシステム・パラメータまたはWALLET_LOCATIONのsqlnet.oraパラメータで定義されたデフォルトの場所にサーバー・ウォレットが存在することを確認します。

    ノート:

    パラメータWALLET_LOCATIONは、Oracle DatabaseサーバーのOracle Database 23cでの使用は非推奨です。Oracle Databaseクライアントでの使用は非推奨ではありません。

    Oracle Databaseサーバーには、WALLET_LOCATIONを使用するかわりにWALLET_ROOTシステム・パラメータを使用することをお薦めします。

  4. listener.oraファイルを確認して、TLSが指定されていることを確認します。
    LISTENER = (ADDRESS=(PROTOCOL=tcps)(HOST=)(PORT=port))

    listener.oraファイルは、サーバーのものと同様に、SSL_CLIENT_AUTHENTICATIONパラメータをFALSEまたはOPTIONALに設定する必要があります。

  5. リスナー・ウォレットがデフォルトの場所またはWALLET_LOCATIONのsqlnet.oraパラメータにも存在することを確認します。
    新しいクライアント接続を作成する場合は、次の設定が含まれるようにlistener.oraファイルを編集します。 
    ADDRESS=(PROTOCOL=tcps)

    デフォルトでは、listener.oraは$ORACLE_HOME/network/adminディレクトリに配置されます。

  6. Oracleデータベースのクライアントにログインします。
  7. クライアントのsqlnet.oraファイルとtnsnames.oraファイルを変更します。
    • sqlnet.oraファイルのSQLNET.SSL_CLIENT_AUTHENTICATIONの設定を編集します。

      SQLNET.SSL_CLIENT_AUTHENTICATION=FALSEを設定します(デフォルトはTRUEであるため)。FALSEにした場合は、クライアントで、TLSまたはmTLSのどちらかを使用して接続を作成できます。FALSEに設定すると、クライアント側のプライベート証明書に関する情報は送信されなくなります。これは、すべての接続に適用されるため、tnsnames.ora接続文字列のSSL_CLIENT_AUTHENTICATIONパラメータは同じパラメータ設定を使用して変更できます。SSL_CLIENT_AUTHENTICATION=TRUEの場合は、mTLSのみを構成できます。この設定はオプションです。

    • 複数のデータベースに接続し、その一部がクライアント・ウォレットでmTLSを必要とする場合は、次のようにクライアント・ウォレットの有無で異なる接続を設定するための2つのオプションがあります。
      • オプション1: コマンド・ウォレットのsqlnet.oraでWALLET_LOCATIONを設定します。その後、sqlnet.oraの設定をオーバーライドするために、接続文字列でWALLET_LOCATIONを(tnsnames.oraまたは直接コマンドラインで)使用します。接続に別のウォレットの場所を指定することも、システム・デフォルトのキーストアを使用するように接続に指示することもできます。次のパラメータを使用して、ウォレットの場所をシステム・デフォルトのキーストアに変更します。
        net_service_name = (DESCRIPTION=(ADDRESS = (PROTOCOL=tcps)
(HOST=host_name)(PORT=port)) (SECURITY=(WALLET_LOCATION=SYSTEM)) 
(CONNECT_DATA=(SERVICE_NAME=service_name)))

        次の例では、ウォレット・ロケーションをウォレット・ファイル・ディレクトリに変更します。

        net_service_name = (DESCRIPTION=(ADDRESS = (PROTOCOL=tcps)
(HOST=host_name)(PORT=port)) (SECURITY=(WALLET_LOCATION=wallet_file_directory))
(CONNECT_DATA=(SERVICE_NAME=service_name)))

        デフォルトの証明書ストアの場所はプラットフォームによって異なります。Windowsの場合は、Microsoft Windows用のMicrosoft証明書ストアにあります。Linuxの場合、その場所は次のとおりです。

        • RHEL/Oracle Linux: /etc/pki/tls/cert.pem
        • Debian/Ubuntu/Gentoo: /etc/ssl/certs/ca-certificates.crt
        • Fedora/RHEL: /etc/pki/tls/certs/ca-bundle.crt
        • OpenSUSE: /etc/ssl/ca-bundle.pem
        • OpenELEC: /etc/pki/tls/cacert.pem
        • CentOS/RHEL7: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
        • Alpine Linux: /etc/ssl/cert.pem

        Linux以外およびWindows以外のシステムの場合、PEMファイルがLinuxシステム用の前述のいずれかの場所にない場合は、PEMファイルをこれらのデフォルトのLinuxの場所のいずれかにコピーするか、PEMファイルからこれらの場所の1つにシンボリックリンクを作成する必要があります。ファイルはPEMファイルである必要があります

        証明書ストアのデフォルトの場所は変更できません。デフォルトでは、tnsnames.oraは$ORACLE_HOME/network/adminディレクトリに配置されます。

      • オプション2: クライアント・ウォレットを使用する必要がある接続の一部としてのみWALLET_LOCATIONを指定します。sqlnet.oraでは、WALLET_LOCATIONを指定しません。クライアント・ウォレットを使用する必要のない接続は、sqlnet.oraファイルでWALLET_LOCATIONが指定されていない場合、自動的にローカル・デフォルトのシステム・キーストアが使用されます。
  8. SQL*Plusで、データベース接続がTLSを使用しているかどうかを確認するには、次の問合せを実行して接続を調べます。
     SELECT SYS_CONTEXT ('USERENV', 'NETWORK_PROTOCOL') FROM DUAL;

    次のような出力が表示されます。

    SYS_CONTEXT('USERENV','NETWORK_PROTOCOL')
-------------------------------------------------------------------
tcps

関連トピック

親トピック: クライアント・ウォレットを使用しないTransport Layer Security接続

21.10 クライアント・ウォレットを使用するTransport Layer Security接続

Transport Layer Securityは、サーバーで構成してから、クライアントで構成する必要があります。

親トピック: Transport Layer Security暗号化の構成

21.10.1 ステップ1: サーバーでのTransport Layer Securityの構成

インストール中、Oracleデータベース・サーバーとOracleクライアントに、Oracleウォレットの場所を除くTLSパラメータのデフォルトが設定されます。

親トピック: クライアント・ウォレットを使用するTransport Layer Security接続

21.10.1.1 ステップ1A: サーバーでのウォレットの作成の確認

次のステップに進む前に、ウォレットが作成されていることと、ウォレットに証明書があることを確認する必要があります。

  1. ウォレットが存在するOracle Databaseサーバーにログインします。
  2. 次のコマンドを実行します。
    orapki wallet display -wallet wallet_location

    ウォレットにステータスがReadyの証明書が含まれ、自動ログインがオンになっている必要があります。orapki create walletを使用して、自動ログインが有効になっているウォレットを作成できます。

21.10.1.2 ステップ1B: サーバーでのデータベース・ウォレットの場所の指定

次に、ウォレットのサーバー上の場所を指定します。

  1. Oracle Databaseサーバーにログインします。
  2. orapkiまたはmkstore (非推奨)コマンドライン・ツールを使用してウォレットを作成します。
    たとえば、orapkiを使用してウォレットを作成するには、次のようにします。
    orapki wallet create -wallet wallet_location

    ウォレットを自動ログイン・ウォレットとして作成するには、次の構文を使用します。

    orapki wallet create -wallet wallet_location - auto_login
  3. sqlnet.oraファイルとlistener.oraファイルの両方でWALLET_LOCATIONパラメータを次のように変更します。
    WALLET_LOCATION = 
 (SOURCE=
  (METHOD=file)
  (METHOD_DATA=
   (DIRECTORY=wallet_location)))

    次のことに注意してください。

    • ディレクトリを指定するとき、エンタープライズ・ユーザー・セキュリティ用にデータベースとディレクトリ間のTLS接続を構成する場合は、Database Configuration Assistantによって自動的にデータベース・ウォレットが作成され、データベースがディレクトリに登録されます。そのウォレットを使用して、TLSで認証されたエンタープライズ・ユーザー・セキュリティのデータベースPKI資格証明を格納する必要があります。

      ノート:

      エンタープライズ・ユーザー・セキュリティ(EUS)は、Oracle Database 23cで非推奨になりました。

      集中管理ユーザー(CMU)の使用に移行することをお薦めします。この機能を使用すると、データベースに対するエンタープライズ・ユーザー認証および認可のためにディレクトリ・サービスを介在させることなく、Microsoft Active Directoryに直接接続できます。Oracle Databaseがクラウドにある場合は、クラウド・アイデンティティ・プロバイダとの新しい統合のいずれかに移行することも選択できます。

      パラメータWALLET_LOCATIONは、Oracle DatabaseサーバーのOracle Database 23cでの使用は非推奨です。Oracle Databaseクライアントでの使用は非推奨ではありません。

      Oracle Databaseサーバーには、WALLET_LOCATIONを使用するかわりにWALLET_ROOTシステム・パラメータを使用することをお薦めします。

      例:

      ALTER SYSTEM SET WALLET_ROOT='wallet_location' SCOPE =  SPFILE SID = "*";

    • sqlnet.oraファイル内の設定は、すべてのプラガブル・データベース(PDB)に適用されます。

    • ウォレットを作成したとき、およびsqlnet.oraファイルに場所を設定したときと同じ場所を入力してください。

ノート:

リスナーでは、listener.oraファイルに定義されているウォレットを使用します。任意のデータベース・ウォレットを使用できます。Net Managerを使用してサーバーのSSLが構成されている場合、ウォレット・ロケーションはlistener.oraファイルとsqlnet.oraファイルに入力されています。listener.oraファイルは、Oracleクライアントには関係ありません。

リスナーが独自のウォレットを所有するようにリスナーのウォレット・ロケーションを変更するには、listener.oraを編集して新しい場所を入力します。

21.10.1.3 ステップ1C: サーバーでのTransport Layer Security暗号スイートの設定(オプション)

オプションで、Transport Layer Security暗号スイートを設定できます。

親トピック: ステップ1: サーバーでのTransport Layer Securityの構成

21.10.1.3.1 Transport Layer Security暗号スイートについて

暗号スイートは、ネットワーク・エンティティ間のメッセージ交換に使用される認証、暗号化およびデータ整合性アルゴリズムのセットです。

Transport Layer Securityハンドシェイク時に、2つのエンティティがネゴシエートし、メッセージを送受信するときに使用する暗号スイートを確認します。

Oracle Databaseをインストールすると、Transport Layer Security暗号スイートがデフォルトで設定され、リスト順にネゴシエートされます。デフォルトの順序は、SSL_CIPHER_SUITESパラメータを設定して上書きできます。SSL_CIPHER_SUITESパラメータの設定は必ずカッコで囲んでください(例: SSL_CIPHER_SUITES=(tls_rsa_with_aes_128_cbc_sha256))。そうしないと、暗号スイート設定が正しく解析されません。

暗号スイートの優先順位を設定できます。クライアントが使用する暗号スイートに関してサーバーとネゴシエートする場合、設定されている優先順位に従います。暗号スイートの優先順位を設定する場合は、次の点を考慮してください。

  • 互換性。正常に接続するには、互換性のある暗号スイートを使用するようにサーバーとクライアントを構成する必要があります。

  • 暗号の優先順位と強度。最高レベルのセキュリティを確保するために、最も強力なものから最も弱いものの順に暗号スイートの優先順位を設定します。

  • 使用するセキュリティ・レベル。

  • パフォーマンスへの影響。

21.10.1.3.2 TLS暗号スイートの認証、暗号化、整合性およびTLSバージョン

Oracle Databaseでは、Oracle Databaseをインストールするとデフォルトで設定される一連の暗号スイートがサポートされています。

表21-3に、各暗号スイートで使用される認証、暗号化およびデータ整合性のタイプを示します。

セキュリティ要件を満たすために、TLS 1.3の使用をお薦めします。

次の表では、非推奨としてマークされている暗号スイートの安全性が低いとみなされます。セキュリティについては無効になっていますが、sqlnet.oraでパラメータSSL_ENABLE_WEAK_CIPHERSをTRUEに設定することで有効にできます。デフォルトでは、SSL_ENABLE_WEAK_CIPHERSはFALSEです。

表21-3 Transport Layer Security暗号スイート

暗号スイート 認証 暗号化 データ整合性 TLSの互換性

TLS_AES_128_CCM_SHA256

CDHE_RSA, DHE_RSA, ECDHE_ECDSA

AES 128 CCM

SHA256 (SHA 2)

TLS 1.3

TLS_AES_128_GCM_SHA256

CDHE_RSA, DHE_RSA, ECDHE_ECDSA

AES 128 GCM

SHA256 (SHA-2)

TLS 1.3

TLS_AES_256_GCM_SHA384

CDHE_RSA, DHE_RSA, ECDHE_ECDSA

AES 256 GCM

SHA384 (SHA-2)

TLS 1.3

TLS_CHACHA20_POLY1305_SHA256 (FIPS以外のみ)

CDHE_RSA, DHE_RSA, ECDHE_ECDSA

CHACHA20 POLY1305

SHA256 (SHA-2)

TLS 1.3

TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (非推奨)

DHE_RSA

AES 128 CBC

SHA256 (SHA-2)

TLS 1.2

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

DHE_RSA

AES 128 GCM

SHA256 (SHA-2)

TLS 1.2

TLS_DHE_RSA_WITH_AES_256_CBC_SHA (非推奨)

DHE_RSA

AES 256 CBC

SHA (SHA-1)

TLS 1.2

TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (非推奨)

DHE_RSA

AES 256 CBC

SHA256 (SHA-2)

TLS 1.2

TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

DHE_RSA

AES 256 GCM

SHA384 (SHA-2)

TLS 1.2

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (非推奨)

ECDHE_ECDSA

AES 128 CBC

SHA (SHA-1)

TLS 1.2

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (非推奨)

ECDHE_ECDSA

AES 128 CBC

SHA (SHA-1)

TLS 1.2

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (非推奨)

ECDHE_ECDSA

AES 128 CBC

SHA256 (SHA-2)

TLS 1.2

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

ECDHE_ECDSA

AES 128 GCM

SHA256 (SHA-2)

TLS 1.2

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (非推奨)

ECDHE_ECDSA

AES 256 CBC

SHA (SHA-1)

TLS 1.2

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (非推奨)

ECDHE_ECDSA

AES 256 CBC

SHA384 (SHA-2)

TLS 1.2

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

ECDHE_ECDSA

AES 256 GCM

SHA384 (SHA-2)

TLS 1.2

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (非推奨)

ECDHE_RSA

AES 128 CBC

SHA (SHA-1)

TLS 1.2

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (非推奨)

ECDHE_RSA

AES 128 CBC

SHA256 (SHA-2)

TLS 1.2

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

ECDHE_RSA

AES 128 GCM

SHA256 (SHA-2)

TLS 1.2

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (非推奨)

ECDHE_RSA

AES 256 CBC

SHA (SHA-1)

TLS 1.2

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (非推奨)

ECDHE_RSA

AES 256 CBC

SHA384 (SHA-2)

TLS 1.2

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

ECDHE_RSA

AES 256 GCM

SHA384 (SHA-2)

TLS 1.2

TLS_RSA_WITH_AES_128_CBC_SHA (非推奨)

RSA

AES 128 CBC

SHA (SHA-1)

TLS 1.2

TLS_RSA_WITH_AES_128_CBC_SHA256 (非推奨)

RSA

AES 128 CBC

SHA256 (SHA-2)

TLS 1.2

TLS_RSA_WITH_AES_128_GCM_SHA256 (非推奨)

RSA

AES 128 GCM

SHA256 (SHA-2)

TLS 1.2

TLS_RSA_WITH_AES_256_CBC_SHA (非推奨)

RSA

AES 256 CBC

SHA (SHA-1)

TLS 1.2

TLS_RSA_WITH_AES_256_CBC_SHA256 (非推奨)

RSA

AES 256 CBC

SHA256 (SHA-2)

TLS 1.2

TLS_RSA_WITH_AES_256_GCM_SHA384 (非推奨)

RSA

AES 256 GCM

SHA384 (SHA-2)

TLS 1.2
21.10.1.3.3 脆弱な暗号スイートの有効化

SSL_ENABLE_WEAK_CIPHERSパラメータを設定することにより、非推奨の暗号スイートを有効にできます。

表21-3に、無効になっている暗号スイートを示します。
  1. Oracle Databaseにログインします。
  2. サーバーとクライアントの両方のsqlnet.oraファイルで、次のパラメータを変更します。
    SSL_ENABLE_WEAK_CIPHERS=value

    この指定では、valueは次のいずれかになります。

    • FALSE (またはOFF、NO、0)は、脆弱な暗号を無効化します。この設定はデフォルトです。脆弱な暗号を使用しようとすると、現在の場所に応じて次のエラーが表示されます。
      • データベース・サーバー: ORA-28860: 致命的なSSLエラーが発生しました
      • データベース・クライアント: ORA-29039: 一致するCipher Suiteがありません。

      SSL_ENABLE_WEAK_CIPHERSがFALSEに設定されている場合、次の暗号スイートを使用できます。

      • TLS_AES_128_CCM_SHA256
      • TLS_AES_128_GCM_SHA256
      • TLS_AES_256_GCM_SHA384
      • TLS_CHACHA20_POLY1305_SHA256
      • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
      • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
      • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
      • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
      • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
      • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    • TRUE (またはON、YES、1)は、脆弱な暗号を有効にします。
21.10.1.3.4 データベース・サーバーのTransport Layer Security暗号スイートの指定

最初に、データベース・サーバーのTransport Layer Security暗号スイートを指定する必要があります。

  1. Oracle Databaseサーバーにログインします。
  2. sqlnet.oraファイルでSSL_CIPHER_SUITESパラメータを変更します。
    SSL_CIPHER_SUITES= (SSL_cipher_suite1 [,SSL_cipher_suite2])
21.10.1.4 ステップ1D: サーバーでの必要なTransport Layer Securityバージョンの設定(オプション)

SSL_VERSIONパラメータでは、サーバーが通信するシステムで実行する必要があるTLSのバージョンを定義します。

オプションで、sqlnet.oraファイルまたはlistener.oraファイルでSSL_VERSIONパラメータを設定できます。

これらのシステムで有効なバージョンを使用するように設定できます。

  • サーバーのsqlnet.oraファイルで、SSL_VERSIONパラメータを設定して、サーバーでサポートされているTLSバージョンを指定します。
    有効な値は、undetermined (デフォルト)、TLSv1.2およびTLSv1.3です。複数のエントリはカンマで区切ります。例:
    SSL_VERSION=(TLSv1.2,TLSv1.3)
21.10.1.5 ステップ1E: サーバーでのTransport Layer Securityクライアント認証の設定(オプション)

SSL_CLIENT_AUTHENTICATIONパラメータは、クライアントがTLSを使用して認証されるかどうかを制御します。

このパラメータはサーバーのsqlnet.oraファイルで設定する必要があります。SSL_CLIENT_AUTHENTICATIONパラメータのデフォルト値はTRUEです。

サーバーの認証のみが必要な一方向TLSを使用している場合は、SSL_CLIENT_AUTHENTICATIONをFALSEに設定できます。

また、KerberosやRADIUSなどのOracle Databaseでサポートされている非SSL認証方式を使用してクライアントがサーバーに対して自己認証を行うようにする場合も、このパラメータをFALSEに設定できます。

  • サーバーでSSL_CLIENT_AUTHENTICATIONを設定するには、sqlnet.oraファイルを編集します。
    例:
    SSL_CLIENT_AUTHENTICATION=FALSE
21.10.1.6 ステップ1F: サーバーでの認証サービスとしてのトランスポート・レイヤー・セキュリティの設定(オプション)

sqlnet.oraファイルのSQLNET.AUTHENTICATION_SERVICESパラメータでは、TLS認証サービスを設定します。

このパラメータは、TLS認証とOracle Databaseでサポートされている別の認証方式を組み合せて使用する場合に設定します。たとえば、サーバーがTLSを使用してクライアントに対して自己認証を行い、クライアントがKerberosを使用してサーバーに対して自己認証を行う場合に、このパラメータを使用します。

  • サーバーにSQLNET.AUTHENTICATION_SERVICESパラメータを設定するには、テキスト・エディタを使用してsqlnet.oraファイルでこのパラメータにTLS付きTCP/IP(TCPS)を追加します。たとえば、SSL認証とRADIUS認証を組み合せて使用する場合は、このパラメータを次のように設定します。 

     SQLNET.AUTHENTICATION_SERVICES = (TCPS, radius)

TLS認証と別の認証方式を組み合せて使用しない場合は、このパラメータを設定しません。

21.10.1.7 ステップ1G: Transport Layer Security付きTCP/IPを使用するリスニング・エンドポイントのサーバーでの作成

TLS付きTCP/IPを使用するリスニング・エンドポイントをサーバーで構成できます。

  • listener.oraファイルでリスナーを構成します。一般的なOracle Netクライアントには、ポート番号2484を使用することをお薦めします
21.10.1.8 ステップ1H: データベースの再起動

サーバーでのTransport Layer Securityの構成を完了するには、データベースを再起動する必要があります。

  • 次に例を示します。
    SHUTDOWN IMMEDIATE
STARTUP

21.10.2 ステップ2: クライアントでのTransport Layer Securityの構成

SSLをクライアントで構成する場合、サーバーDNを構成して、TLS付きTCP/IPをクライアントで使用します。

親トピック: クライアント・ウォレットを使用するTransport Layer Security接続

21.10.2.1 ステップ2A: クライアント・ウォレットの作成の確認

クライアントでウォレットが作成されていることと、クライアントに有効な証明書があることを確認する必要があります。

  • 次のコマンドを実行して、ウォレットが作成されていることを確認します。
    orapki wallet display -wallet wallet_location
    orapki crl deleteコマンドを使用して、各認証局に関連付けられたOracleウォレット内の使用していない信頼できる証明書を削除することをお薦めします。
21.10.2.2 ステップ2B: サーバーDN一致の構成とクライアントでのTLS付きTCP/IPの使用

次に、サーバーDN一致を構成し、クライアントでTransport Layer Security (TLS)付きのTCP/IPを使用します。

親トピック: ステップ2: クライアントでのTransport Layer Securityの構成

21.10.2.2.1 サーバーDN一致の構成とクライアントでのTLS付きTCP/IPの使用について

サーバー証明書の証明書チェーンの検証に加えて、サーバーDN一致を使用して追加のチェックを実行できます。

サーバーDNの照合はオプションですが、Oracleではクライアントにセキュリティのレイヤーが追加されるため、これをお薦めします。

部分DN一致または完全DN一致のいずれかを構成できます。部分または完全DN一致のいずれかを使用すると、ホスト証明書の作成方法と管理方法に基づいて柔軟性が向上します。

  • 部分DN一致: SSL_SERVER_DN_MATCHパラメータをTRUEに設定すると、部分DN一致が自動的に有効になります。クライアントは、HOSTパラメータを使用してサーバー証明書のCNと照合します。たとえば、クライアントがHOST=finance.us.example.comを使用してサーバーへの接続を試みるとします。部分DN一致では、クライアントはサーバーの証明書をチェックして、CN=financeがサーバーのDNであることを確認します。部分DN一致の場合、ホスト名(finance)のみがチェックされ、完全修飾ドメイン名(finance.us.example.com)はチェックされません。
  • 完全DN一致: 完全DN一致により、クライアントはサーバーの完全なDNと照合できます。完全DN一致を実行する場合は、SSL_SERVER_DN_MATCHパラメータをTRUEに設定し、SSL_SERVER_CERT_DNパラメータをTNS接続文字列のサーバーのDNに設定する必要があります。

    tnsnames.oraクライアント・ネットワーク構成ファイルを手動で編集して、サーバーのDNとTCP/IPをTLSプロトコルに指定する必要があります。tnsnames.oraファイルは、クライアントまたはLDAPディレクトリに配置できます。サーバーに配置される場合は、通常、listener.oraファイルと同じディレクトリに存在します。tnsnames.oraファイルは、通常、TNS_ADMIN環境変数で指定された設定にあります。TNS_ADMINが設定されていない場合、tnsnames.oraは次のディレクトリの場所に存在します。

    • Linux: $ORACLE_HOME/network/admin/
    • Windows: ORACLE_BASE\ORACLE_HOME\network\admin\
21.10.2.2.2 サーバーDN一致の構成とクライアントでのTLS付きTCP/IPの使用

サーバーDN一致を構成し、クライアントでTLS付きのTCP/IPを使用するようにtnsnames.oraファイルとlistener.oraファイルを編集する必要があります。

  • 部分DN一致(ホスト名ベースのDN一致)
    部分DN一致を有効にするには、sqlnet.oraファイルでSSL_SERVER_DN_MATCHパラメータをTRUEに設定する必要があります。
  • 完全なDN一致
    tnsnames.oraおよびsqlnet.oraファイルを編集して、サーバーDN一致を構成し、クライアントでTCP/IPとTLSを使用する必要があります。

親トピック: ステップ2B: サーバーDN一致の構成とクライアントでのTLS付きTCP/IPの使用

21.10.2.2.2.1 部分DN一致(ホスト名ベースのDN一致)

部分DN一致を有効にするには、sqlnet.oraファイルでSSL_SERVER_DN_MATCHパラメータをTRUEに設定する必要があります。

パラメータがTRUEに設定されると、部分DN一致がデフォルトで有効になります。tnsnames.oraで構成された接続識別子のHOSTパラメータは、サーバー証明書のDNと一致するために使用されます。

デフォルトでは、tnsnames.oraおよびsqlnet.oraファイルは$ORACLE_HOME/network/admin directory (UNIXシステムの場合)またはORACLE_HOME\network\admin (Windowsの場合)にあります。

部分DN一致のtnsnames.oraの例を次に示します。 

finance=
    (DESCRIPTION=
    (ADDRESS_LIST=
    (ADDRESS= (PROTOCOL = tcps) (HOST = finance) (PORT = 1575)))
    (CONNECT_DATA=
    (SERVICE_NAME= finance.us.example.com)))

部分DN一致のsqlnet.oraの例を次に示します。 

SSL_SERVER_DN_MATCH=TRUE
21.10.2.2.2.2 完全なDN一致

サーバーDN一致を構成し、クライアントでTLS付きのTCP/IPを使用するには、tnsnames.oraファイルおよびsqlnet.oraファイルを編集する必要があります。

デフォルトでは、tnsnames.oraおよびsqlnet.oraファイルは$ORACLE_HOME/network/adminディレクトリ(UNIXシステムの場合)またはORACLE_HOME\network\admin (Windowsの場合)にあります。

完全なDN一致を使用する場合は、次の例のように、SSL_SERVER_CERT_DNパラメータを接続識別子の完全なDNに設定します。 

(SECURITY=
(SSL_SERVER_CERT_DN="cn=finance,ou=OracleContext,c=us,o=example"))

クライアントはこの情報を使用して、リスナーおよびサーバーに必要なDNを取得し、リスナーおよびサーバーのDNがDN文字列と一致するように強制します。

ノート:

2022年から組織ユニット(OU)フィールドが削除されるCA証明書形式の変更により、SSL_SERVER_CERT_DNパラメータを設定する場合は、サーバー証明書DNを更新する必要がある場合があります。DNからOUを削除した新しいサーバー証明書を受け取ったら、新しいDNと一致するようにクライアントのSSL_SERVER_CERT_DNパラメータを更新する必要があります。

完全DN一致用にtnsnames.oraを設定する例を次に示します。 

finance=
    (DESCRIPTION=
    (ADDRESS_LIST=
    (ADDRESS= (PROTOCOL = tcps) (HOST = finance) (PORT = 1575)))
    (CONNECT_DATA=
    (SERVICE_NAME= finance.us.example.com))
    (SECURITY=
    (SSL_SERVER_CERT_DN="cn=finance,ou=OracleContext,c=us,o=example"))

完全DN一致用にsqlnet.oraを設定する例を次に示します。 

SSL_SERVER_DN_MATCH=TRUE
21.10.2.2.3 SSL_ALLOW_WEAK_DN_MATCHパラメータを使用したSSL_SERVER_DN_MATCHの制御

SSL_ALLOW_WEAK_DN_MATCHパラメータは、SSL_SERVER_DN_MATCHパラメータで部分識別名一致にサービス名を使用できるかと、データベース・サーバーの証明書をチェックするかを制御します。

Oracle Database 23c以降、SSL_SERVER_DN_MATCHパラメータの動作が変更されました。以前は、DN一致について、データベース・サーバーの証明書のみがチェックされました。Oracle Database 23cでは、リスナーとサーバーの両方の証明書がチェックされます。また、SERVICE_NAME設定は、部分DN一致時のチェックに使用されません。HOST設定は引き続き、リスナーとサーバーの両方の証明書で、証明書DNおよびサブジェクト代替名(SAN)との部分DN一致に使用できます。

SSL_ALLOW_WEAK_DN_MATCHは次のように設定できます。

  • TRUEは、SSL_SERVER_DN_MATCHでデータベース・サーバーの証明書をチェックし(ただし、リスナーはチェックしません)、サービス名を部分DN一致に使用できるようにします。クライアント側での検索順序は、まずホスト名、次にサブジェクト代替名(SAN)、そしてサービス名です。
  • FALSE (デフォルト)は、SSL_SERVER_DN_MATCHでサービス名一致をチェックできないようにします。かわりに、クライアント側での一致は、証明書DNでのHOST設定の検索に基づき、それが使用できない場合はサブジェクト代替名(SAN)フィールドで行います(ただし、サービス名は使用できません)。DNチェックは、リスナーおよびサーバーで実行されます。

以前に部分DN一致にサービス名を使用した場合は、新しい証明書を取得するか、SSL_ALLOW_WEAK_DN_MATCHをTRUEに設定してリリース23cより前の動作に戻す必要があります。ほとんどの場合、データベース・サーバーとリスナーの両方に同じ証明書を使用していますが、そうでない場合は、次のいずれかを実行する必要があります。

  • 新しい証明書を取得します(自己署名証明書にはorapki cert createコマンドを使用します)
  • DN一致方針を変更または削除します。
  • SSL_SERVER_DN_MATCHを古い動作に戻すには、SSL_ALLOW_WEAK_DN_MATCHパラメータをTRUEに設定します。

SSL_ALLOW_WEAK_DN_MATCHをTRUEに設定する際は、次の点に注意してください。

  • クライアントが完全DN一致(SSL_SERVER_MATCH=TRUE、SSL_SERVER_CERT_DN="certificate_DN")を実行する場合、データベース・サーバーの証明書DNのみがSSL_SERVER_CERT_DN値と一致する必要があります。
  • クライアントが部分DN一致(SSL_SERVER_MATCH=TRUE、SSL_SERVER_CERT_DNが設定されていない)を実行する場合、Oracle Databaseは接続文字列パラメータHOSTをデータベース・サーバー証明書DNの共通名(CN)および証明書のサブジェクト代替名フィールド(SAN)と比較します。部分一致がない場合、Oracle Databaseは引き続き、CNでSERVICE_NAMEパラメータをチェックします。
21.10.2.3 ステップ2C: 必要なクライアントTLS構成の指定(ウォレット・ロケーション)

sqlnet.oraファイルを変更して、必要なクライアントTLS構成を指定できます。

  1. Oracle Databaseクライアントにログインします。
  2. sqlnet.oraファイルでWALLET_LOCATIONおよびSSL_SERVER_DN_MATCHパラメータを次のように変更します。
    SSL_CLIENT_AUTHENTICATION =TRUE
WALLET_LOCATION = 
 (SOURCE=
  (METHOD=File)
  (METHOD_DATA=
   (DIRECTORY=wallet_location)))

SSL_SERVER_DN_MATCH=(ON/OFF)

    SSL_SERVER_DN_MATCH設定の場合、次の点に注意してください。

    • ON: サーバーの識別名(DN)がホスト名と一致している必要があります。TLSによって証明書がサーバーからのものであることが確認され、一致した場合は接続が成功します。
    • OFF: TLSによってDNとホスト名の間の一致がチェックできるようになりますが、強制はされません。結果に関係なく接続は成功しますが、一致しない場合はエラーが記録されます。これはデフォルト設定です。OFFを選択すると、次のアラートが表示されます。
      Security Alert
Not enforcing the server X.509 name match allows a server to potentially fake its identity. Oracle recommends selecting YES for this option so that connections are refused when there is a mismatch.
21.10.2.4 ステップ2D: 単一データベース・クライアントからの様々な証明書の使用による複数データベースへの接続

オプションで、クライアントを、様々な証明書およびウォレットを使用して複数のOracle Databaseサーバーに接続するように構成できます。

親トピック: ステップ2: クライアントでのTransport Layer Securityの構成

21.10.2.4.1 単一データベース・クライアントからの様々な証明書の使用による複数データベースへの接続について

この機能により、マルチスレッド・クライアントが、異なる証明書を持つ複数のウォレットをTransport Layer Security (TLS)セッションで同時に使用できます。

この機能は、単一のクライアントで様々なウォレットおよび証明書を使用して様々なOracle Databasesに接続する必要がある場合に使用します。たとえば、複数のプラガブル・データベース(PDB)へのアクセスが必要なクライアントが、それぞれ独自のID (証明書)を持つ場合です。この機能により、クライアントが各PDBの正しいIDに接続するように構成できます。構成が完了すると、マルチスレッド・クライアントは、同時TLSセッションで異なる証明書を持つ複数のウォレットにアクセスできるようになります。

21.10.2.4.2 クライアント接続での個別のTLSセッションの有効化

tnsnames.oraファイルのWALLET_LOCATIONパラメータを構成して、クライアント接続が個別のTransport Layer Security (TLS)セッションを持つようにできます。

  1. PDBが存在するデータベース・サーバーにログインします。
  2. tnsnames.oraファイルを探します。
    デフォルトでは、tnsnames.oraファイルはORACLE_HOME/network/adminディレクトリにあります。tnsnames.oraファイルは、環境変数TNS_ADMINで指定されたディレクトリに配置される場合もあります。
  3. tnsnames.oraファイルを編集してそれにWALLET_LOCATIONパラメータを含めます。
    例:
    ssl_certs = 
    (DESCRIPTION = 
       (ADDRESS=(PROTOCOL=tcps)(HOST=shobeen.us.example.com) (PORT=1750))
       (CONNECT_DATA=(SID=hr_pdb)) 
       (SECURITY=(WALLET_LOCATION=/oracle/wallets/certificates/hr_cert))
     )

    この例では、WALLET_LOCATIONは、hr_certというTLS証明書を含むディレクトリを指します。

    WALLET_LOCATIONは、tnsnames.oraとsqlnet.oraの両方で使用できます。tnsnames.ora内のWALLET_LOCATIONは、sqlnet.ora内の、そのtnsnames.oraサービスについてのWALLET_LOCATIONより優先されます。

    次の例では、証明書を持つ複数のウォレットをtnsnames.oraにおいてどのように構成するかを示します。SIDとウォレット・ロケーションが異なることに注意してください。 

    ssl_certs1 = 
    (DESCRIPTION = 
       (ADDRESS=(PROTOCOL=tcps)(HOST=shobeen.us.example.com) (PORT=1750))
       (CONNECT_DATA=(SID=sales_pdb)) 
       (SECURITY=(WALLET_LOCATION=/oracle/wallets/certificates/sales_cert))
     )
ssl_certs2 = 
    (DESCRIPTION = 
       (ADDRESS=(PROTOCOL=tcps)(HOST=shobeen.us.example.com) (PORT=1750))
       (CONNECT_DATA=(SID=marketing_pdb)) 
       (SECURITY=(WALLET_LOCATION=/oracle/wallets/certificates/marketing_cert))
     )
21.10.2.5 ステップ2E: クライアントのTransport Layer Security暗号スイートの設定(オプション)

オプションで、Transport Layer Security暗号スイートを設定できます。Oracle Databaseにはデフォルトの暗号スイート設定が用意されています。

親トピック: ステップ2: クライアントでのTransport Layer Securityの構成

21.10.2.5.1 クライアントのTransport Layer Security暗号スイートの設定について

暗号スイートは、ネットワーク・エンティティ間のメッセージ交換に使用される認証、暗号化およびデータ整合性アルゴリズムのセットです。

SSLハンドシェイク時に、2つのエンティティがネゴシエートし、メッセージを送受信するときに使用する暗号スイートを確認します。

Oracle Databaseをインストールすると、TLS暗号スイートがデフォルトで設定されます。2つのエンティティが接続をネゴシエートするときに、この表のリスト順で暗号スイートが試行されます。デフォルトは、SSL_CIPHER_SUITESパラメータを設定して上書きできます。たとえば、暗号スイートTLS_DHE_RSA_WITH_AES_128_GCM_SHA256を追加した場合、デフォルト設定での他のすべての暗号スイートは無視されます。

暗号スイートの優先順位を設定できます。クライアントが使用する暗号スイートに関してサーバーとネゴシエートする場合、設定されている優先順位に従います。暗号スイートの優先順位を設定する場合は、次の点を考慮してください。

  • 使用するセキュリティ・レベル。たとえば、AES暗号化はDESよりも強力です。

  • パフォーマンスへの影響。たとえば、Triple-DES暗号化は、DESよりも低速です。

  • 管理要件。クライアントに対して選択された暗号スイートは、サーバーに必要な暗号スイートと互換性がある必要があります。たとえば、Oracle Call Interface (OCI)ユーザーの場合、サーバーはクライアントに自己認証を求めます。

通常、暗号スイートは最も強力なものから弱いものの順に優先順位を設定します。

現在サポートされているTransport Layer Security暗号スイートは、Oracle Databaseのインストール時にデフォルトで設定されます。表では、各暗号スイートで使用される認証、暗号化およびデータ整合性のタイプも示されています。

21.10.2.5.2 クライアントのTransport Layer Security暗号スイートの設定

sqlnet.oraファイルを変更して、クライアントTLS暗号スイートを設定できます。

  1. Oracle Databaseクライアントにログインします。
  2. sqlnet.oraファイルでSSL_CIPHER_SUITESパラメータを次のように変更します。
    SSL_CIPHER_SUITES= (SSL_cipher_suite1 [,SSL_cipher_suite2])
21.10.2.6 ステップ2F: クライアントでの必要なTLSバージョンの設定(オプション)

SSL_VERSIONパラメータでは、クライアントが通信するシステムで実行する必要があるTLSのバージョンを定義します。

sqlnet.oraファイルでSSL_VERSIONパラメータを設定する必要があります。これらのシステムで有効なバージョンを使用するように設定できます。

sqlnet.oraにおけるこのパラメータのデフォルト設定はundeterminedで、これは、「ネットワーク・セキュリティ」ウィンドウの「SSL」タブのリストから「任意」を選択すると設定されます。「任意」を選択すると、TLSバージョンが上位バージョンから下位バージョンに試行されます。まずTLS 1.3を、次にTLS 1.2を試みます。

セキュリティ要件を満たすために、TLS 1.3の使用をお薦めします。

  1. 「必要なSSLバージョン」リストで、構成するTLSバージョンを選択します。

    デフォルトの設定は「任意」です。

  2. 「ファイル」メニューから、「ネットワーク構成の保存」を選択します。

    sqlnet.oraファイルが更新されます。「任意」を選択した場合は、次のエントリで更新されます。 

    SSL_VERSION=UNDETERMINED
21.10.2.7 ステップ2G: クライアントでの認証サービスとしてのTLSの設定(オプション)

sqlnet.oraファイルのSQLNET.AUTHENTICATION_SERVICESパラメータでは、TLS認証サービスを設定します。

親トピック: ステップ2: クライアントでのTransport Layer Securityの構成

21.10.2.7.1 SQLNET.AUTHENTICATION_SERVICESパラメータについて

SQLNET.AUTHENTICATION_SERVICESパラメータは、TLS認証とOracle Databaseでサポートされている別の認証方式の併用を可能にします。

たとえば、サーバーがTLSを使用してクライアントに対して自己認証を行い、クライアントがRADIUSを使用してサーバーに対して自己認証を行う場合に、このパラメータを使用します。

SQLNET.AUTHENTICATION_SERVICESパラメータを設定するには、sqlnet.oraファイル(他のネットワーク構成ファイルと同じディレクトリにあります)を編集する必要があります。

プラットフォームに応じて、sqlnet.oraファイルは次のディレクトリにあります。

  • (UNIXの場合) $ORACLE_HOME/network/admin

  • (Windowsの場合) ORACLE_BASE\ORACLE_HOME\network\admin\

21.10.2.7.2 SQLNET.AUTHENTICATION_SERVICESパラメータの設定

sqlnet.oraファイルでSQLNET.AUTHENTICATION_SERVICESパラメータを設定できます。

  • クライアントのSQLNET.AUTHENTICATION_SERVICESパラメータを設定するには、テキスト・エディタを使用して、sqlnet.oraファイルのこのパラメータにTLS付きTCP/IP (TCPS)を追加します。

    たとえば、TLS認証とRADIUS認証を組み合せて使用する場合は、このパラメータを次のように設定します。

     SQLNET.AUTHENTICATION_SERVICES = (TCPS, radius)

TLS認証と別の認証方式を組み合せて使用しない場合は、このパラメータを設定しません。

21.10.2.8 ステップ2H: クライアントでの認証に使用する証明書の指定(オプション)

証明書が複数ある場合は、sqlnet.oraファイルのSQLNET.SSL_EXTENDED_KEY_USAGEパラメータで正しい証明書を指定できます。

親トピック: ステップ2: クライアントでのTransport Layer Securityの構成

21.10.2.8.1 SQLNET.SSL_EXTENDED_KEY_USAGEパラメータについて

sqlnet.oraファイルのSQLNET.SSL_EXTENDED_KEY_USAGEパラメータは、データベース・サーバー認証時に使用する証明書を指定します。

セキュリティ・モジュールに複数の証明書があるが、1つの証明書のみにクライアント認証の拡張キー使用方法フィールドがあり、その証明書がまさに、データベースの認証に使用する証明書である場合、SQLNET.SSL_EXTENDED_KEY_USAGEパラメータを設定します。

たとえば、スマートカードに複数の証明書があり、そのうちの1つのみにclient authenticationの拡張キー使用方法フィールドがあり、その証明書Cをデータベースの認証に使用する場合、このパラメータを設定します。Windowsクライアントでこのパラメータをclient authenticationに設定すると、MSCAPI証明書の選択ボックスが表示され、証明書Cが自動的に、サーバーへのクライアントのTransport Layer Security認証に使用されます。

21.10.2.8.2 SQLNET.SSL_EXTENDED_KEY_USAGEパラメータの設定

SQLNET.SSL_EXTENDED_KEY_USAGEを設定して、クライアント認証を設定できます。

  • クライアントのSQLNET.SSL_EXTENDED_KEY_USAGEパラメータを設定するには、sqlnet.oraファイルを編集し、次の行を含めます。 

    SQLNET.SSL_EXTENDED_KEY_USAGE = "client authentication"

証明書のフィルタ処理を使用しない場合は、sqlnet.oraファイルからSQLNET.SSL_EXTENDED_KEY_USAGEパラメータ設定を削除します。

21.10.2.9 ステップ2I: 接続がTransport Layer Securityを使用していることの確認

動的ビューのV$SESSIONとV$SESSION_CONNECT_INFOを問い合せると、クライアント接続がTransport Layer Security (TLS)を使用していることを確認できます。

  • SQL*Plusで、次の問合せを実行します。
    Oracle Databaseセッションのプロトコルを表示するには:
    SELECT SYS_CONTEXT ('USERENV', 'NETWORK_PROTOCOL') FROM DUAL;

    次のような出力が表示されます。

    SYS_CONTEXT('USERENV','NETWORK_PROTOCOL')
-------------------------------------------------------------------
tcps

    OracleセッションのTLSバージョンを表示するには:

    SELECT SYS_CONTEXT ('USERENV', 'TLS_VERSION') FROM DUAL;

    次のような出力が表示されます。

    SYS_CONTEXT('USERENV','TLS_VERSION')
--------------------------------------------------------------------
TLS 1.3

    OracleセッションのTLS暗号スイートを表示するには:

    SELECT SYS_CONTEXT ('USERENV', 'TLS_CIPHERSUITE') FROM DUAL;

    次のような出力が表示されます。

    SYS_CONTEXT('USERENV','TLS_CIPHERSUITE')
--------------------------------------------------------------------
TLS_AES_256_GCM_SHA384
21.10.2.10 ステップ2J: データベースの再起動

クライアントでのTransport Layer Securityの構成を完了するには、データベースを再起動する必要があります。

  • 次に例を示します。
    SHUTDOWN IMMEDIATE
STARTUP

21.10.3 ステップ3: データベース・インスタンスへのログイン

構成の完了後、データベースにログインします。

  • SQL*Plusを起動して、次のいずれかの接続コマンドを入力します。

    • クライアントにTransport Layer Security認証を使用する場合は(sqlnet.oraファイルでSSL_CLIENT_AUTHENTICATION=trueを設定)、次のように入力します。 

      CONNECT/@net_service_name

    • Transport Layer Security認証を使用しない場合は(sqlnet.oraファイルでSSL_CLIENT_AUTHENTICATION=falseを設定)、次のように入力します。 

      CONNECT username@net_service_name
Enter password: password

関連トピック

親トピック: クライアント・ウォレットを使用するTransport Layer Security接続

21.11 Oracle Real Application Clusters環境でのTransport Layer Security接続

Oracle RACツールを使用してOracle Database構成ファイルを変更することで、Oracle Real Application Clusters (Oracle RAC)環境でTransport Layer Security (TLS)接続を構成できます。

親トピック: Transport Layer Security暗号化の構成

21.11.1 ステップ1: TCPSプロトコル・エンドポイントの構成

Oracle Real Application Clusters (Oracle RAC)では、クライアントは3つのSCANリスナーのいずれかにアクセスし、それからデータベース・リスナーにルーティングされます。Transport Layer Security (TLS)をサポートするには、これらのリスナーすべてにTCPSプロトコル・エンドポイントが必要です。

  1. Oracle RACデータベースをホストするクラスタにログインします。
  2. リスナー・リソースをチェックして、TCPエンドポイントをサポートしているかどうかを確認します。
    例:
    $ srvctl config listener -h

    次のような出力が表示されます。

    Name: LISTENER
Subnet: 192.0.2.195
Type: type
Owner: pfitch
Home: Grid_home
End points: TCP:1521

    次のコマンドは、スキャン・リスナーに関する情報を表示します。

    $ srvctl config scan_listener -h

    次のような出力が表示されます。

    SCAN Listener LISTENER_SCAN1 exists. Port: TCP:1529
Registration invited nodes:
Registration invited subnets:
SCAN Listener is enabled.
SCAN Listener is individually enabled on nodes:
SCAN Listener is individually disabled on nodes:
  3. データベース・リスナーにTCPSエンドポイントを追加します。
    例:
    $ srvctl modify listener -endpoints "TCP:port_1/TCPS:port_2"
  4. リスナー構成を確認します。
    例:
    $ srvctl config listener

Name: LISTENER
Network: 1, Owner: oracle
Home: CRS_home
End points: TCP:port_1/TCPS:port_2

$ lsnrctl status

Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcps)(HOST=IP_address)(PORT=port_2)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=IP_address)(PORT=port_1)))
  5. スキャン・リスナーにTCPSエンドポイントを追加します。
    例:
    $ srvctl modify scan_listener -endpoints "TCP:port_1/TCPS:port_2"
  6. SCANリスナーの構成を確認します。
    例:
    $ srvctl config scan_listener

SCAN Listener LISTENER_SCAN1 exists. Port: TCP:port_1/TCPS:port_2
SCAN Listener LISTENER_SCAN2 exists. Port: TCP:port_1/TCPS:port_2
SCAN Listener LISTENER_SCAN3 exists. Port: TCP:port_1/TCPS:port_2

$ lsnrctl status listener_scan3

Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER_SCAN3)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=IP_address)(PORT=port_1)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcps)(HOST=IP_address)(PORT=port_2)))

親トピック: Oracle Real Application Clusters環境でのTransport Layer Security接続

21.11.2 ステップ2: 各ノードでLOCAL_LISTENERパラメータが正しく設定されていることの確認

Oracle Agentは、各ノードでLOCAL_LISTENERパラメータを自動的に設定しますが、正しいことを再確認する必要があります。

  1. 任意のOracle Real Application Clusters (Oracle RAC)ノードにログインします。
  2. SQL*Plusで、SYSDBA管理権限を持つユーザーとして、LOCAL_LISTENERパラメータを確認します。
    show parameter local_listener;

    次のような出力が表示されます。

    NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
local_listener                       string      (DESCRIPTION=(ADDRESS_LIST=
                                                 (ADDRESS=(PROTOCOL=TCPS)(HOST=IP_address)
                                                 (PORT=port_2))))
  3. 出力が希望と異なる場合は、各Oracle RACインスタンスを再起動します。

親トピック: Oracle Real Application Clusters環境でのTransport Layer Security接続

21.11.3 ステップ3: Transport Layer Securityウォレットおよび証明書の作成

クラスタ用、およびTLS経由でクラスタに接続するクライアント用のTransport Layer Security (TLS)ウォレットおよび証明書を作成する必要があります。

親トピック: Oracle Real Application Clusters環境でのTransport Layer Security接続

21.11.3.1 証明書が必要なOracle Real Application Clustersコンポーネント

Oracle Real Application Clusters (Oracle RAC)の特定のコンポーネントでは、Transport Layer Security (TLS)接続を構成するときに証明書が必要です。

  • 各クラスタ・ノード(サーバー)およびリスナーには、ユーザー証明書およびCA証明書を含むウォレットが必要です。
  • 一方向のTLSが構成されている場合、クライアントはリスナーおよびサーバーのCA証明書(ウォレットまたはシステムの証明書ストア内)のみを必要とします。
  • mTLSが構成されている場合、クライアントには、ユーザー証明書とリスナーおよびサーバーのCA証明書を含むウォレットが必要です。
21.11.3.2 ステップ3: Transport Layer Securityウォレットおよび証明書の作成

Transport Layer Securityウォレットおよび証明書を作成するには、最初にルートCA証明書を作成し、次にクラスタ・ウォレットおよびクライアント・ウォレットを作成します。

  1. ルートCA証明書を作成します。
    1. 任意のOracle Real Application Clusters (Oracle RAC)クラスタ・ノードにログインします。
    2. orapkiユーティリティを使用して、CAのディレクトリにCAウォレットを作成します。
      $ orapki wallet create -wallet CA_home_wallet_file_directory
    3. CAウォレット用の自己署名ルート証明書を作成します。
      例:
      $ orapki wallet add -wallet CA_home_wallet_file_directory -self_signed -dn "CN=test CA,O=test,C=c" -keysize 2048 -validity 3650 -sign_alg sha256
Enter wallet password: password
    4. ウォレットからルートCA証明書を抽出します。
      このルート証明書はクラスタ・ウォレットまたはクライアント・ウォレットで信頼できるCA証明書として使用され、PKCS#12ウォレットを作成するユーザーに対し配布または公開できます。例:
      $ orapki wallet export -wallet CA_home_wallet_file_directory -dn "CN=test CA,O=test,C=c" -cert testCAroot.cer
Enter wallet password: password

      この段階で、CA_home_wallet_file_directoryディレクトリには新しいウォレット(ewallet.p12)と証明書(testCAroot.cer)が含まれます。

      構成を確認するには:

       $ orapki wallet display -wallet CA_home_wallet_file_directory -summary

      次のような出力が表示されます。

      Requested Certificates:
User Certificates:
Subject:        CN=test CA,O=test,C=c
Trusted Certificates:
Subject:        CN=test CA,O=test,C=c
  2. クラスタ・ウォレットを作成します。
    次に、この手順の残りのステップに従って、ユーザー証明書リクエストに署名し、使用している環境の様々なエンティティおよびプロセスに対して承認されたデジタル・ユーザー証明書を提供する準備ができます。テスト環境内で公開キー・インフラストラクチャ機能に関与している各エンティティに対してこの手順を繰り返します。有効なウォレットは、ルートCA証明書および署名付きユーザー証明書で構成されます。
    1. CAホーム・ディレクトリとは異なる場所にウォレットを作成します。
      例:
      $ orapki wallet create -wallet cluster_wallet_file_directory
Enter password: password
Enter password again: password
    2. ユーザー・アイデンティティ(ユーザーdn)および証明書リクエストを作成します。
      例:
      $ orapki wallet add -wallet cluster_wallet_file_directory -dn "CN=testuser" -keysize 2048
Enter wallet password: password
$ orapki wallet export -wallet cluster_wallet_file_directory -dn "CN=testuser" -request cluster_wallet_file_directory/testuser.req
Enter wallet password: password

      この段階では、cluster_wallet_file_directoryディレクトリにSSOウォレット(cwallet.sso)、ウォレット(ewallet.p12)および証明書リクエスト(testuser.req)が含まれます。証明書リクエストは、前述で生成されたCAによって署名されます。

      例: 

      $ orapki cert create -wallet cluster_wallet_file_directory -request cluster_wallet_file_directory/testuser.req -cert user_wallet_file_directory/testuser.cer -validity 3650 -sign_alg sha256
Enter wallet password: password

      これで、cluster_wallet_file_directoryディレクトリにtestuser.req証明書リクエスト・ファイルが含まれます。

    3. ルート証明書(testCAroot.cer)および署名付きユーザー証明書(testuser.cer)をユーザー・ウォレットにインポートします。
      例:
      $ orapki wallet add -wallet cluster_wallet_file_directory -trusted_cert -cert CA_home_wallet_file_directory/testCAroot.cer -pwd
Enter wallet password: user_password
$ orapki wallet add -wallet cluster_wallet_file_directory -user_cert -cert cluster_wallet_file_directory/testuser.cer
Enter wallet password: user_password
    4. 完成したクラスタ・ウォレットを確認します。
      例:
      $ orapki wallet display -wallet cluster_wallet_file_directory -summary

Requested Certificates:
User Certificates:
Subject:        CN=testuser
Trusted Certificates:
Subject:        CN=test CA,O=test,C=c

      この時点で、完成したクラスタ・ウォレットをクラスタの各ノードにコピーする準備ができます。

  3. クライアント・ウォレットを作成します。
    1. ルート証明書(testCAroot.cer)を使用してクライアント・ウォレットを作成します。
      TLS接続を成功させるには、クライアントはサーバーの証明書のCA証明書のみが必要です。
      例:
      $ orapki wallet create -wallet client_wallet_file_directory -auto_login
$ orapki wallet add -wallet client_wallet_file_directory -trusted_cert -cert CA_home_wallet_file_directory/testCAroot.cer
    2. 完成したクライアント・ウォレットを確認します。
      例:
      $ orapki wallet display -wallet client_wallet_file_directory -summary

Requested Certificates:
User Certificates:
Trusted Certificates:
Subject:        CN=test CA,O=test,C=c

21.11.4 ステップ4: Oracle RACクラスタの各ノードでのウォレットの作成

クラスタ・ウォレットを作成した後、それをOracle Real Applications (Oracle RAC)クラスタの各ノードにコピーできます。

各ノードが、Oracle Real Application Clusters (Oracle RAC)データベース・サーバー(プロセス・モニター)と、通常はGIホームから実行されるスキャン・リスナーおよびローカル・リスナーの両方からアクセスできることを確認します。
  1. 前のセクションで作成したPKCS#12ウォレット(ewallet.p12)ファイルをクラスタ内の各ノードにコピーします。
  2. 各ノードで、自動ログイン・ウォレット(cwallet.sso)を作成します。
    cwallet.ssoファイルは、ewallet.p12の不明瞭化されたミラー・コピーであり、データベース・サーバーとそのリスナーがアクセスするファイルです。Oracle RACクラスタにcwallet.ssoを作成する場合は、これをewallet.p12ファイルとともに各ノードのウォレット・ディレクトリにコピーできます。また、ewallet.p12ファイルがすでに配置されている場合は、各ノードにcwallet.ssoファイルを個別に作成することもできます。ewallet.p12ファイルと同じ場所で次のコマンドを実行します:
    $ orapki wallet create -wallet wallet_file_location -auto_login
Enter wallet password: ewallet_password

関連トピック

親トピック: Oracle Real Application Clusters環境でのTransport Layer Security接続

21.11.5 ステップ5: listener.oraおよびsqlnet.oraファイルでのウォレット・ロケーションの定義

データベース・サーバーおよびリスナーがウォレットにアクセスできるようにするには、listener.oraおよびsqlnet.oraファイルにウォレットの場所を定義する必要があります。

  1. すべてのノードのGridホームにあるlistener.oraファイルを変更します。
    SSL_CLIENT_AUTHENTICATION = FALSE

WALLET_LOCATION =
  (SOURCE =
    (METHOD = FILE)
    (METHOD_DATA =
      (DIRECTORY = wallet_file_location)
  2. 各クラスタ・ノードのOracle DatabaseホームおよびGridホームのsqlnet.oraファイルに、次の情報を追加します。
    SQLNET.AUTHENTICATION_SERVICES = (BEQ, TCP, TCPS)

SSL_CLIENT_AUTHENTICATION = FALSE

WALLET_LOCATION =
  (SOURCE =
    (METHOD = FILE)
    (METHOD_DATA =
      (DIRECTORY = wallet_file_location)
    )
  )

親トピック: Oracle Real Application Clusters環境でのTransport Layer Security接続

21.11.6 ステップ6: データベース・インスタンスおよびリスナーの再起動

ウォレットを配置して*.oraファイルを編集した後、データベース・サーバーおよびリスナー・プロセスを再起動して新しい設定を取得する必要があります。

再起動プロセスにより、前にLOCAL_LISTENERパラメータを設定したOracle Real Application Clusters (Oracle RAC)インスタンスも有効になります。
  • 任意のクラスタ・ノードで、srvctlユーティリティを使用して、データベース・サーバーおよびリスナー・プロセスを再起動します。
    例:
    $ srvctl stop listener
$ srvctl start listener

$ srvctl stop scan_listener
$ srvctl start scan_listener

$ srvctl stop database -d db_name 
$ srvctl start database -d db_name

親トピック: Oracle Real Application Clusters環境でのTransport Layer Security接続

21.11.7 ステップ7: クラスタ・ノード構成のテスト

クラスタ・ノード構成をテストするには、ノードの接続記述子を作成し、このノードへの接続を試行します。

  1. 任意のクラスタ・ノードで、スキャン・リスナーTCPSエンドポイントを使用する接続記述子をtnsnames.oraファイルに作成します。
    たとえば、dbsslというTCPSエンドポイントの場合:
    DBSSL =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCPS)(HOST = scan_name)(PORT = port_2))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = service_name)
    )
  )
  2. SQL*Plusを使用して、このTCPSエンドポイントへの接続を試みます。
    例:
    sqlplus user_name/@dbssl
Enter password: password

親トピック: Oracle Real Application Clusters環境でのTransport Layer Security接続

21.11.8 ステップ8: リモート・クライアント構成のテスト

Oracle Real Applications (Oracle RAC)クラスタ・ノードでウォレットをテストした後、リモート・クライアント構成をテストする準備ができます。

  1. クラスタ・ノード上のすべてのリモート・クライアントsqlnet.oraファイルで、ウォレット・ディレクトリを定義します。
    WALLET_LOCATION =
  (SOURCE =
    (METHOD = FILE)
    (METHOD_DATA =
      (DIRECTORY = wallet_file_location)
    )
  )
  2. 前にSSLウォレットおよび証明書を作成したときに作成したクライアント・ウォレットを、クライアント・ウォレット・ディレクトリに移動します。
    $ wallet create -wallet wallet_file_location -auto_login
Enter wallet password: password

    wallet_file_locationには、ewallet.p12ファイルとcwallet.ssoファイルが必要です。

  3. tnsnames.oraファイルに、スキャン・リスナーのTCPSエンドポイントを使用する接続記述子を作成します。
    例:
    DBSSL =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCPS)(HOST = scan_name)(PORT = port_2))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = service_name)
    )
  )
  4. SQL*Plusを使用して、このTCPSエンドポイントへの接続を試みます。
    例:
    sqlplus user_name/@dbssl
Enter password: password

親トピック: Oracle Real Application Clusters環境でのTransport Layer Security接続

21.12 Microsoft証明書ストアを使用したクライアント認証および暗号化のためのトランスポート・レイヤー・セキュリティの構成

この構成をMicrosoft Certificate Store (MCS)で実行するには、orapkiコマンドライン・ツールを使用して証明書を生成し、Oracleウォレットを操作します。

親トピック: Transport Layer Security暗号化の構成

21.12.1 Microsoft証明書ストアを使用したクライアント認証および暗号化のためのトランスポート・レイヤー・セキュリティの構成について

このタイプの構成は、Common Access CardおよびPIVカード認証の基盤です。

Common Access CardおよびPIVカードとともに提供されるソフトウェア・ライブラリが、必要な証明書を透過的にMicrosoft証明書ストアにロードできるかぎり、構成するTransport Layer Security (TLS)認証は透過的に実行されます。

PIVカードにロードされるユーザー証明書のすべての署名証明書は、サーバー・レベルのTLS構成の一部としてサーバーのウォレットに手動でロードする必要があることに注意してください。

親トピック: Microsoft証明書ストアを使用したクライアント認証および暗号化のためのトランスポート・レイヤー・セキュリティの構成

21.12.2 ステップ1: サーバー・ウォレットの作成および構成

サーバー・ウォレットおよびサーバーの自己署名証明書を作成するには、orapkiを使用する必要があります。

  1. Oracle Databaseサーバーにログインします。
  2. サーバー・ウォレットのディレクトリを作成します。
    例:
    mkdir /home/oracle/wallet_tls/server
  3. このディレクトリに移動します。
    cd /home/oracle/wallet_tls/server
  4. サーバー・ウォレットを作成します。
    orapki wallet create -wallet . -auto_login -pwd password
  5. ディレクトリを確認します。
    例:
    ls -la

    次のような出力が表示されます。

    total 16
drwxr-xr-x. 2 oracle oinstall 4096 Oct 28 07:18 .
drwxr-xr-x. 6 oracle oinstall 4096 Oct 28 07:17 ..
-rw-------. 1 oracle oinstall 120 Oct 28 07:18 cwallet.sso
-rw-rw-rw-. 1 oracle oinstall 0 Oct 28 07:18 cwallet.sso.lck
-rw-------. 1 oracle oinstall 75 Oct 28 07:18 ewallet.p12
-rw-rw-rw-. 1 oracle oinstall 0 Oct 28 07:18 ewallet.p12.lck
  6. サーバーの自己署名証明書を作成します。
    orapki wallet add -wallet . -dn "cn=server" -self_signed -keysize 2048 -sign_alg sha256 -validity 365 -pwd password

親トピック: Microsoft証明書ストアを使用したクライアント認証および暗号化のためのトランスポート・レイヤー・セキュリティの構成

21.12.3 ステップ2: クライアント・ウォレットの作成および構成

クライアント・ウォレットおよび証明書リクエストを作成するには、orapkiを使用する必要があります。

  1. Oracle Databaseクライアントにログインします。
  2. クライアント・ウォレットのディレクトリを作成します。
    例:
    mkdir /home/oracle/wallet_tls/client
  3. このディレクトリに移動します。
    cd /home/oracle/wallet_tls/client
  4. クライアント・ウォレットを作成します。
    orapki wallet create -wallet . -auto_login -pwd password
  5. ユーザー証明書のリクエストを作成し、リクエストをエクスポートします。
    orapki wallet add -wallet . -dn "cn=client" -keysize 2048 -sign_alg sha256 -pwd password
orapki wallet export -wallet . -dn "cn=client" -request req.txt -pwd password
  6. クライアント・ディレクトリからサーバー・ディレクトリに証明書リクエストをコピーします。
    例: 
    cp req.txt ../server/
cd ../server/
  7. クライアントの証明書に署名し、サーバーのCA証明書もエクスポートします。
    例:
    orapki cert create -wallet . -request req.txt -cert sign.txt -validity 1000 -pwd password
orapki wallet export -wallet . -dn "cn=server" -cert server.txt
cp server.txt ../client
cp sign.txt ../client
orapki wallet add -wallet . -trusted_cert -cert server.txt -pwd password
orapki wallet add -wallet . -user_cert -cert sign.txt -pwd password
cp sign.txt server.txt ../client/
cd ../client

親トピック: Microsoft証明書ストアを使用したクライアント認証および暗号化のためのトランスポート・レイヤー・セキュリティの構成

21.12.4 ステップ3: Oracle Databaseでの外部ユーザーの作成

クライアントおよびサーバー接続で使用する外部ユーザーを作成する必要があります。

  1. ユーザーを作成して権限を付与できるユーザーとして、この外部ユーザー・アカウントを使用するPDBにログインします。
  2. 外部ユーザーを作成します。
    例:
    CREATE USER tlsuser IDENTIFIED EXTERNALLY AS 'cn=client';
  3. このアカウントにCONNECT権限を付与します。 
    GRANT CONNECT TO tlsuser;

親トピック: Microsoft証明書ストアを使用したクライアント認証および暗号化のためのトランスポート・レイヤー・セキュリティの構成

21.12.5 ステップ4: サーバーのlistener.oraファイルの構成

次に、サーバーのlistener.oraファイルを確認してから再起動する必要があります。

  1. Oracle Databaseサーバーにログインします。
  2. サーバーのlistener.oraファイルをチェックして、正しく構成されていることを確認します。
    例:
     cat /u01/app/oracle/product/release/dbhome_1/network/admin/listener.or

    次のような出力が表示されます。

    LISTENERBOS =
     (DESCRIPTION_LIST =
       (DESCRIPTION =
         (ADDRESS = (PROTOCOL = TCP)(HOST = domain.com)(PORT = 1529))
        )
       (DESCRIPTION =
         (ADDRESS = (PROTOCOL = TCPS)(HOST = domain.com)(PORT = 1530))
         )
       )
WALLET_LOCATION =
      (SOURCE =
        (METHOD = File)
          (METHOD_DATA =
           (DIRECTORY = /home/oracle/wallet_tls/server))
  3. リスナーを再起動し、データベースがこのリスナーに登録されているかどうかを確認します。
    su - oracle
./lsnrctl start

    次のような出力が表示されます。

    Listener Parameter File /u01/app/oracle/product/release/dbhome_1/network/admin/listener.ora
Listener Log File /u01/app/oracle/diag/tnslsnr/service/instance/alert/log.xml
Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=domain.com)(PORT=1523)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcps)(HOST=domain.com)(PORT=1525)))
  Services Summary...
   Service "service" has 1 instance(s).
    Instance "instance", status READY, has 1 handler(s) for this service...
   Service "serviceDB" has 1 instance(s).
    Instance "instance", status READY, has 1 handler(s) for this service...
 The command completed successful

親トピック: Microsoft証明書ストアを使用したクライアント認証および暗号化のためのトランスポート・レイヤー・セキュリティの構成

21.12.6 ステップ5: サーバーのsqlnet.oraファイルの構成

sqlnet.oraファイルが、前に作成したサーバー・ウォレットを指していることを確認する必要があります。

  1. Oracle Databaseサーバーにログインします。
  2. sqlnet.oraファイルを確認して、サーバー・ウォレットを指していることを確認します。
    例:
    NAMES.DIRECTORY_PATH=(TNSNAMES)
SQLNET.AUTHENTICATION_SERVICES=(BEQ,TCPS)
SSL_CLIENT_AUTHENTICATION = TRUE 
WALLET_LOCATION =
 (SOURCE =
  (METHOD = FILE)
    (METHOD_DATA =
      (DIRECTORY = /home/oracle/wallet_tls/server)
    )
)

親トピック: Microsoft証明書ストアを使用したクライアント認証および暗号化のためのトランスポート・レイヤー・セキュリティの構成

21.12.7 ステップ6: Microsoft証明書ストアへのクライアント・ウォレットのインポート

このインポート操作を実行するには、Microsoft管理コンソール(MMC)を使用する必要があります。

  1. MMC (mmc.exe)を起動します。
  2. 「ファイル」、「スナップインの追加と削除」の順に選択します。
  3. 「証明書」、「追加」の順に選択します。
  4. 「ユーザー アカウント」、「完了」、「OK」の順に選択します。
  5. 「コンソール ルート」、「証明書 - 現在のユーザー」、「個人」、「証明書」の順に移動します。
  6. 「すべてのタスク」を右クリックし、「インポート」、「次へ」、「参照」の順に選択します。
  7. 接続に必要な証明書が含まれている証明書ファイル(ewallet.p12など)を選択します。
  8. 「開く」、「次へ」の順に選択します。
  9. ウォレットのパスワードを入力します。
  10. 「このキーをエクスポート可能としてマークする」チェック・ボックスを選択します。
  11. 「すべての拡張プロパティを含める」チェック・ボックスを選択します。
  12. 「すべての証明書を次のストアに配置する: 個人」を選択します。
  13. 「次へ」、「完了」の順に選択します。
  14. 「コンソール ルート」に移動してから、「証明書 - 現在のユーザー」、「個人」、「証明書」の順に選択して、クライアントの証明書がMYストアに追加されていることを確認します。
  15. 「コンソール ルート」に移動してから、「証明書 - 現在のユーザー」、「信頼されたルート証明機関」、「証明書」の順に選択して、CA証明書がROOTストアに追加されていることを確認します。

親トピック: Microsoft証明書ストアを使用したクライアント認証および暗号化のためのトランスポート・レイヤー・セキュリティの構成

21.12.8 ステップ7: クライアントのsqlnet.oraファイルの構成

クライアント・ウォレットにMicrosoft証明書ストアを使用するようにクライアントのsqlnet.oraファイルを構成する必要があります。

  1. Oracle Databaseクライアントにログインします。
  2. クライアント側のsqlnet.oraファイルを確認します。
    例:
    WALLET_LOCATION = (SOURCE = (METHOD=MCS))

親トピック: Microsoft証明書ストアを使用したクライアント認証および暗号化のためのトランスポート・レイヤー・セキュリティの構成

21.12.9 ステップ8: Oracle Databaseの構成

Oracleデータベースで、OS_AUTHENT_PREおよびREMOTE_OS_AUTHパラメータを構成します。

  1. ALTER SYSTEMシステム権限を持つユーザーとして、Oracle DatabaseサーバーでSQL*Plusにログインします。
  2. OS_AUTHENT_PREおよびREMOTE_OS_AUTHパラメータを設定します。 
    ALTER SYSTEM SET REMOTE_OS_AUTHENT=FALSE SCOPE=SPFILE;
ALTER SYSTEM SET OS_AUTHENT_PREFIX='' SCOPE=SPFILE;
  3. データベース・インスタンスを再起動します。

親トピック: Microsoft証明書ストアを使用したクライアント認証および暗号化のためのトランスポート・レイヤー・セキュリティの構成

21.12.10 ステップ9: クライアントおよびサーバー接続のテスト

Microsoft証明書ストアの構成が完了したら、およびサーバー接続をテストする必要があります。

  1. TLS接続にMCSが使用されていることを確認するには、クライアントのsqlnet.oraファイルに次の行を追加することでクライアント・トレースを有効にします。
    trace_level_client=16
trace_directory_client=trace_directory
DIAG_ADR_ENABLED=OFF
  2. SQL*Plusを使用してサーバーに接続してから、証明書がMCSから正常にロードされていることを確認します。
    nztwOpenWallet: [enter]
nztwOpenWallet: WRL mcs:, type = 24
nztwOpenWallet: Loading the EXTKS provider for MCS type wallet
nztwOpenWallet: [exit] OK

親トピック: Microsoft証明書ストアを使用したクライアント認証および暗号化のためのトランスポート・レイヤー・セキュリティの構成

21.13 証明書失効リストによる証明書の検証

オラクル社では、証明書失効リストを使用して証明書を検証できるツールを提供しています。

親トピック: Transport Layer Security暗号化の構成

21.13.1 証明書失効リストによる証明書検証について

指定の証明書を指定のコンテキストで使用できるかどうかを判定するプロセスは、証明書の検証と呼ばれます。

証明書の検証には、次が該当するかどうかの判定が含まれます。

  • 信頼できる認証局(CA)にデジタル署名された証明書があるかどうか。

  • 証明書のデジタル署名が、証明書自体の別個に計算されたハッシュ値および証明書の署名者の(CAの)公開キーに対応しているかどうか。

  • 証明書が期限切れになっていないかどうか。

  • 証明書が失効していないかどうか。

Transport Layer Securityネットワーク・レイヤーは、自動的に最初の3つの検証チェックを実行しますが、証明書が失効していないことを確認するには、証明書失効リスト(CRL)のチェックを構成する必要があります。CRLは、失効した証明書のリストを含む署名付きデータ構造体です。これは通常、元の証明書を発行したエンティティと同じエンティティによって発行され署名されます。

親トピック: 証明書失効リストによる証明書の検証

21.13.2 使用するCRLの選択方法

使用するトラスト・ポイントすべてについてCRLが必要です。

トラスト・ポイントは、一定の信頼レベルで資格を与えられたサード・パーティ・アイデンティティからの信頼できる証明書です。

通常、信頼する認証局はトラスト・ポイントと呼ばれます。

親トピック: 証明書失効リストによる証明書の検証

21.13.3 CRLチェックの動作の仕組み

Oracle Databaseでは証明書の失効状態をCRLに照らして確認します。

CRLはファイル・システム・ディレクトリ(Oracle Internet Directory)に存在するか、または証明書のCRL配布ポイント(CRL DP)拡張で指定された場所からダウンロードして入手します。

通常、CRL定義は数日間有効です。CRLをローカル・ファイル・システムまたはディレクトリに格納する場合、CRLを定期的に更新する必要があります。 CRL配布ポイント(CRL DP)を使用する場合、証明書が使用されるたびにCRLがダウンロードされるため、CRLを定期的に更新する必要はありません。

サーバーは、次の場所で(ここに示されている順番で)CRLを検索します。システムは、証明書のCAのDNと一致するCRLを検出すると、検索を停止します。

  1. ローカル・ファイル・システム

    システムは、まずsqlnet.oraファイルのSSL_CRL_FILEパラメータを確認し、それからSSL_CRL_PATHパラメータを確認します。システムは、これらの2つのパラメータが指定されていない場合、ウォレット・ロケーションで任意のCRLをチェックします。

    ノート: CRLをローカル・ファイル・システムに格納する場合、orapkiユーティリティを使用してCRLを定期的に更新する必要があります(証明書検証用ハッシュ値によるCRLの名前変更など)。

  2. Oracle Internet Directory

    サーバーは、ローカル・ファイル・システムでCRLを検出できず、ldap.oraファイルでディレクトリ接続情報が構成されている場合、このディレクトリを検索します。これは、CAの識別名(DN)およびCRLサブツリーのDNを使用してCRLサブツリーを検索します。

    ディレクトリでCRLを検索するためには、サーバーに、適切に構成されたldap.oraファイルが存在している必要があります。Oracle Internet Directoryのドメイン・ネーム・システム(DNS)検出機能は使用できません。また、CRLをディレクトリに格納する場合、orapkiユーティリティを使用してCRLを定期的に更新する必要があることに注意してください。

  3. CRL DP

    CAが、証明書が発行されたときのCRL DP X.509、バージョン3、証明書拡張子内の位置を指定すると、その証明書用の失効情報を含む適切なCRLがダウンロードされます。現在、Oracle Databaseは、LDAPを介したCRLのダウンロードをサポートしています。

    次のことに注意してください。

    • パフォーマンス上の理由から、ユーザー証明書のみがチェックされます。

    • CRLをローカル・ファイル・システムではなくディレクトリに格納することをお薦めします。

関連トピック

親トピック: 証明書失効リストによる証明書の検証

21.13.4 証明書失効リストによる証明書検証の構成

sqlnet.oraファイルを編集して、証明書失効リストによる証明書検証を構成できます。

親トピック: 証明書失効リストによる証明書の検証

21.13.4.1 証明書失効リストによる証明書検証の構成について

証明書失効ステータス・チェックを有効にするには、sqlnet.oraファイルでSSL_CERT_REVOCATIONパラメータをREQUIREDまたはREQUESTEDに設定する必要があります。

証明書失効ステータス・チェックを有効にするには、sqlnet.oraファイルでSSL_CERT_REVOCATIONパラメータをREQUIREDまたはREQUESTEDに設定する必要があります。

デフォルトでは、このパラメータはNONEに設定され、証明書失効ステータス・チェックはオフになっています。

ノート:

CRLをローカル・ファイル・システムまたはOracle Internet Directoryに格納する場合は、コマンドライン・ユーティリティorapkiを使用して、ファイル・システム内のCRLの名前を変更するか、CRLをディレクトリにアップロードします。

21.13.4.2 クライアントまたはサーバー用の証明書失効ステータス・チェックの有効化

クライアントまたはサーバー用の証明書失効ステータス・チェックを有効にできます。

  1. Oracle Databaseサーバーにログインします。
  2. sqlnet.oraファイルでSSL_CERT_REVOCATIONパラメータを変更します。
    SSL_CERT_REVOCATION=value

    この指定では、valueは次の設定のいずれかになります。

    • required: 証明書失効ステータス・チェックが必須です。証明書が失効しているかCRLが見つからない場合、TLS接続は拒否されます。証明書がまだ失効していないことが確認された場合にのみ、TLS接続は許可されます。
    • requested: CRLが使用可能な場合に、証明書失効ステータス・チェックを実行します。証明書が失効している場合、TLS接続は拒否されます。CRLが見つからない場合や、証明書がまだ失効していない場合、TLS接続は許可されます。パフォーマンス上の理由から、ユーザー証明書の失効のみがチェックされます。
  3. CRLがローカル・ファイル・システムに格納されている場合は、次のsqlnet.oraパラメータの一方または両方を設定して、格納場所を指定します。
    • SSL_CRL_PATHは、CRLが格納されているディレクトリへのパスを設定します。この設定を省略すると、デフォルトはウォレット・ディレクトリになります。DERエンコードされた(バイナリ形式) CRLおよびPEMエンコードされた(BASE64) CRLの両方がサポートされています。CRLをローカル・ファイル・システム・ディレクトリに格納する場合は、orapkiユーティリティを使用して、システムが特定できるようにCRLの名前を変更する必要があります。
    • SSL_CRL_FILEは、包括的CRLファイル(PEMエンコードされた(BASE64) CRLが優先度の順に1つのファイルに連結されたもの)へのパスを設定します。ファイルが指定の場所に存在するか、アプリケーションを起動できないことを確認します。
  4. Oracle Internet DirectoryからCRLをフェッチする場合は、ldap.oraファイルを編集してディレクトリ・サーバーおよびポートの情報を含めます。

    ldap.oraファイルを構成する場合は、ディレクトリに非TLSポートのみを指定する必要があります。CRLダウンロードはTLSプロトコルの一部として実行され、TLS接続内でのTLS接続の確立はサポートされません。

    Oracle Internet Directoryの非TLSポートが無効になっている場合、Oracle DatabaseのCRL機能は動作しません。

  5. Oracle Databaseクライアントのsqlnet.oraファイルに対して、これらのステップを繰り返します。
21.13.4.3 証明書失効ステータス・チェックの無効化

証明書失効ステータス・チェックを無効にできます。

  1. Oracle Databaseサーバーにログインします。
  2. sqlnet.oraファイルでSSL_CERT_REVOCATIONパラメータを次のように変更します。
    SSL_CERT_REVOCATION=NONE
  3. Oracle Databaseクライアントに対してこのステップを繰り返します。

21.13.5 証明書失効リストの管理

証明書失効リストの管理では、証明書失効チェックを有効にする前に、CRLが正しい書式であることを確認する必要があります。

親トピック: 証明書失効リストによる証明書の検証

21.13.5.1 証明書失効リストの管理について

Oracle Databaseには、証明書の管理を実行するために使用できるコマンドライン・ユーティリティorapkiがあります。

証明書失効ステータス・チェックを有効にするには、まず、使用するCAから受信したCRLがコンピュータで使用できるフォームである(ハッシュ値で名前変更されている)こと、またはコンピュータで使用できる場所にある(ディレクトリにアップロードされている)ことを確認してください。

LDAPコマンド行ツールを使用して、Oracle Internet DirectoryでCRLを管理することもできます。

ノート:

CRLは、正常な検証を行うために、(期限切れになる前に)定期的に更新する必要があります。このタスクは、スクリプトでorapkiコマンドを使用して自動化できます。

21.13.5.2 CRLを管理するコマンドのorapkiヘルプの表示

CRLの管理に使用可能なorapkiコマンドをすべて表示できます。

  • CRLの管理に使用可能なorapkiコマンドとそのオプションをすべての表示するには、コマンドラインに次のように入力します。 

    orapki crl help

ノート:

-summary、-completeまたは-walletコマンド・オプションの使用は、常にオプションです。これらのコマンド・オプションが指定されていなくても、コマンドは実行されます。

21.13.5.3 証明書検証用ハッシュ値によるCRLの名前変更

システムは、証明書を検証するとき、証明書を作成したCAが発行するCRLを見つける必要があります。

システムは、証明書の発行者名とCRLにある発行者名を照合して適切なCRLを検出します。

Oracle Net Managerの「証明書失効リスト・パス」フィールドにCRL格納場所を指定する(sqlnet.oraファイルのSSL_CRL_PATHパラメータを設定する)場合、orapkiユーティリティを使用して発行者名を表すハッシュ値を使用してCRLを名前変更します。ハッシュ値を作成すると、サーバーでCRLをロードできます。

UNIXオペレーティング・システムでは、orapkiによってCRLへのシンボリック・リンクが作成されます。Windowsオペレーティング・システムでは、CRLファイルのコピーが作成されます。どちらの場合も、orapkiによって作成されたシンボリック・リンクまたはコピーは、発行者名のハッシュ値を使用して名前が付けられます。その後、システムが証明書を検証するとき、同じハッシュ関数が使用されて、適切なCRLをロードできるようにリンク(またはコピー)の名前が計算されます。

  • オペレーティング・システムに応じて、次のコマンドのいずれかを入力して、ファイル・システムに格納されているCRLの名前を変更します。

    • UNIXファイル・システムに格納されているCRLの名前を変更するには:

      orapki crl hash -crl crl_filename [-wallet wallet_location] -symlink crl_directory [-summary]

    • Windowsファイル・システムに格納されているCRLの名前を変更するには:

      orapki crl hash -crl crl_filename [-wallet wallet_location] -copy crl_directory [-summary]

この指定では、crl_filenameはCRLファイルの名前、wallet_locationはCRLを発行したCAの証明書を含むウォレットの場所、crl_directoryはCRLがあるディレクトリです。

-walletおよび-summaryの使用はオプションです。-walletを指定すると、CRLの名前を変更する前に、ツールによってCAの証明書に対するCRLの有効性が確認されます。-summaryオプションを指定すると、ツールによってCRL発行者名が表示されます。

21.13.5.4 Oracle Internet DirectoryへのCRLのアップロード

ディレクトリでCRLを発行すると、企業全体でのCRL検証が可能になり、個々のアプリケーションに固有のCRLを構成する必要がなくなります。

すべてのアプリケーションで、一元的に管理可能なディレクトリに格納されたCRLを使用できるので、CRL管理および使用の管理オーバーヘッドが大幅に減ります。orapkiを使用してディレクトリにCRLをアップロードするユーザーは、ディレクトリ・グループCRLAdmins(cn=CRLAdmins,cn=groups,%s_OracleContextDN%)のメンバーである必要があります。これらのCRLには企業全体でアクセスできるため、これは特権操作です。この管理ディレクトリ・グループに追加するには、ディレクトリ管理者に連絡してください。

  • CRLをディレクトリにアップロードするには:

    orapki crl upload -crl crl_location -ldap hostname:ssl_port -user username [-wallet wallet_location] [-summary]

    この指定では、crl_locationはCRLがあるファイル名またはURL、hostnameおよびssl_port (認証なしのTLSポート)はディレクトリがインストールされているシステムに対するもの、usernameはCRLをCRLサブツリーに追加する権限があるディレクトリ・ユーザー、wallet_locationはCRLを発行したCAの証明書を含むウォレットの場所です。

-walletおよび-summaryの使用はオプションです。-walletを指定すると、CRLをディレクトリにアップロードする前に、ツールによってCAの証明書に対するCRLの有効性が確認されます。-summaryオプションを指定すると、CRL発行者名、およびCRLがディレクトリに格納されているLDAPエントリがツールによって出力されます。

次の例では、orapkiユーティリティを使用してCRLをアップロードする方法を示しています。 

orapki crl upload -crl /home/user1/wallet/crldir/crl.txt -ldap host1.example.com:3533 -user cn=orcladmin

ノート:

  • orapkiユーティリティを使用すると、この操作の実行時にディレクトリ・パスワードの入力を求めるプロンプトが表示されます。

  • Diffie-HellmanベースのTLSサーバーが実行されているディレクトリのSSLポートを指定していることを確認してください。これは、認証を実行しないTLSポートです。サーバー認証も相互認証TLSポートも、orapkiユーティリティではサポートされていません。

21.13.5.5 Oracle Internet Directoryに格納されているCRLの一覧表示

orapkiを使用してディレクトリに格納されているすべてのCRLのリストを表示できます。特定のCRLを検出してローカル・コンピュータで表示またはダウンロードする際に、このリストを参照すると便利です。

このコマンドを使用すると、CRLを発行したCA(発行者)およびディレクトリのCRLサブツリー内の場所(DN)が表示されます。

  • Oracle Internet DirectoryでCRLを一覧表示するには:

    orapki crl list -ldap hostname:ssl_port
    hostnameおよびssl_portは、ディレクトリがインストールされているシステムに対するものです。これは、前の項で説明した認証なしのディレクトリのSSLポートであることに注意してください。
                                 
    
                              
    • 
                           

                        

                        
                     

                     
                     
                  
21.13.5.6 Oracle Internet DirectoryでのCRLの表示
                     

                     

                        
Oracle Internet Directory CRLは要約された形式で表示できるほか、CRLの失効した証明書のリストを要求することもできます。 

                        
Oracle Internet Directoryに格納されているCRLを要約された形式で表示するか、CRLの失効した証明書の完全なリストを要求できます。サマリー・リストには、CRL発行者名およびその有効期間が記載されています。完全なリストには、そのCRLに含まれるすべての失効した証明書のリストが記載されています。

                        
                        
    
                           
  • Oracle Internet DirectoryでCRLのサマリー・リストを表示するには:
    orapki crl display -crl crl_location [-wallet wallet_location] -summary

    この指定で、crl_locationはディレクトリ内のCRLの場所です。orapki crl listコマンドを使用すると表示されるリストからCRLの位置を貼り付けると便利です。 
                                 
    
                                 
    Oracle Internet Directoryに格納されている指定したCRLに含まれているすべての失効した証明書のリストを表示するには、コマンドラインに次のように入力します。
    orapki crl display -crl crl_location [-wallet wallet_location] -complete
    たとえば、orapkiコマンドを次のように入力します。
                                 
    orapki crl display -crl $T_WORK/pki/wlt_crl/nzcrl.txt -wallet $T_WORK/pki/wlt_crl -complete

    次の出力が生成されます。これには、CRL発行者のDN、発行日、次の更新日、および含まれる失効した証明書が示されます。
    issuer = CN=root,C=us, thisUpdate = Sun Nov 16 10:56:58 PST 2003, nextUpdate = Mon Sep 30 11:56:58 PDT 2013, revokedCertificates = {(serialNo = 153328337133459399575438325845117876415, revocationDate - Sun Nov 16 10:56:58 PST 2003)}
CRL is valid

    -walletオプションを使用すると、orapki crl displayコマンドにより、CAの証明書に対してCRLが検証されます。
                                 
    
                                 
    -completeオプションを選択すると、CRLのサイズによっては、表示に時間がかかる場合があります。
                                 
    
                                 
    Oracle Directory Manager(Oracle Internet Directoryに付属するグラフィカル・ユーザー・インタフェース)を使用して、ディレクトリ内のCRLを表示することもできます。CRLは、次のディレクトリの場所に格納されます。
    cn=CRLValidation,cn=Validation,cn=PKI,cn=Products,cn=OracleContext
    
                           
    • 
                        

                     

                     
                  
21.13.5.7 Oracle Internet DirectoryからのCRLの削除
                     

                     

                        
orapkiを使用してディレクトリからCRLを削除するユーザーは、ディレクトリ・グループCRLAdminsのメンバーである必要があります。
                        

                        
    
                           
  • CRLをディレクトリから削除するには:
    orapki crl delete -issuer issuer_name -ldap host:ssl_port -user username [-summary]
    ここで、issuer_nameはCRLを発行したCAの名前、hostnameおよびssl_portはディレクトリがインストールされているシステムに対するもの、usernameはCRLをCRLサブツリーから削除する権限があるディレクトリ・ユーザーです。このポートは、認証を使用しないディレクトリのSSLポートであることが必要です。 
                                 
    
                                 
    -summaryオプションを使用すると、削除されたCRL LDAPエントリがツールによって印刷されます。
                                 
    
                                 
    たとえば、orapkiコマンドを次のように入力します。
                                 
    orapki crl delete -issuer "CN=root,C=us" -ldap machine1:3500 -user cn=orcladmin -summary

    次の出力が生成されます。これには、ディレクトリ内の削除されたCRLの場所が示されます。
    Deleted CRL at cn=root cd45860c.rN,cn=CRLValidation,cn=Validation,cn=PKI,cn=Products,cn=OracleContext
    
                           
    • 
                        

                     

                     
                  

               
21.13.6 CRL証明書検証のトラブルシューティング
                  

                  

                     
CRLに対して証明書を検証するかどうかを判断するには、Oracle Netトレースを有効にできます。 

                     
CRLを使用して失効した証明書を検証すると、Oracle Netトレース・ファイルに次のエントリが記録され、entryとexitの間にエラー・メッセージは記録されません。
                     
nzcrlVCS_VerifyCRLSignature: entry
nzcrlVCS_VerifyCRLSignature: exit

nzcrlVCD_VerifyCRLDate: entry
nzcrlVCD_VerifyCRLDate: exit

nzcrlCCS_CheckCertStatus: entry
nzcrlCCS_CheckCertStatus: Certificate is listed in CRL
nzcrlCCS_CheckCertStatus: exit


                        
ノート:

                        
証明書検証に失敗した場合は、SSLハンドシェイク時にピアに「ORA-29024: 証明書の検証に失敗しました」というメッセージが表示されます。
                        

                     

                  

                  

                     

                        
関連トピック

                        
                     

                     

                        

                           
親トピック: 証明書失効リストによる証明書の検証

                        

                     

                  

               
21.13.7 証明書検証に関連するOracle Netトレース・ファイルのエラー・メッセージ
                  

                  

                     
証明書検証に関連するトレース・メッセージが生成されます。 

                     
これらのトレースメッセージは、Oracle Netトレース・ファイルのentryエントリとexitエントリの間に記録されることがあります。Oracle SSLは複数の場所でCRLを検索するため、トレースに複数のエラーが記録されることがあります。
                     

                     
エラーの解決方法の詳細は、次の表示される可能性があるエラー・メッセージのリストを確認できます。

                     

                        

                              RSAステータスでCRLの署名検証に失敗しました
                        

                        

                           
原因: CRLの署名を検証できません。
                           

                        

                        

                           
処置: ダウンロードしたCRLがピアのCAによって発行されたものであることと、ダウンロード時に破損しなかったことを確認します。CRLは、orapkiユーティリティによって検証されてから、ハッシュ値で名前が変更されるかディレクトリにアップロードされます。 
                           

                           
CRL管理にorapkiを使用する方法の詳細は、「証明書失効リストの管理」を参照してください。
                           

                        

                        

                              RSAステータスでCRLの日付検証に失敗しました
                        

                        

                           
原因: 現在の時刻が次の更新フィールド内の時刻より後になっています。このエラーは、CRL DPを使用している場合には表示されません。CRLは次の順番で検索されます。
                           

                           
    
                              
  1. 
                                 
    ファイル・システム
    
                              
    2. 
                              
  2. 
                                 
    Oracle Internet Directory
    
                              
    3. 
                              
  3. 
                                 
    CRL DP
    
                              
    4. 
                           

                           
この検索で最初に見つかったCRLが最新であるとはかぎりません。

                        

                        

                           
処置: CRLを最新のコピーで更新します。
                           

                        

                        

                              CRLが見つかりませんでした
                        

                        

                           
原因: 構成されている場所にCRLがありませんでした。構成で証明書検証が必須に指定されている場合、エラーORA-29024が戻されます。
                           

                        

                        

                           
処置: 次のステップを実行して、構成で指定されているCRLの場所が正しいことを確認します。
                           

                           
    
                              
  1. 
                                 
    Oracle Net Managerを使用して、正しいCRLの場所が構成されているかどうかを確認します。証明書失効リストによる証明書検証の構成を参照してください
    
                              
    2. 
                              
  2. 
                                 
    必要に応じて、orapkiユーティリティを使用してシステムで使用するCRLを次のように構成します。
                                 
    
                                 
                              
    3. 
                           

                        

                        

                              Oracle Internet Directoryのホスト名またはポート番号が設定されていません
                        

                        

                           
原因: Oracle Internet Directoryの接続情報が設定されていません。これはリカバリ不能なエラーではありません。続いてCRL DPが検索されます。
                           

                        

                        

                           
処置: CRLをOracle Internet Directoryに格納する場合は、Oracle Net Configuration Assistantを使用して、Oracleホームのldap.oraファイルを作成し、構成します。
                           

                        

                        

                              CRL DPからのCRLのフェッチ: CRLが見つかりません
                        

                        

                           
原因: CRL配布ポイント(CRL DP)を使用してCRLをフェッチできませんでした。このことは、証明書にCRL DP拡張で指定された場所がないか、CRL DP拡張で指定されたURLが正しくない場合に発生します。
                           

                        

                        

                           
処置: 認証局が証明書のCRL DP拡張で指定されたURLにCRLを発行することを確認します。
                           

                           
CRLを手動でダウンロードします。次に、それをローカル・ファイル・システムに格納するか、Oracle Internet Directoryに格納するかに応じて、次のステップを実行します。

                           
CRLをローカル・ファイル・システムに格納する場合:

                           
    
                              
  1. 
                                 
    Oracle Net Managerを使用して、CRLディレクトリまたはファイルへのパスを指定します。証明書失効リストによる証明書検証の構成を参照してください
    
                              
    2. 
                              
  2. 
                                 
    orapkiユーティリティを使用して、システムで使用するCRLを構成します。証明書検証用ハッシュ値によるCRLの名前変更を参照してください
    
                              
    3. 
                           

                           
CRLをOracle Internet Directoryに格納する場合:

                           
    
                              
  1. 
                                 
    Oracle Net Configuration Assistantを使用して、ディレクトリ接続情報を含むldap.oraファイルを作成し、構成します。
                                 
    
                              
    2. 
                              
  2. 
                                 
    orapkiユーティリティを使用して、CRLをディレクトリにアップロードします。Oracle Internet DirectoryへのCRLのアップロードを参照してください
    
                              
    3. 
                           

                        

                     

                  

                  

                     

                        

                           
親トピック: 証明書失効リストによる証明書の検証

                        

                     

                  

                  
               

            

            
21.14 以前のアルゴリズムからの証明書の許可
               

               

                  
ALLOWED_WEAK_CERT_ALGORITHMS sqlnet.oraパラメータを設定することで、以前の非推奨(および脆弱な)アルゴリズムに関連付けられた証明書を使用できます。 
                  

                  
ALLOWED_WEAK_CERT_ALGORITHMSを使用すると、以前のアルゴリズムを明示的に有効にできます。ただし、以前のアルゴリズムは新しいアルゴリズムより安全ではないことに注意してください。このパラメータは、Oracle Databaseリリース23c以降は非推奨であるALLOW_MD5_CERTSおよびALLOW_SHA1_CERTSパラメータに置き換ります。 
                  

                  
                  
    
                     
  1. データベース・サーバーまたはクライアント・サーバーにログインします。 
    2. 
                     
  2. sqlnet.oraパラメータ・ファイルを編集して、ALLOWED_WEAK_CERT_ALGORITHMSパラメータを含めます。
    
                           
    MD5またはSHA1を指定できます。両方を指定する場合は、カンマで区切ります。例:
                           
    ALLOWED_WEAK_CERT_ALGORITHMS = (MD5,SHA1)
    MD5は、デフォルトで無効になっています。SHA1は、デフォルトで有効になっています。sqlnet.oraファイルのデフォルトの場所は$ORACLE_HOME/network/adminディレクトリ内に存在します。
                           
    
                        
    
                     
    3. 
                  

               

               

                  

                     

                        
親トピック: Transport Layer Security暗号化の構成

                     

                  

               

               
            
21.15 Transport Layer Security構成のトラブルシューティング
               

               

                  
Oracle Database Transport Layer Securityアダプタの使用時に、一般的なエラーが発生する可能性があります。

                  

                     
Oracle Netトレースを有効にして、エラーの原因を特定することが必要になる場合があります。トレース・パラメータを設定してOracle Netトレースを有効にする方法の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。
                     

                     

                        

                              ORA-28759: ファイルのオープンに失敗しました
                        

                        

                           
原因: 指定されたファイルをオープンできませんでした。通常、このエラーはウォレットが見つからないために発生します。
                           

                        

                        

                           
処置: 次の点を確認します。
                           

                           
    
                              
  • 
                                 
    sqlnet.oraファイルに正しいウォレット・ロケーションが指定されていることを確認します。これは、ウォレットを保存したディレクトリと同じにする必要があります。
                                 
    
                              
    • 
                              
  • 
                                 
    Oracle Netトレースを有効にして、開くことができないファイルの名前とその原因を調べます。
    
                              
    • 
                              
  • 
                                 
    orapkiまたはmkstore (非推奨)を使用してウォレットを保存したときに、自動ログインが有効になっていたことを確認します。
                                 
    
                              
    • 
                           

                        

                        

                              ORA-28786: 暗号化された秘密キーの復号化に失敗しました
                        

                        

                           
原因: 暗号化された秘密キーの復号化に不正なパスワードが使用されました。このことは、多くの場合、自動ログイン・ウォレットが使用されていないために発生します。
                           

                        

                        

                           
処置: mkstoreを使用して、ウォレットの自動ログイン機能をオンにします。次に、ウォレットを再度保存します。例:
                           
mkstore -wrl wallet_location -create wallet_name
 自動ログイン機能が使用されていない場合は、正しいパスワードを入力します。

                        

                        

                              ORA-28858: SSLプロトコル・エラーが発生しました
                        

                        

                           
原因: これは、2つのプロセス間のTLSハンドシェイク・ネゴシエーション中に発生する可能性がある一般的なエラーです。
                           

                        

                        

                           
処置: Oracle Netトレースを使用可能にし、再接続してトレース出力を生成します。トレース出力をOracleカスタマ・サポートに連絡してください。
                           

                        

                        

                              ORA-28859 SSLでネゴシエーションに失敗しました
                        

                        

                           
原因: TLSプロトコルの一部である2つのプロセス間のネゴシエーション中にエラーが発生しました。このエラーは、両プロセスの接続で同じ暗号スイートがサポートされていない場合に発生する可能性があります。
                           

                        

                        

                           
処置: 次の点を確認します。
                           

                           
    
                              
  • 
                                 
    sqlnet.oraファイルをチェックして、クライアントとサーバーの両方のTLSバージョンが一致しているか、互換性があることを確認します。たとえば、サーバーでTLS 1.3のみを受け入れ、クライアントでTLS 1.2のみを受け入れる場合、TLS接続は失敗します。
                                 
    
                              
    • 
                              
  • 
                                 
    クライアントおよびサーバーで構成されている暗号スイートをチェックし、両方に互換性のある暗号スイートが設定されていることを確認します。
    
                                 
    それでもエラーが解決されない場合は、トレースを有効にして再度接続を試みてください。Oracleサポートに連絡して、トレース出力を提出してください。
    
                                 
    
                                    
    関連項目:
    
                                    
    クライアントとサーバーで互換性のある暗号スイートを設定する方法の詳細は、ステップ2E: クライアントのTransport Layer Security暗号スイートの設定(オプション)を参照してください
                                    
    
                                 
    
                                 
    
                                    
    ノート:
    
                                    
    暗号スイートを構成しない場合は、使用可能なすべての暗号スイートが有効になります。
    
                                 
    
                              
    • 
                           

                        

                        

                              ORA-28862: SSL接続に失敗しました。
                        

                        

                           
原因: このエラーは、ピアが接続をクローズしたために発生しました。
                           

                        

                        

                           
処置: 次の点を確認します。
                           

                           
    
                              
  • 
                                 
    ウォレットが検出されるように、sqlnet.oraファイルに正しいウォレット・ロケーションが指定されていることを確認します。
                                 
    
                              
    • 
                              
  • 
                                 
    sqlnet.oraファイルで暗号スイートが正しく設定されていることを確認します。このエラーは、sqlnet.oraが手動で編集され、暗号スイート名の綴りが誤っている場合に発生することがあります。暗号スイート名で大/小文字が区別される文字列照合が使用されていることを確認します。
                                 
    
                              
    • 
                              
  • 
                                 
    クライアントとサーバーの両方のTLSバージョンが一致しているか、互換性があることを確認します。このエラーは、サーバーとクライアントに指定されているTLSバージョンが一致しないために発生することがあります。たとえば、サーバーでTLS 1.3のみを受け入れ、クライアントでTLS 1.2のみを受け入れる場合、TLS接続は失敗します。
    
                              
    • 
                              
  • 
                                 
    診断情報の詳細を確認するために、ピアでOracle Netトレースを有効にします。
    
                              
    • 
                           

                        

                        

                              ORA-28865: SSL接続はクローズしました。
                        

                        

                           
原因: 基礎となるトランスポート層でエラーが発生したか、ピア・プロセスが突然停止したため、TLS接続がクローズしました。
                           

                        

                        

                           
処置: 次の点を確認します。
                           

                           
    
                              
  • 
                                 
    クライアントとサーバーの両方のTLSバージョンが一致しているか、互換性があることを確認します。このエラーは、サーバーとクライアントに指定されているTLSバージョンが一致しないために発生することがあります。たとえば、サーバーでTLS 1.3のみを受け入れ、クライアントでTLS 1.2のみを受け入れる場合、TLS接続は失敗します。
    
                              
    • 
                              
  • 
                                 
    Oracle Netトレースを有効にし、トレース出力にネットワーク・エラーがないか確認します。
    
                              
    • 
                           

                        

                        

                              ORA-28868: ピア証明連鎖のチェックに失敗しました。
                        

                        

                           
原因: ピアが証明連鎖を提示したときに、その証明連鎖のチェックに失敗しました。この失敗の原因として、いくつかの問題が考えられます。
                           

                           
    
                              
  • 
                                 
    連鎖内のいずれかの証明書が期限切れになっています。
    
                              
    • 
                              
  • 
                                 
    連鎖内のいずれかの証明書の認証局がトラスト・ポイントとして認識されていません。
                                 
    
                              
    • 
                              
  • 
                                 
    いずれかの証明書の署名を検証できません。
    
                              
    • 
                           

                        

                        

                           
処置: ウォレットを開き、次のことを確認します。
                           

                           
    
                              
  • 
                                 
    ウォレットにインストールされているすべての証明書が使用可能である(期限切れでない)こと。
    
                              
    • 
                              
  • 
                                 
    ピア証明連鎖からの認証局の証明書が、ウォレットに信頼できる証明書として追加されています。 
    
                              
    • 
                           

                        

                        

                              ORA-28885: 必須のキー使用方法のある証明書が見つかりません。
                        

                        

                           
原因: 証明書は、適切なX.509バージョン3のキー使用方法の拡張機能を使用して作成されていません。
                           

                        

                        

                           
処置: mkstoreを使用して、証明書のキー使用方法を確認します。例:
                           
mkstore -wrl wallet_location -listCredential

                        

                              ORA-29019: プロトコル・バージョンが無効です
                        

                        

                           
原因: 2つのピア間でプロトコルのバージョンが一致していません。
                           

                        

                        

                           
処置: 正しいプロトコル・バージョンを指定するか、製品の構成ファイルにSSL_VERSIONを設定解除してください。 
                           

                           
エラー・コードはトレース[DATE_AND_TIME] ntzdosecneg: SSL handshake failed with error 29019に表示されます。
                           

                        

                        

                              ORA-29024: 証明書の検証に失敗しました
                        

                        

                           
原因: 反対側から送信された証明書の妥当性チェックに失敗しました。このエラーは、証明書が期限切れか、失効済か、または他の理由で無効になっている場合に発生する可能性があります。
                           

                        

                        

                           
処置: 次の点を確認します。
                           

                           
    
                              
  • 
                                 
    証明書をチェックして、有効かどうかを確認します。必要に応じて、新しい証明書を取得するか、送信者に証明書にエラーがあることを警告するか、または再送します。
    
                              
    • 
                              
  • 
                                 
    サーバーのウォレットに、クライアントの証明書を検証するための適切なトラスト・ポイントがあることを確認します。トラスト・ポイントがない場合は、orapkiを使用して、適切なトラスト・ポイントをウォレットにインポートします。 
                                 
    
                              
    • 
                              
  • 
                                 
    証明書が失効していないこと、および証明書失効リスト(CRL)チェックがオンになっていることを確認します。詳細は、証明書失効リストによる証明書検証の構成を参照してください
    
                              
    • 
                           

                        

                        

                              ORA-29223: 証明連鎖を作成できませんでした
                        

                        

                           
原因: インストールする証明書の既存のトラスト・ポイントを使用して証明書チェーンを作成できません。通常、このエラーは、ピアによって完全な連鎖が提供されず、連鎖を完了するのに適切なトラスト・ポイントがない場合に戻されます。
                           

                        

                        

                           
処置: orapkiを使用して、連鎖の完了に必要なトラスト・ポイントをインストールします。 
                           

                        

                     

                  

                  
               

               

                  

                     

                        
親トピック: Transport Layer Security暗号化の構成