21 Transport Layer Security暗号化の構成

セキュアで標準のプロトコルであるTransport Layer Security (TLS)を使用して、データベース・クライアントおよびサーバー接続を暗号化します。

  • Transport Layer Security (TLS)およびOracle Database
    TLSは、Oracle Databaseクライアントとサーバー間の接続を保護します。データベース・サーバーは、TLSバージョン1.3 (デフォルト)または1.2を使用して、他のデータベースおよびその他のサービスに接続することもできます。この章では、主にOracle Databaseクライアントとサーバー間のTLSの構成に焦点を当てます。
  • Oracle DatabaseおよびクライアントのTLSの構成
    このトピックでは、最も一般的な3つのTLS構成について説明します。詳細な構成とオプションの構成については、この章の後半で説明します。
  • 拡張構成とオプション構成
    Oracle Database 23aiでは、デフォルトのTransport Layer Security構成がセキュアで汎用性があります。ただし、Oracleには、この構成をカスタマイズおよび制御するためのパラメータが用意されています。
  • TLSおよびその他のOracle製品
    Transport Layer Security (TLS)は、他のOracle Database製品を使用する場合に構成できます。
  • Transport Layer Security構成のトラブルシューティング
    Oracle Database Transport Layer Securityの使用時に、一般的なエラーが発生する可能性があります。
  • Transport Layer Securityバージョン1.3への移行および構成
    Transport Layer Security (TLS)のバージョン1.3は、以前のバージョンのTLSと比較すると、セキュリティが強化され、TLSハンドシェイクが高速になっています。

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

21.1 Transport Layer Security (TLS)とOracle Database

TLSは、Oracle Databaseクライアントとサーバー間の接続を保護します。データベース・サーバーは、TLSバージョン1.3 (デフォルト)または1.2を使用して、他のデータベースおよびその他のサービスに接続することもできます。この章では、主にOracle Databaseクライアントとサーバー間のTLSの構成に焦点を当てます。

データベース・クライアントおよびサーバーは、要件に応じてTLSを使用するように構成できます。次に説明するいくつかのオプションを検討します。主なユースケースについては、次のトピックで説明します。詳細な考慮事項については、「詳細構成とオプション構成」を参照してください。

クライアント・サーバーTLS接続を構成するには、データベース・サーバーにウォレットが必要です。サーバー・ウォレットには、秘密キー、署名付きユーザー証明書、信頼のルート証明書およびデータベース・サーバー・ユーザー証明書の中間証明書が含まれます。

データベース・サーバー上のTLSウォレットは、WALLET_ROOTの場所に格納する必要があります。(パラメータWALLET_LOCATIONは、Oracle DatabaseサーバーのOracle Database 23aiでの使用は非推奨です。Oracle Databaseクライアントまたはリスナーでの使用は非推奨ではありません。) WALLET_ROOTの下にTLS用のディレクトリを作成して、WALLET_ROOT/<PDB GUID>/tlsとします。各コンテナ(CDBルートを含む)には独自のTLSウォレットがあり、WALLET_ROOTの使用時に1つのウォレットが複数のコンテナまたはすべてのコンテナで動作するように構成することはできません。

データベース・クライアントとサーバー間にTLSを構成する場合は、いくつかのオプションを検討する必要があります:

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

21.1.1 自己署名証明書と公開認証局(CA)署名証明書

自己署名証明書または公開認証局署名証明書がデータベース構成に適しているかどうかを確認します。

自己署名証明書: 自己署名ルート証明書は自分で作成でき、無料であるため、内部向けのITリソースに対して一般的です。リソース(ここではデータベース・サーバー)は、自己署名ルート証明書を使用して独自のデータベース・サーバー証明書に署名します。サーバー証明書と自己署名ルート証明書は、データベース・サーバー・ウォレットに格納されます。データベース・クライアントがデータベース・サーバー証明書を信頼できるようにするには、自己署名ルート証明書のコピーもクライアントに必要になります。この自己署名ルート証明書は、クライアント側のウォレットに格納することも、クライアント・システムのデフォルト証明書ストアにインストールすることもできます。すべてのOSのシステム証明書ストアの場所は、「Oracleウォレットの検索順序」に記載されています。

セッションの確立前に、データベース・クライアントは、サーバー証明書がクライアントにインストールされているものと同じルート証明書によって署名されているかどうかを確認します。ルート信頼証明書は、クライアント・システムのデフォルトの証明書ストアに格納すると、クライアント・マシンの他のアプリケーションやブラウザでも使用できるため便利です。会社で自己署名証明書を使用している場合、ルート信頼証明書はすべてのクライアントのデフォルト信頼ストアにすでにインストールされている可能性があります。

公開認証局(CA): CA署名証明書は、サード・パーティのパブリックで信頼できる認証局(CA)によって署名されます。公開認証局の例には、Symantec、DigiCert、Thawte、GeoTrust、GlobalSign、GoDaddyおよびEntrustがあります。これらのエンティティは、各証明書を要求する個人または組織の検証を担当します。

信頼のルートの公開認証局を使用すると、場合によってはルート信頼証明書がクライアント・システムのデフォルト証明書ストアにすでに格納されているというメリットがあります。公開認証局からの場合、クライアントがルート信頼証明書を格納するための追加のステップはありません。デメリットとしては、通常はサード・パーティの認証局への支払があることです。

親トピック: Transport Layer Security (TLS)およびOracle Database

21.1.2 一方向TLSと相互TLS

一方向TLSまたは相互TLS (mTLS)がデータベース構成に適しているかどうかを確認します。

一方向TLS: 一方向TLSは、TLSプロトコルを使用するサーバー検証暗号化チャネルです。標準のTLSセッションでは、サーバーのみがクライアントに証明書を提供し、自身を認証します。クライアントは、サーバーに対して自身を認証するために個別のクライアント証明書を必要としません(HTTPSセッションの確立方法と同様)。データベース・サーバーにはサーバー・ユーザー証明書および秘密キーを格納するためのウォレットが必要ですが、データベース・クライアントは信頼できるCAルート証明書にアクセスするだけで、サーバー・ユーザー証明書が信頼できるCAルート証明書によって署名されていることを検証します。OSプラットフォームおよびデータベース・クライアントによっては、信頼できるCAルート証明書がローカルのデフォルトの証明書システム・ストアまたはクライアント・ウォレットに存在する場合があります。一方向TLSは最も一般的なTLS構成であり、詳細な構成ステップは、「データベース・サーバー証明書に公開認証局の信頼のルートを使用したTLSの構成」を参照してください。

双方向TLS(相互TLS、mTLSとも呼ばれる): mTLSでは、クライアントとサーバーの両方がユーザー証明書を相互に提示します。ほとんどの場合、同じCAルート証明書がこれらの証明書の両方に署名するため、データベース・サーバーとクライアントで同じルートCA証明書を他方の証明書の認証に使用できます。この方法で使用されるmTLSは、データベースとクライアント間のリンクの暗号化、およびデータベースとクライアントの証明書の両方の検証に使用されます。データベース・ユーザー認証は、たとえば、mTLS暗号化リンクの確立に加え、データベース・ユーザー名とパスワードを使用してユーザーを認証するなど、個別に実行されます。プリンシパル(人間またはアプリケーション)は、クライアント側ユーザー証明書を認証メカニズムとして使用することもできます。これはPKI証明書による認証と呼ばれ、「PKI証明書による認証の構成」で説明されています。この場合、ユーザー証明書は二重の義務を果たし、データベースへのmTLS接続およびPKI証明書による認証を確立します。mTLSの構成ステップの詳細は、「相互Transport Layer Security (mTLS)」を参照してください。

親トピック: Transport Layer Security (TLS)およびOracle Database

21.1.3 クライアント・ウォレットの使用の有無を問わないTLS

クライアント・ウォレットの使用がデータベース構成に適しているかどうかを確認します。

ウォレットを使用するクライアント: mTLSを使用する場合、クライアント証明書が必要です。クライアント証明書は、Windowsのクライアント・ウォレットまたはMicrosot証明書ストア(MCS)に格納する必要があります。ウォレットには、信頼できるCAルート証明書と必要な中間証明書も格納する必要があります。

ウォレットを使用しないクライアント: TLSを次の条件で使用する場合、クライアントはウォレットなしで構成できます:

  1. クライアントに独自の証明書がない一方向TLSが構成されています。
  2. データベース・サーバー証明書に署名したルート証明書は、システムのデフォルトの証明書ストアに格納されます。サーバー証明書が公開認証局によって署名されている場合、ルート証明書はすでに存在しています。自己署名証明書を使用してサーバー証明書に署名した場合は、クライアント・ウォレットを使用しないように、この自己署名証明書をシステムのデフォルトの証明書ストアにインストールする必要があります。
  3. これはLinuxおよびWindowsクライアントにのみ適用されます。これは、Windows MCSおよびネイティブLinuxキーストアでネイティブに機能します。Windows以外のクライアントおよびLinux OS以外のクライアントでは、OCI-Cクライアントは、「Oracleウォレットの検索順序」で説明されている複数の場所に格納されているPEMファイルを検索します。

親トピック: Transport Layer Security (TLS)およびOracle Database

21.1.4 証明書DN一致

証明書DN一致がデータベース構成に適しているかどうかを確認します。

ヒント:

Oracleでは、TLSセッションを構成するときにこのオプションを使用することをお薦めします。
DN証明書一致パラメータは、データベース・クライアントでのみ使用されます。DN証明書一致が有効な場合、クライアントはサーバー証明書(共通名(CN)、識別名(DN)、サブジェクト代替名(SAN))の情報をチェックし、接続文字列またはsqlnet.oraの情報と比較します。一致する場合、データベース・サーバーはクライアントが接続しようとしているサーバーであることを意味します。一致しない場合、サーバーは目的のサーバーではないため、クライアントは接続試行を拒否します。部分または完全DN一致をチェックせずにTLSを構成すると、サーバー証明書が期限切れではなく、既知の認証局によって署名されていることがチェックされます。DN証明書の一致はさらに一歩進み、クライアントが目的のサーバーと通信していることを確認します。DN証明書一致には、部分DN一致と完全DN一致の2つのサブオプションがあります。
  • 部分DN一致: SQLNET.oraまたは接続文字列で、SSL_SERVER_DN_MATCH=YESを指定します。部分DN一致では、接続文字列のHOSTパラメータをチェックして、CN、DNまたはSAN名と一致するかどうかを確認します。接続を確立させるには一致する必要があります。
  • 完全DN一致: SSL_SERVER_DN_MATCH=YESの設定に加えて、完全なDN一致を強制するようにSSL_SERVER_CERT_DN=<certificate DN>も設定する必要があります。これにより、HOST値がIPアドレスまたは証明書で使用可能な名前以外にする必要がある場合に、DN証明書の一致を引き続き使用できます。

親トピック: Transport Layer Security (TLS)およびOracle Database

21.2 Oracle DatabaseおよびクライアントのTLSの構成

このトピックでは、最も一般的な3つのTLS構成について説明します。詳細な構成とオプションの構成については、この章の後半で説明します。

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

21.2.1 Oracle DatabaseのTLSの構成について

このトピックでは、最も一般的な3つのTLS構成について詳しく説明します。

最初に決定するのは、自己署名証明書の信頼ルートまたは信頼のパブリックCAルートを使用することです。Oracleでは、使用している環境でサポートされ、セキュリティ・ポリシーで許可されていて、これを決定した場合にウォレットなしでTLSを使用することをお薦めします。これにより、データベース・クライアントの管理が大幅に簡素化されます。最小限の必須パラメータ・セットで構成を開始します。次に完了したら、推奨パラメータとオプション・パラメータを1つずつ追加します。

このトピックの次の構成では、次のパラメータが使用されます。

表21-1 一方向TLSを構成するための必須パラメータと推奨パラメータ

パラメータ 説明 サーバー(sqlnet.oraで定義) リスナー(listener.oraで定義) 静的クライアント(sqlnet.oraで定義) 動的クライアント(接続文字列で定義)
WALLET_ROOT データベース・サーバーのシステム・パラメータ(WALLET_LOCATIONと置換) 必須 いいえ いいえ いいえ
WALLET_LOCATION 必要に応じて、ウォレットの場所を指定します いいえ 必須 オプション オプション
Protocol=tcps TLS接続を有効化します いいえ 必須 いいえ 必須
SSL_CLIENT_AUTHENTICATION 1方向TLSの許可を無効化します 必須 必須 オプション オプション
SSL_SERVER_DN_MATCH 部分DN一致または完全DN一致を有効化します いいえ いいえ 推奨 推奨
SSL_SERVER_CERT_DN 完全DN一致が必要な場合に使用します いいえ いいえ いいえ オプション

WALLET_ROOTおよびWALLET_LOCATIONパラメータ

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

パラメータWALLET_LOCATIONは、Oracle DatabaseサーバーのOracle Database 23aiでの使用は非推奨です。Oracle Databaseクライアントまたはリスナーでの使用は非推奨ではありません。PDBのTLSウォレットの場所はWALLET_ROOT/<PDB GUID>/tlsです。

WALLET_LOCATIONは、リスナーがウォレットを検索するために使用する必要があります。Oracleでは、リスナーとサーバーのDN一致に同じウォレットを使用することをお薦めします。DN一致は、クライアントが想定しているサーバーに接続していることを確認するために使用され、クライアントはリスナー証明書とサーバー証明書の両方をチェックします。

Protocolパラメータ

クライアントおよびリスナーでは、Protocolをtcpsに設定する必要があります。リスナーは、これをサービス接続文字列の一部として設定します。クライアントはこれを接続文字列に設定します。

SSL_CLIENT_AUTHENTICATONパラメータ

TLSトラフィック(およびmTLS)がリスナーおよびサーバーに接続できるようにするには、データベース・サーバーおよびリスナーのSSL_CLIENT_AUTHENTICATONをFALSEに設定する必要があります。これはクライアントではオプションであり、そのクライアントで、他の接続に使用されるクライアント側ユーザー証明書を含むウォレットがすでにあるかによって異なります。

DN一致

DN一致を使用することをお薦めします。ただし、TLS接続の確認が完了してから、これらの設定を追加します。

Oracle Databaseの最も一般的なTLS構成は次のとおりです:

親トピック: Oracle DatabaseおよびクライアントのTLSの構成

21.2.2 データベース・サーバー証明書に公開認証局の信頼のルートを使用したTLSの構成

クライアント・ウォレットを使用せずにTLSを構成する前に、サーバー・ウォレットを最初に作成し、データベースとリスナーが正しく構成されていることを確認する必要があります。

親トピック: Oracle DatabaseおよびクライアントのTLSの構成

21.2.2.1 サーバーおよびリスナー・ウォレットの作成
公開署名認証局によって署名された証明書を取得するには、データベース・サーバーおよびリスナー・ウォレットを作成し、証明書署名リクエスト(CSR)をエクスポートする必要があります。
  1. データベースがインストールされているホストにログインします。
  2. ウォレットを作成します。
    orapki wallet create -wallet <wallet location> -pwd <wallet password> -auto_login
  3. 信頼できるルート証明書をウォレットに追加します(これは証明書管理者から取得します)。
    orapki wallet add -wallet <wallet location> -trusted_cert -cert <trusted root certificate location>/rootCA.crt -pwd <wallet password>
  4. ウォレットに秘密キーおよび証明書リクエストを作成します。
    orapki wallet add -wallet <wallet location> -keysize 2048 -dn <certificate_dn> -pwd <wallet password>
  5. 証明書リクエストをエクスポートして、署名を受けます。
    orapki wallet export -wallet <wallet location> -dn <certificate_dn> -request <certificate signing request location>/<file_name>.csr -pwd <wallet password>
  6. ウォレットの内容を表示します。
    orapki wallet display -wallet <wallet_location>

    「Requested Certificates」の下にエントリがあります。

  7. CSR (証明書署名リクエスト)ファイルの内容を表示します。
    cat <certificate_signing_request_location>/<file_name>.csr
  8. CSRファイルを証明書管理者に送信して、ルート認証局(CA)または中間CAによる署名を受けます。
  9. 署名されたデータベース・サーバー・ユーザー証明書をデータベース・ウォレットにインポートします。
    orapki wallet add -wallet <wallet location> -user_cert -cert <signed certificate location>/<file_name_signed>.crt -pwd <wallet password>
  10. ウォレットの内容を表示します:
    orapki wallet display -wallet <wallet location>
  11. データベース・サーバー・ユーザー証明書がUser Certificatesの下に表示されていることを確認します。
    データベース・サーバーおよびリスナーに使用するウォレットは、使用のためにデプロイする準備ができました。
21.2.2.2 WALLET_ROOTの設定とデータベース・サーバー・ウォレットのデプロイ
  1. WALLET_ROOTがすでに存在するかどうかを確認します。システム・パラメータを確認する権限を持つユーザーとしてログインし、次を実行します:
    SHOW PARAMETER WALLET_ROOT
    WALLET_ROOTがまだ設定されていない場合は、次のコマンドを実行してWALLET_ROOTを作成します。
  2. システム・パラメータであるWALLET_ROOTを作成します。次のSQLコマンドを実行します。
    alter system set wallet_root = '<wallet_root_directory>' scope=spfile;
  3. データベースを再起動します。
  4. 変更されたwallet_rootパラメータを表示します。次のSQLコマンドを実行します。
    show parameter wallet_root;
  5. TLSディレクトリがWALLET_ROOTの下にまだ存在しない場合は、オペレーティング・システムのWALLET_ROOT PDBディレクトリの下に、TLS用のディレクトリを作成します。
    mkdir -p -v <wallet_root_directory>/<PDB GUID>/tls
    PDBのPDB GUIDを確認するには、次のSQLコマンドを実行します:
    select guid from v\$containers;
  6. ディレクトリの所有者を変更します。
    sudo chown oracle:oinstall -R -v <wallet_root_directory>/<PDB GUID>/tls
  7. データベース・サーバーewallet.p12およびcwallet.ssoファイルをこの新しいtlsディレクトリにコピーします。

    ウォレットが作成されたのと同じディレクトリから次のコマンドを実行します:

    cp ./ewallet.p12 ./cwallet.sso <wallet_root_directory>/<PDB GUID>/tls
21.2.2.3 TLSのデータベース・サーバー構成
  1. Oracleデータベースが存在するサーバーにログインします。
  2. sqlnet.oraファイルのSSL_CLIENT_AUTHENTICATIONがFALSEに設定されていることを確認します。これにより、一方向TLSが有効になります:
    デフォルトでは、sqlnet.oraファイルは、$ORACLE_HOME/network/adminディレクトリ、またはTNS_ADMIN環境変数によって設定されている場所にあります。

    読取り専用Oracleホームを使用する場合、sqlnet.oraのデフォルトの場所は$ORACLE_HOME/network/adminです。 

    SSL_CLIENT_AUTHENTICATION=FALSE
    かわりに、TLSとmTLSの両方を有効にし、クライアントがクライアント・ユーザー証明書を送信するかどうかに依存するOPTIONALに設定できます。
21.2.2.4 TLSのリスナー構成
  1. listener.oraファイルのPROTOCOLパラメータをチェックして、TLSが指定されていることを確認します。
    デフォルトでは、listener.oraは$ORACLE_HOME/network/adminディレクトリに配置されます。

    パラメータPROTOCOL=tcpsは、データベース接続にTLS (またはmTLS)のみを使用するようにリスナーに指示します。

    次に例を示します:
    LISTENER = (ADDRESS=(PROTOCOL=tcps)(HOST=<host_name>)(PORT=1522))
  2. listener.oraファイルのWALLET_LOCATIONパラメータの場所にリスナー・ウォレットが存在することを確認します。データベース・サーバーの場合と同じウォレットを使用します。
    WALLET_LOCATION=  
    (SOURCE=    
        (METHOD=file)    
        (METHOD_DATA=       
            (DIRECTORY=$WALLET_DIR/<pdb guid>/tls)))

    リスナーがデータベース・サーバーと同じサーバー上にあり、サーバーのTLSウォレットがデフォルトの場所にある場合は、リスナーWALLET_LOCATIONを同じ場所に設定します。または、サーバー・ウォレットをリスナーの別の場所にコピーできます。

    DN一致(部分または完全DN一致)に対してSSL_SERVER_DN_MATCHパラメータをTRUEに設定すると、リスナー証明書とサーバー証明書の両方に対してホスト名またはDNチェックが実行されます。同じ証明書である必要はありませんが、両方の証明書で一致が行われます。

  3. 相互TLSを無効にするには、listener.oraファイルでSSL_CLIENT_AUTHENTICATIONパラメータがFALSEに設定されていることを確認します。
    SSL_CLIENT_AUTHENTICATION=FALSE

    ノート:

    リスナーが複数のデータベース(一方向TLSを持つデータベースとmTLSを持つデータベース)をサポートしている場合は、SSL_CLIENT_AUTHENTICATION=OPTIONALを設定します。
21.2.2.5 TLSのクライアント構成
21.2.2.5.1 TLSのためのクライアント接続文字列の構成

接続文字列にパラメータprotocol=tcpsを追加して、クライアントからTLSを強制します。接続では、クライアントからリスナーへのTLSが使用されます。

ノート:

このパラメータは、sqlnet.oraでは使用できません。
(description=
    (address=
        (protocol=tcps)
        (port=1522)
        (host=example.com))
    (connect_data=
        (service_name=dbservicename.example.com)))
21.2.2.5.2 (オプション)クライアントのSSL_CLIENT_AUTHENTICATONの設定
  • クライアント側ユーザー証明書があってもmTLSに使用しない場合は、このステップを完了する必要があります。
  • クライアント側ユーザー証明書がない場合は、このパラメータ設定に関係なく、クライアントが先に進んで一方向TLS接続を行うため、このステップをスキップできます。
  1. Oracleデータベースのクライアントにログインします。
  2. sqlnet.oraファイルのSSL_CLIENT_AUTHENTICATIONをFALSEに設定します。
    SSL_CLIENT_AUTHENTICATION=FALSE

    sqlnet.oraでこのパラメータをFALSEに設定すると、すべての接続のクライアント側ユーザー証明書の送信がブロックされます。tnsnames.oraの接続文字列でSSL_CLIENT_AUTHENTICATION=TRUEを設定し、これを特定の接続に対してオーバーライドすると、クライアント側ユーザー証明書が接続に使用されます。

    接続文字列のパラメータは、sqlnet.oraパラメータ設定より優先されます。この設定はオプションであり、クライアント側ユーザー証明書があり、それをmTLS接続に使用しない場合のみ必要です。

  3. クライアント側ウォレットとユーザー証明書を使用する既存のmTLS接続を保持し、ユーザー証明書を使用せずに一方向TLS接続を確立するには、sqlnet.oraにデフォルト設定であるSSL_CLIENT_AUTHENTICATION=TRUEを設定します。次に、クライアント側ユーザー・ウォレットなしで使用するすべての接続について、接続文字列にSSL_CLIENT_AUTHENTICATION=FALSEを追加します。
21.2.2.6 データベースに接続します

tcpsプロトコルで接続名を使用してデータベースに接続します。

sqlplus <user_name>@<PDB_name>
21.2.2.7 接続の検証
  1. 次のコマンドを実行します。
    select sys_context ('userenv','NETWORK_PROTOCOL') from dual;

    TLSが有効になっている場合は「tcps」、TLSが有効になっていない場合は「tcp」が表示されます。

  2. 次のコマンドを実行します。
    select sys_context ('userenv','TLS_VERSION') from dual;

    データベース・サーバーでの接続終了のTLSプロトコルが表示されます。

  3. 次のコマンドを実行します。
    select sys_context ('userenv','TLS_CIPHERSUITE') from dual;

    データベース・サーバーでの接続終了のTLS暗号スイートが表示されます。

21.2.3 自己署名ルート証明書を使用したTLSの構成

自己署名ルート証明書の使用は、前述のユースケースと非常によく似ていますが、ルート・ウォレットを作成し、自己署名ルート証明書でデータベース証明書に署名する必要があります。

親トピック: Oracle DatabaseおよびクライアントのTLSの構成

21.2.3.1 ルート・ウォレットの作成
  1. ルート・ウォレットを作成します:
    orapki wallet create -wallet <root wallet directory> -pwd <root wallet password> -auto_login
  2. ウォレットの内容を空白で表示します:
    orapki wallet display -wallet <root wallet directory>
  3. ルートCAウォレット用の自己署名ルート証明書を作成します:
    orapki wallet add -wallet <root wallet directory> -dn <certificate_DN> -keysize 2048 -sign_alg sha256 -self_signed -validity 365 -pwd <root wallet password>
  4. ディレクトリには、cwallet.ssoおよびewallet.p12ファイルが必要です:
    ls -l <root wallet directory>
  5. ウォレットの内容(ユーザーと信頼できる証明書)を表示します:
    orapki wallet display -wallet <root wallet directory>
  6. DBウォレットの作成に使用するルートCAの信頼できる証明書をエクスポートします:
    orapki wallet export -wallet <root wallet directory> -dn <certificate_DN> -cert <root wallet directory>/rootCA.crt -pwd <root wallet password>
  7. rootCA.crtファイルの内容を表示します:
    cat <root wallet directory>/rootCA.crt
21.2.3.2 サーバーおよびリスナー・ウォレットの作成
自己署名ルート証明書によって署名された証明書を取得するには、前のユース・ケースと同じステップに従ってウォレットを作成し、証明書署名リクエスト(CSR)をエクスポートします。
  1. データベースがインストールされているホストにログインします。
  2. ウォレットを作成します。
    orapki wallet create -wallet <wallet location> -pwd <wallet password> -auto_login
  3. 信頼できるルート証明書をウォレットに追加します(これは証明書管理者から取得します)。
    orapki wallet add -wallet <wallet location> -trusted_cert -cert <trusted root certificate location>/rootCA.crt -pwd <wallet password>
  4. ウォレットに秘密キーおよび証明書リクエストを作成します。
    orapki wallet add -wallet <wallet location> -keysize 2048 -dn <certificate_dn> -pwd <wallet password>
  5. 証明書リクエストをエクスポートして、署名を受けます。
    orapki wallet export -wallet <wallet location> -dn <certificate_dn> -request <certificate signing request location>/<file_name>.csr -pwd <wallet password>
  6. ウォレットの内容を表示します。
    orapki wallet display -wallet <wallet_location>

    「Requested Certificates」の下にエントリがあります。

  7. CSR (証明書署名リクエスト)ファイルの内容を表示します。
    cat <certificate_signing_request_location>/<file_name>.csr
21.2.3.3 データベース・サーバー証明書署名リクエスト(CSR)ファイルの署名
  1. 自己署名ルート・ウォレットを使用してCSRに署名します:
    orapki cert create -wallet <root wallet directory> -request <CSR directory>/example.csr -cert <wallet location>/example-signed.crt -validity 365 -sign_alg sha256 -pwd <root wallet password>
  2. 署名付きサーバー・ユーザー証明書を表示します:
    cat <wallet location>/example-signed.crt
  3. 署名されたデータベース・サーバー・ユーザー証明書をデータベース・ウォレットにインポートします。
    orapki wallet add -wallet <wallet location> -user_cert -cert <signed certificate location>/<file_name_signed>.crt -pwd <wallet password>
  4. ウォレットの内容を表示します:
    orapki wallet display -wallet <wallet location>
  5. データベース・サーバー・ユーザー証明書がUser Certificatesの下に表示されていることを確認します。
    データベース・サーバーおよびリスナーに使用するウォレットは、使用のためにデプロイする準備ができました。
21.2.3.4 WALLET_ROOTの設定とデータベース・サーバー・ウォレットのデプロイ
  1. WALLET_ROOTがすでに存在するかどうかを確認します。システム・パラメータを確認する権限を持つユーザーとしてログインし、次を実行します:
    SHOW PARAMETER WALLET_ROOT
    WALLET_ROOTがまだ設定されていない場合は、次のコマンドを実行してWALLET_ROOTを作成します。
  2. システム・パラメータであるWALLET_ROOTを作成します。次のSQLコマンドを実行します。
    alter system set wallet_root = '<wallet_root_directory>' scope=spfile;
  3. データベースを再起動します。
  4. 変更されたwallet_rootパラメータを表示します。次のSQLコマンドを実行します。
    show parameter wallet_root;
  5. TLSディレクトリがWALLET_ROOTの下にまだ存在しない場合は、オペレーティング・システムのWALLET_ROOT PDBディレクトリの下に、TLS用のディレクトリを作成します。
    mkdir -p -v <wallet_root_directory>/<PDB GUID>/tls
    PDBのPDB GUIDを確認するには、次のSQLコマンドを実行します:
    select guid from v\$containers;
  6. ディレクトリの所有者を変更します。
    sudo chown oracle:oinstall -R -v <wallet_root_directory>/<PDB GUID>/tls
  7. データベース・サーバーewallet.p12およびcwallet.ssoファイルをこの新しいtlsディレクトリにコピーします。

    ウォレットが作成されたのと同じディレクトリから次のコマンドを実行します:

    cp ./ewallet.p12 ./cwallet.sso <wallet_root_directory>/<PDB GUID>/tls
21.2.3.5 TLSのデータベース・サーバー構成
  1. Oracleデータベースが存在するサーバーにログインします。
  2. sqlnet.oraファイルのSSL_CLIENT_AUTHENTICATIONがFALSEに設定されていることを確認します。これにより、一方向TLSが有効になります:
    デフォルトでは、sqlnet.oraファイルは、$ORACLE_HOME/network/adminディレクトリ、またはTNS_ADMIN環境変数によって設定されている場所にあります。

    読取り専用Oracleホームを使用する場合、sqlnet.oraのデフォルトの場所は$ORACLE_HOME/network/adminです。 

    SSL_CLIENT_AUTHENTICATION=FALSE
    かわりに、TLSとmTLSの両方を有効にし、クライアントがクライアント・ユーザー証明書を送信するかどうかに依存するOPTIONALに設定できます。
21.2.3.6 TLSのリスナー構成
  1. listener.oraファイルのPROTOCOLパラメータをチェックして、TLSが指定されていることを確認します。
    デフォルトでは、listener.oraは$ORACLE_HOME/network/adminディレクトリに配置されます。

    パラメータPROTOCOL=tcpsは、データベース接続にTLS (またはmTLS)のみを使用するようにリスナーに指示します。

    次に例を示します:
    LISTENER = (ADDRESS=(PROTOCOL=tcps)(HOST=<host_name>)(PORT=1522))
  2. listener.oraファイルのWALLET_LOCATIONパラメータの場所にリスナー・ウォレットが存在することを確認します。データベース・サーバーの場合と同じウォレットを使用します。
    WALLET_LOCATION=  
    (SOURCE=    
        (METHOD=file)    
        (METHOD_DATA=       
            (DIRECTORY=$WALLET_DIR/<pdb guid>/tls)))

    リスナーがデータベース・サーバーと同じサーバー上にあり、サーバーのTLSウォレットがデフォルトの場所にある場合は、リスナーWALLET_LOCATIONを同じ場所に設定します。または、サーバー・ウォレットをリスナーの別の場所にコピーできます。

    DN一致(部分または完全DN一致)に対してSSL_SERVER_DN_MATCHパラメータをTRUEに設定すると、リスナー証明書とサーバー証明書の両方に対してホスト名またはDNチェックが実行されます。同じ証明書である必要はありませんが、両方の証明書で一致が行われます。

  3. 相互TLSを無効にするには、listener.oraファイルでSSL_CLIENT_AUTHENTICATIONパラメータがFALSEに設定されていることを確認します。
    SSL_CLIENT_AUTHENTICATION=FALSE

    ノート:

    リスナーが複数のデータベース(一方向TLSを持つデータベースとmTLSを持つデータベース)をサポートしている場合は、SSL_CLIENT_AUTHENTICATION=OPTIONALを設定します。
21.2.3.7 TLSのクライアント構成
21.2.3.7.1 自己署名の信頼できるルート証明書の、クライアント・システムのデフォルト・キーストアへの追加
データベース・クライアントのオペレーティング・システムでは、自己署名の信頼できるルート証明書をクライアント・システムのデフォルト・キーストアに追加する必要があります。これは会社が企業の自己署名付きの信頼できるルート証明書を使用している場合、すでに完了している可能性があります。

Oracle Databaseシック・クライアント(OCI-C)は、WindowsおよびLinuxシステムのデフォルト・ストアとネイティブに連携します。他のオペレーティング・システムでは、Oracle Databaseクライアントは、次にリストされているディレクトリの場所でPEMファイルを検索します。OS用のPEMファイルが別の場所にある場合は、PEMファイルを検索した場所の1つにコピーするか、検索した場所へのシンボリックリンクを作成できます。OSごとの指示に従って、新しい信頼証明書をシステムの証明書ストア(PEMファイル)に追加します。Microsoft WindowsおよびRHEL/Oracle Linuxについては、このための指示が含まれています。

  1. ルート・ウォレットからルートCAの信頼できる証明書をエクスポートします。
    orapki wallet export -wallet <root wallet location> -dn <certificate_DN> -cert <root wallet location>/rootCA.crt -pwd <root wallet password>
  2. エクスポートされたデータベース信頼証明書をシステムのデフォルトの証明書ストアに追加します。
    • Windowsの場合、Microsoft管理コンソール(mmc)を使用して、信頼できるルート証明書をMicrosoft証明書ストア(MCS)にインポートします
    • RHEL/Oracle Linuxの場合、デフォルトのシステム・ストアは/etc/pki/tls/cert.pemにあります。新しいルート証明書をこのPEMファイルにインポートするには、次の手順を実行します:
      1. 新しい証明書を/etc/pki/ca-trust/source/anchors/に追加します
      2. 次のコマンドを実行します; 
        sudo update-ca-trust extract
      3. スタンドアロン・ルート証明書を削除します: 
        rm -v <root wallet location>/rootCA.crt
    • 残りのLinuxオペレーティング・システムについては、PEMファイルは次の場所にあります:
      • 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

      OSの指示に従って、既存のPEMファイルに新しい証明書を追加します。

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

      ノート:

      証明書ストアのデフォルトの場所は変更できません。
21.2.3.7.2 TLSのためのクライアント接続文字列の構成

接続文字列にパラメータprotocol=tcpsを追加して、クライアントからTLSを強制します。接続では、クライアントからリスナーへのTLSが使用されます。

ノート:

このパラメータは、sqlnet.oraでは使用できません。
(description=
    (address=
        (protocol=tcps)
        (port=1522)
        (host=example.com))
    (connect_data=
        (service_name=dbservicename.example.com)))
21.2.3.7.3 (オプション)クライアントのSSL_CLIENT_AUTHENTICATONの設定
  • クライアント側ユーザー証明書があってもmTLSに使用しない場合は、このステップを完了する必要があります。
  • クライアント側ユーザー証明書がない場合は、このパラメータ設定に関係なく、クライアントが先に進んで一方向TLS接続を行うため、このステップをスキップできます。
  1. Oracleデータベースのクライアントにログインします。
  2. sqlnet.oraファイルのSSL_CLIENT_AUTHENTICATIONをFALSEに設定します。
    SSL_CLIENT_AUTHENTICATION=FALSE

    sqlnet.oraでこのパラメータをFALSEに設定すると、すべての接続のクライアント側ユーザー証明書の送信がブロックされます。tnsnames.oraの接続文字列でSSL_CLIENT_AUTHENTICATION=TRUEを設定し、これを特定の接続に対してオーバーライドすると、クライアント側ユーザー証明書が接続に使用されます。

    接続文字列のパラメータは、sqlnet.oraパラメータ設定より優先されます。この設定はオプションであり、クライアント側ユーザー証明書があり、それをmTLS接続に使用しない場合のみ必要です。

  3. クライアント側ウォレットとユーザー証明書を使用する既存のmTLS接続を保持し、ユーザー証明書を使用せずに一方向TLS接続を確立するには、sqlnet.oraにデフォルト設定であるSSL_CLIENT_AUTHENTICATION=TRUEを設定します。次に、クライアント側ユーザー・ウォレットなしで使用するすべての接続について、接続文字列にSSL_CLIENT_AUTHENTICATION=FALSEを追加します。
21.2.3.8 データベースに接続します

tcpsプロトコルで接続名を使用してデータベースに接続します。

sqlplus <user_name>@<PDB_name>
21.2.3.9 接続の検証
  1. 次のコマンドを実行します。
    select sys_context ('userenv','NETWORK_PROTOCOL') from dual;

    TLSが有効になっている場合は「tcps」、TLSが有効になっていない場合は「tcp」が表示されます。

  2. 次のコマンドを実行します。
    select sys_context ('userenv','TLS_VERSION') from dual;

    データベース・サーバーでの接続終了のTLSプロトコルが表示されます。

  3. 次のコマンドを実行します。
    select sys_context ('userenv','TLS_CIPHERSUITE') from dual;

    データベース・サーバーでの接続終了のTLS暗号スイートが表示されます。

21.2.4 クライアント・ウォレットを使用したTLS接続の構成

公開認証局または自己署名CA信頼証明書を使用してTLSを構成する場合、クライアント・ウォレットが必要になることがあります。

TLS接続のクライアント・ウォレットには、データベース・サーバー証明書に署名した認証局の信頼証明書が含まれます。信頼証明書のルートのみが必要です。中間証明書は必要ありません。

システムのデフォルトの証明書ストアを使用できない場合は、クライアント・ウォレットを使用する必要があります。

  1. クライアント・ウォレットを作成します。
    orapki wallet create -wallet <wallet_location> -pwd <wallet_password> -auto_login
  2. CAの信頼できる証明書を取得します。これは、ファイル内ですでに使用可能であるか、ルート証明書ウォレットまたはデータベース・サーバー・ウォレットからエクスポートする必要がある場合があります。
    orapki wallet export -wallet <wallet_location> -dn <certificate_dn> -cert <certificate_filename>

    詳細は、「orapkiユーティリティ・コマンドのサマリー」を参照してください。

  3. CAの信頼できる証明書をクライアント・ウォレットに追加します。
    orapki wallet add -wallet <wallet_location> -trusted_cert -cert <certificate_filename>
  4. クライアント・ウォレットを目的の場所に移動またはコピーします。
  5. sqlnet.oraを更新して、クライアント・ウォレットのWALLET_LOCATIONを追加します。
    これは、接続文字列パラメータWALLET_LOCATIONによってオーバーライドされないかぎり、すべてのクライアント接続で使用されます。WALLET_LOCATIONがsqlnet.oraまたは接続文字列に設定されていない場合、クライアントはシステムのデフォルトの証明書ストアをチェックします。 
    WALLET_LOCATION=    
    (SOURCE=      
        (METHOD=file)      
        (METHOD_DATA=           
            (DIRECTORY=/etc/oracle/wallets/databases)))

    詳細は、『Oracle Database Net Servicesリファレンス・ガイド』のWALLET_LOCATIONを参照してください。

親トピック: Oracle DatabaseおよびクライアントのTLSの構成

21.2.4.1 (オプション)クライアントのSSL_CLIENT_AUTHENTICATONの設定
  • クライアント側ユーザー証明書があってもmTLSに使用しない場合は、このステップを完了する必要があります。
  • クライアント側ユーザー証明書がない場合は、このパラメータ設定に関係なく、クライアントが先に進んで一方向TLS接続を行うため、このステップをスキップできます。
  1. Oracleデータベースのクライアントにログインします。
  2. sqlnet.oraファイルのSSL_CLIENT_AUTHENTICATIONをFALSEに設定します。
    SSL_CLIENT_AUTHENTICATION=FALSE

    sqlnet.oraでこのパラメータをFALSEに設定すると、すべての接続のクライアント側ユーザー証明書の送信がブロックされます。tnsnames.oraの接続文字列でSSL_CLIENT_AUTHENTICATION=TRUEを設定し、これを特定の接続に対してオーバーライドすると、クライアント側ユーザー証明書が接続に使用されます。

    接続文字列のパラメータは、sqlnet.oraパラメータ設定より優先されます。この設定はオプションであり、クライアント側ユーザー証明書があり、それをmTLS接続に使用しない場合のみ必要です。

  3. クライアント側ウォレットとユーザー証明書を使用する既存のmTLS接続を保持し、ユーザー証明書を使用せずに一方向TLS接続を確立するには、sqlnet.oraにデフォルト設定であるSSL_CLIENT_AUTHENTICATION=TRUEを設定します。次に、クライアント側ユーザー・ウォレットなしで使用するすべての接続について、接続文字列にSSL_CLIENT_AUTHENTICATION=FALSEを追加します。
21.2.4.2 データベースに接続します

tcpsプロトコルで接続名を使用してデータベースに接続します。

sqlplus <user_name>@<PDB_name>
21.2.4.3 接続の検証
  1. 次のコマンドを実行します。
    select sys_context ('userenv','NETWORK_PROTOCOL') from dual;

    TLSが有効になっている場合は「tcps」、TLSが有効になっていない場合は「tcp」が表示されます。

  2. 次のコマンドを実行します。
    select sys_context ('userenv','TLS_VERSION') from dual;

    データベース・サーバーでの接続終了のTLSプロトコルが表示されます。

  3. 次のコマンドを実行します。
    select sys_context ('userenv','TLS_CIPHERSUITE') from dual;

    データベース・サーバーでの接続終了のTLS暗号スイートが表示されます。

21.2.5 識別名(DN)一致の有効化

DN一致では、サーバー証明書名またはDNがクライアントで想定されるものと一致する場合に、Oracle Databaseサーバーに接続できます。

ヒント:

Oracleでは、クライアントが正しいホストに接続するように、部分DN一致または完全DN一致を使用することをお薦めします。

DN一致が有効な場合、リスナー証明書とデータベース・サーバー証明書の両方が、クライアントで想定される証明書と照合されます。DN一致を使用しない場合、同じまたは有効な公開CAによって署名されたサーバー証明書がクライアントに受け入れられ、TLSセッションが確立されます。

DN一致を設定する前に、まずテスト環境でTLSを正常に構成することをお薦めします。「データベース・サーバー証明書に公開認証局の信頼のルートを使用したTLSの構成」を参照してください。

DN一致を有効にするには:

  1. sqlnet.oraファイルでSSL_SERVER_DN_MATCHパラメータをTRUEに設定します: 
    SSL_SERVER_DN_MATCH = TRUE
    sqlnet.oraファイルは次のようになります:
    SSL_CLIENT_AUTHENTICATION = FALSE
WALLET_LOCATION =  
    (SOURCE= 
    (METHOD=File)  
    (METHOD_DATA=
        (DIRECTORY=wallet_location)))
SSL_SERVER_DN_MATCH = TRUE

    ノート:

    このステップのみを完了すると、部分DN一致になります。ステップ3を実行して、完全DN一致を確立します。

    部分DN一致では、接続文字列のホスト・パラメータ値が証明書の共通名(CN)と照合されます。一致が見つからない場合、クライアントはホスト・パラメータ値を証明書のサブジェクト代替名(SAN)フィールドのエントリと比較します。一致しない場合、接続は拒否されます。

  2. tnsnames.oraの接続文字列で、ホスト名パラメータを証明書DN文字列の共通名(CN)およびサブジェクト代替名(SAN)フィールドにリストされているホスト名と照合して確認します。部分DNが一致するには、接続文字列ホスト名が一致している必要があります。

    tnsnames.oraファイルは、クライアントまたはLDAPディレクトリに配置できます。tnsnames.oraファイルは、通常、TNS_ADMIN環境変数で指定された設定にあります。TNS_ADMINが設定されていない場合、tnsnames.oraは次のディレクトリの場所に存在します:

    • Linuxの場合: 
      $ORACLE_HOME/network/admin/
    • Windowsの場合: 
      ORACLE_BASE\ORACLE_HOME\network\admin\
  3. 部分DN一致を使用できない場合は、tnsnames.oraファイルでSSL_SERVER_CERT_DNパラメータ接続文字列を設定し、完全DN一致を構成します:

    ノート:

    tnsnames.oraまたはsqlnet.oraのホスト値を証明書の共通名(CN)の値またはSANフィールドのいずれかのエントリに設定できない場合は、完全DN一致の使用を検討してください。

    リスナー証明書とサーバー証明書の両方が、部分DNと完全DNの両方の一致でチェックされます。完全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_DN_MATCH = TRUE)  
        (SSL_SERVER_CERT_DN="cn=finance,cn=OracleContext,c=us,o=example")))

親トピック: Oracle DatabaseおよびクライアントのTLSの構成

21.3 拡張構成とオプション構成

Oracle Database 23aiでは、デフォルトのTransport Layer Security構成がセキュアで汎用性があります。ただし、Oracleには、この構成をカスタマイズおよび制御するためのパラメータが用意されています。

ノート:

セキュアな構成を確保するために、Oracleでは、使用している環境で必須パラメータおよび推奨パラメータのみを構成することをお薦めします。Oracle Databaseクライアントおよびサーバーが接続を構成している場合、サーバーとクライアントの両方に共通する、最もセキュアなプロトコルおよび暗号スイートが選択されます。TLSプロトコルまたは暗号スイートを選択すると、そのプロトコルまたは暗号スイートを使用できないクライアントがブロックされます。これらの構成はデータベースの更新やアップグレード中にチェックして、選択した値がデータベースのアップグレードまたは更新後にサポートされていることを確認する必要があります。
  • Transport Layer Securityのオプション・パラメータ
    サーバー側のTLS構成は、サーバーが提供するすべての接続に適用されます。これらはデータベース・サーバーのサーバー側構成ファイルsqlnet.ora、およびデータベース・リスナーのlistener.oraで指定されます。
  • 相互Transport Layer Security (mTLS)
    従来のTransport Layer Security (TLS)では、サーバーのみが証明書を提示してクライアントに対して認証されます。相互Transport Layer Security (mTLS)では、サーバーとクライアントの両方が証明書を提示し、相互に認証されるようにします。
  • Oracle Walletの場所
    TLSに使用される証明書は、Oracleウォレットに格納されます。ウォレットを配置できるデフォルトの場所がいくつかあります。ウォレットの場所は、クライアントおよびリスナーのウォレットの場所パラメータを使用して構成することもできます。データベース・サーバーのウォレットの場所には、WALLET_ROOTシステム・パラメータを使用する必要があります。
  • 弱いDN一致の有効化
    SSL_ALLOW_WEAK_DN_MATCHパラメータ制御は、DN一致の動作を以前のデータベース・バージョンに戻します。
  • 秘密キー/証明書の選択
    証明書に使用するOracleウォレットまたはシステム証明書ストアのいずれかに、複数の秘密キー/証明書ペアを格納できます。これは、Autonomous Databaseなど、異なるデータベースがmTLSの異なるクライアント資格証明を割り当てる場合に必要になることがあります。
  • Transport Layer Security暗号化と認証方式の併用
    データベース・ユーザーの名前およびパスワード、RADIUS、Kerberos、PKI証明書、MS-EI、OCI IAMなど、すべての認証メカニズムとTLSを同時に使用するようにOracle Databaseを構成できます。
  • TLSプロトコルおよびTLS暗号スイートの指定
    Oracle Database 23aiでは、TLSプロトコル・バージョン1.2および1.3と、それに関連付けられたTransport Layer Security (TLS)の暗号スイートがサポートされています。
  • 証明書失効リストによる証明書の検証
    オラクル社では、証明書失効リストを使用して証明書を検証できるツールを提供しています。

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

21.3.1 Transport Layer Securityのオプション・パラメータ

サーバー側のTLS構成は、サーバーが提供するすべての接続に適用されます。これらはデータベース・サーバーのサーバー側構成ファイルsqlnet.ora、およびデータベース・リスナーのlistener.oraで指定されます。

クライアント側のTLS構成は、接続固有にすることも、sqlnet.oraを介してすべての接続に適用することもできます。クライアント用のTransport Layer Security (TLS)パラメータの構成方法は2つあります。

  • 静的: これらは構成ファイルsqlnet.oraで指定されたパラメータであり、クライアントによるすべての接続に均一に適用されます。

  • 動的: 必要に応じて、特定のTLSパラメータをTNS接続文字列に直接指定して、sqlnet.ora内の同じまたは類似するパラメータをオーバーライドできます。

表21-2 一般的なTLSパラメータ

パラメータ 説明 サーバー リスナー 静的クライアント 動的クライアント
HTTPS_CLIENT_AUTHENTICATION HTTPS接続用のTLSを使用してクライアントを認証するかどうかを指定します はい はい はい はい
SSL_CLIENT_AUTHENTICATION TLSまたはmTLSを使用してクライアントが認証されるかどうかを指定します はい はい はい はい
WALLET_LOCATION TLSウォレットの場所を指定します。 はい* はい はい はい

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

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

表21-3 ユーザー証明書を選択するためのTLSパラメータ

パラメータ 説明 サーバー リスナー 静的クライアント 動的クライアント
SSL_CERTIFICATE_ALIAS 別名に基づいて証明書を指定します。 はい はい はい はい
SSL_EXTENDED_KEY_USAGE キー使用値に基づいて証明書を指定します。 はい はい はい はい
SSL_CERTIFICATE_THUMBPRINT サムプリントに基づいて証明書を指定します。 はい はい はい はい

ノート:

クライアント側ユーザー証明書の選択は、Windows MCSおよびOracleウォレットでユーザー証明書を操作する場合にのみ適用されます。

表21-4 TLS証明書DN一致パラメータ

パラメータ 説明 サーバー リスナー 静的クライアント 動的クライアント
SSL_ALLOW_WEAK_DN_MATCH サーバー側の証明書の検証中に、以前の弱い識別名(DN)の照合動作を許可します いいえ いいえ はい はい
SSL_SERVER_CERT_DN データベース・サーバーの識別名(DN)を指定します いいえ いいえ いいえ はい
SSL_SERVER_DN_MATCH 識別名(DN)一致によるサーバーのクライアント側検証を強制します いいえ いいえ はい はい
TLS_CERT_VALIDATION_MODE RFC 5280に従ったより厳しいチェックを強制するかどうかを指定します。 いいえ いいえ はい いいえ

表21-5 TLSプロトコルおよび暗号スイートの選択パラメータ

パラメータ 説明 サーバー リスナー 静的クライアント 動的クライアント
SSL_CIPHER_SUITES TLS接続に許可されるTLS暗号スイートを指定します はい はい はい はい
SSL_ENABLE_WEAK_CIPHERS 非推奨のTLS暗号スイートを有効化します はい はい はい はい
SSL_VERSION 接続に使用するTLSプロトコルを指定します はい はい はい はい
TLS_DISABLE_VERSION 接続で許可されないTLSプロトコル(ある場合)を指定します。 はい はい はい はい

親トピック: 拡張構成とオプション構成

21.3.2 相互Transport Layer Security (mTLS)

従来のTransport Layer Security (TLS)では、サーバーのみが証明書を提示してクライアントに対して認証されます。相互Transport Layer Security (mTLS)では、サーバーとクライアントの両方が証明書を提示し、相互に認証されるようにします。

SSL_CLIENT_AUTHENTICATIONパラメータは、クライアント証明書を認証する必要があるかどうかを制御します。これはエンド・ユーザーを認証または認可しません。サーバーとクライアントの両方で使用される証明書が有効であり、既知の認証局(CA)によって署名されていることを認証します。「PKI証明書による認証の構成」では、PKI証明書を使用したエンド・ユーザー認証について詳しく説明します。

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

  • OFF/FALSEは一方向TLSを有効にするmTLSを無効にします。
  • ON/TRUEはmTLSを有効にします。サーバーでOn/TRUEに設定されている場合、一方向TLSは無効になります。クライアントでOn/TRUEに設定されている場合、クライアントはmTLSの確立を試みますが、サーバーが一方向TLSで構成されている場合、一方向TLSは引き続き許可されます。
  • OPTIONAL (サーバーのみの構成値)を使用すると、サーバーは次のように動作できます:
    • クライアントが証明書を送信すると、接続はクライアント証明書の認証後にmTLS接続として完了します。
    • クライアントが証明書を送信していないと、接続は一方向TLS接続として完了します。
  • サーバー証明書DN一致
    Oracleでは、サーバー証明書DN一致を使用することをお薦めします。これは、一方向TLSでサーバーDN一致を使用する場合と同様に、クライアントが目的のサーバーに接続していることを確認するためです。

親トピック: 拡張構成とオプション構成

21.3.2.1 サーバーおよびリスナー・ウォレットの作成
公開署名認証局によって署名された証明書を取得するには、データベース・サーバーおよびリスナー・ウォレットを作成し、証明書署名リクエスト(CSR)をエクスポートする必要があります。
  1. データベースがインストールされているホストにログインします。
  2. ウォレットを作成します。
    orapki wallet create -wallet <wallet location> -pwd <wallet password> -auto_login
  3. 信頼できるルート証明書をウォレットに追加します(これは証明書管理者から取得します)。
    orapki wallet add -wallet <wallet location> -trusted_cert -cert <trusted root certificate location>/rootCA.crt -pwd <wallet password>
  4. ウォレットに秘密キーおよび証明書リクエストを作成します。
    orapki wallet add -wallet <wallet location> -keysize 2048 -dn <certificate_dn> -pwd <wallet password>
  5. 証明書リクエストをエクスポートして、署名を受けます。
    orapki wallet export -wallet <wallet location> -dn <certificate_dn> -request <certificate signing request location>/<file_name>.csr -pwd <wallet password>
  6. ウォレットの内容を表示します。
    orapki wallet display -wallet <wallet_location>

    「Requested Certificates」の下にエントリがあります。

  7. CSR (証明書署名リクエスト)ファイルの内容を表示します。
    cat <certificate_signing_request_location>/<file_name>.csr
  8. CSRファイルを証明書管理者に送信して、ルート認証局(CA)または中間CAによる署名を受けます。
  9. 署名されたデータベース・サーバー・ユーザー証明書をデータベース・ウォレットにインポートします。
    orapki wallet add -wallet <wallet location> -user_cert -cert <signed certificate location>/<file_name_signed>.crt -pwd <wallet password>
  10. ウォレットの内容を表示します:
    orapki wallet display -wallet <wallet location>
  11. データベース・サーバー・ユーザー証明書がUser Certificatesの下に表示されていることを確認します。
    データベース・サーバーおよびリスナーに使用するウォレットは、使用のためにデプロイする準備ができました。
21.3.2.2 WALLET_ROOTの設定とデータベース・サーバー・ウォレットのデプロイ
  1. WALLET_ROOTがすでに存在するかどうかを確認します。システム・パラメータを確認する権限を持つユーザーとしてログインし、次を実行します:
    SHOW PARAMETER WALLET_ROOT
    WALLET_ROOTがまだ設定されていない場合は、次のコマンドを実行してWALLET_ROOTを作成します。
  2. システム・パラメータであるWALLET_ROOTを作成します。次のSQLコマンドを実行します。
    alter system set wallet_root = '<wallet_root_directory>' scope=spfile;
  3. データベースを再起動します。
  4. 変更されたwallet_rootパラメータを表示します。次のSQLコマンドを実行します。
    show parameter wallet_root;
  5. TLSディレクトリがWALLET_ROOTの下にまだ存在しない場合は、オペレーティング・システムのWALLET_ROOT PDBディレクトリの下に、TLS用のディレクトリを作成します。
    mkdir -p -v <wallet_root_directory>/<PDB GUID>/tls
    PDBのPDB GUIDを確認するには、次のSQLコマンドを実行します:
    select guid from v\$containers;
  6. ディレクトリの所有者を変更します。
    sudo chown oracle:oinstall -R -v <wallet_root_directory>/<PDB GUID>/tls
  7. データベース・サーバーewallet.p12およびcwallet.ssoファイルをこの新しいtlsディレクトリにコピーします。

    ウォレットが作成されたのと同じディレクトリから次のコマンドを実行します:

    cp ./ewallet.p12 ./cwallet.sso <wallet_root_directory>/<PDB GUID>/tls
21.3.2.3 mTLSのデータベース・サーバー構成
  1. Oracleデータベースが存在するサーバーにログインします。
  2. sqlnet.oraファイルのSSL_CLIENT_AUTHENTICATIONがTRUEに設定されていることを確認します。これにより、mTLSが有効になります:
    デフォルトでは、sqlnet.oraファイルは、$ORACLE_HOME/network/adminディレクトリ、またはTNS_ADMIN環境変数によって設定されている場所にあります。 
    SSL_CLIENT_AUTHENTICATION=TRUE
    かわりに、TLSとmTLSの両方を有効にし、クライアントがクライアント・ユーザー証明書を送信するかどうかに依存するOPTIONALに設定できます。
21.3.2.4 mTLSのリスナー構成
  1. listener.oraファイルのPROTOCOLパラメータをチェックして、TLSが指定されていることを確認します。
    デフォルトでは、listener.oraは$ORACLE_HOME/network/adminディレクトリに配置されます。

    パラメータPROTOCOL=tcpsは、データベース接続にTLS (またはmTLS)のみを使用するようにリスナーに指示します。

    次に例を示します:
    LISTENER = (ADDRESS=(PROTOCOL=tcps)(HOST=<host_name>)(PORT=1522))
  2. listener.oraファイルのWALLET_LOCATIONパラメータの場所にリスナー・ウォレットが存在することを確認します。データベース・サーバーの場合と同じウォレットを使用します。
    WALLET_LOCATION=  
    (SOURCE=    
        (METHOD=file)    
        (METHOD_DATA=       
            (DIRECTORY=$WALLET_DIR/<pdb guid>/tls)))

    リスナーがデータベース・サーバーと同じサーバー上にあり、サーバーのTLSウォレットがデフォルトの場所にある場合は、リスナーWALLET_LOCATIONを同じ場所に設定します。または、サーバー・ウォレットをリスナーの別の場所にコピーできます。

    DN一致(部分または完全DN一致)に対してSSL_SERVER_DN_MATCHパラメータをTRUEに設定すると、リスナー証明書とサーバー証明書の両方に対してホスト名またはDNチェックが実行されます。同じ証明書である必要はありませんが、両方の証明書で一致が行われます。

  3. 相互TLSを有効にするには、listener.oraファイルでSSL_CLIENT_AUTHENTICATIONパラメータがTRUEに設定されていることを確認します。
    SSL_CLIENT_AUTHENTICATION=TRUE
21.3.2.5 mTLSのクライアント構成
  1. Oracleデータベースのクライアントにログインします。
  2. sqlnet.oraおよびtnsnames.oraファイルのSSL_CLIENT_AUTHENTICATIONをTRUEに設定します。
    TRUEに設定すると、クライアント側ユーザー証明書がサーバーに送信されます。これは、すべての接続に適用されるため、tnsnames.ora接続文字列のSSL_CLIENT_AUTHENTICATIONパラメータは、sqlnet.ora設定よりも優先される同じパラメータ設定を使用して変更できます。 
    SSL_CLIENT_AUTHENTICATION=TRUE

    ヒント:

    このパラメータのデフォルト値はtrueですが、明示的にtrueに設定すると、接続の問題のトラブルシューティングが容易になります。
  3. 複数のデータベースに接続し、その一部がmTLSを必要とし、他のTLS接続でウォレットを必要としない場合は、異なるデータベースに接続するための共通ウォレットがあるか、または各mTLS接続に異なるウォレットが必要かに応じて、異なる接続を設定するための2つのオプションがあります:
    1. sqlnet.oraでWALLET_LOCATIONを設定して、共通のmTLSクライアント・ウォレットを指定します。

      これにより、同じクライアント・ウォレットを使用するすべてのmTLS接続をデータベースに接続します。

    2. 一方向TLS接続の接続文字列で次のようにします。
      1. SSL_CLIENT_AUTHENTICATION = FALSEを設定して、mTLSクライアント・ウォレット設定をオーバーライドします。
      2. WALLET_LOCATION = SYSTEMを設定して、システムのデフォルト証明書ストアを指定します。

    これは、データベース接続ごとに異なるクライアント・ウォレットを使用する必要がある場合に使用できます。

    1. ウォレットを使用しないTLS接続を可能にするには、sqlnet.oraでWALLET_LOCATION = SYSTEMを設定します。
    2. すべてのmTLS接続にWALLET_LOCATIONを設定して、それぞれの接続に一意のウォレットの場所を指定します。

関連トピック

21.3.2.6 データベースに接続します

tcpsプロトコルで接続名を使用してデータベースに接続します。

sqlplus <user_name>@<PDB_name>
21.3.2.7 サーバー証明書DN一致

Oracleでは、サーバー証明書DN一致を使用することをお薦めします。これは、一方向TLSでサーバーDN一致を使用する場合と同様に、クライアントが目的のサーバーに接続していることを確認するためです。

tnsnames.oraファイルでSSL_SERVER_CERT_DNパラメータ接続文字列を設定し、完全DN一致を構成します:

ノート:

tnsnames.oraまたはsqlnet.oraのホスト値を証明書の共通名(CN)の値またはSANフィールドのいずれかのエントリに設定できない場合は、完全DN一致の使用を検討してください。

リスナー証明書とサーバー証明書の両方が、部分DNと完全DNの両方の一致でチェックされます。完全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_DN_MATCH = TRUE)  
        (SSL_SERVER_CERT_DN="cn=finance,cn=OracleContext,c=us,o=example")))

21.3.3 Oracleウォレットの場所

TLSに使用される証明書は、Oracleウォレットに格納されます。ウォレットを配置できるデフォルトの場所がいくつかあります。ウォレットの場所は、クライアントおよびリスナーのウォレットの場所パラメータを使用して構成することもできます。データベース・サーバーのウォレットの場所には、WALLET_ROOTシステム・パラメータを使用する必要があります。

  • クライアントのウォレットの場所の構成
    クライアントのウォレットの場所は、パラメータWALLET_LOCATIONを使用して構成できます。sqlnet.oraで WALLET_LOCATIONパラメータを構成すると、すべての接続に適用されます。接続固有のウォレットが必要な場合は、接続用のWALLET_LOCATIONを構成して、sqlnet.oraのWALLET_LOCATIONをオーバーライドできます。
  • リスナーのウォレットの場所の構成
    リスナーのウォレットの場所は、listener.oraのWALLET_LOCATIONパラメータを使用して構成できます。
  • サーバーのPDBウォレットの場所の構成
    マルチテナント・アーキテクチャを使用すると、Oracle Databaseを、ユーザーが作成した1つ以上のプラガブル・データベース(PDB)を含むマルチテナント・コンテナ・データベース(CDB)として機能させることができます。
  • Oracleウォレットの検索順序
    Oracle Databaseは、Transport Layer Security (TLS)環境でサーバーのウォレットを検索するための複数のルートを用意しています。

親トピック: 拡張構成とオプション構成

21.3.3.1 クライアントのウォレットの場所の構成

クライアントのウォレットの場所は、パラメータWALLET_LOCATIONを使用して構成できます。sqlnet.oraで WALLET_LOCATIONパラメータを構成すると、すべての接続に適用されます。接続固有のウォレットが必要な場合は、接続用のWALLET_LOCATIONを構成して、sqlnet.oraのWALLET_LOCATIONをオーバーライドできます。

特定のプラットフォームでは、一方向TLS認証用のクライアントを設定する際にウォレットは不要であり、構成にウォレットの場所も不要です。Oracle Databaseでは、システムにインストールされている信頼できるCA証明書を使用して、一方向TLSに対応できます。詳細およびサポートされているプラットフォームのリストは、前のトピック「クライアント・ウォレットを使用しないTransport Layer Security接続」を参照してください。

静的構成の例 (sqlnet.ora)
WALLET_LOCATION =
(SOURCE=
  (METHOD=File)
  (METHOD_DATA=
     (DIRECTORY=your_wallet_dir)
      )
)
動的(接続前)構成の例 (tnsnames.ora)
svc_name=(DESCRIPTION=
            (ADDRESS=(...))
            (CONNECT_DATA=(...))
            (SECURITY=
                (WALLET_LOCATION=your_wallet_dir)
            )
          )
21.3.3.2 リスナーのウォレットの場所の構成

リスナーのウォレットの場所は、listener.oraのWALLET_LOCATIONパラメータを使用して構成できます。

WALLET_LOCATIONは、listener.oraの各リスナーに指定できます。

次に例を示します。 
LISTENER = 
    (DESCRIPTION=
        (ADDRESS=
            (PROTOCOL=tcps)
            (HOST=)
            (PORT=5678))
        (SECURITY=
            (WALLET_LOCATION=dir1)))

LISTENER2 =
    (DESCRIPTION=
        (ADDRESS=
            (PROTOCOL=tcps)
            (HOST=)
            (PORT=5679))
        (SECURITY=
            (WALLET_LOCATION=dir2)))
21.3.3.3 サーバーのPDBウォレットの場所の構成

マルチテナント・アーキテクチャを使用すると、Oracle Databaseを、ユーザーが作成した1つ以上のプラガブル・データベース(PDB)を含むマルチテナント・コンテナ・データベース(CDB)として機能させることができます。

CDB$ROOTと各PDBは、init.oraファイルで定義されたWALLET_ROOTシステム・パラメータで構成できる独自のローカル・ウォレットを持つことができます。

たとえば、CDBルート・コンテナの場合(CDB内のすべてのコンテナには適用されません):
WALLET_ROOT/tls
たとえば、PDBの場合:
WALLET_ROOT/<pdb_GUID>/tls

ノート:

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

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

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

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

Oracle DatabaseサーバーがTLSで使用するウォレットを特定する方法

Oracle Databaseサーバーは、次の場所を指定の順序で検索して、ウォレットを特定します。データベースに1つ以上のプラガブル・データベース(PDB)がある場合は、pdb_GUIDの値をPDBのグローバル識別子(GUID)に置き換える必要があります。

  1. init.oraファイルのWALLET_ROOTシステム・パラメータによって定義された場所:
    • PDBの場合はWALLET_ROOT/<pdb_ID>/tls
    • CDBルート・コンテナCDB$ROOTの場合はWALLET_ROOT/tls、
  2. sqlnet.oraファイルのWALLET_LOCATIONによって定義された場所:
    • WALLET_LOCATION

      ノート:

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

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

  3. $TNS_ADMIN環境変数によって定義された場所。これは、チェックされる唯一のディレクトリの場所であり、この場所の下にあるサブディレクトリではありません。
  4. デフォルトのウォレットの場所:
    • Linux: /etc/ORACLE/WALLETS/user_name

      これは、チェックされる唯一のディレクトリの場所であり、この場所の下にあるサブディレクトリではありません。

    • Windows: C:\Users\user_name\ORACLE\WALLETS

      これは、チェックされる唯一のディレクトリの場所であり、この場所の下にあるサブディレクトリではありません。

  5. CDBコンテナ・データベースの一部またはすべてに単一のウォレットが必要な場合は、TNS_ADMINまたはデフォルトのウォレットの場所にウォレットを配置します。WALLET_ROOTの下にウォレットが見つからない場合、PDBはその場所にデフォルト設定されます。

Oracle DatabaseリスナーがTLSで使用するウォレットを特定する方法

Oracle Databaseリスナーは、これらの場所を指定の順序で検索して、ウォレットの場所を特定します:

  1. listener.oraファイルのWALLET_LOCATIONパラメータによって定義された場所
  2. $TNS_ADMIN環境変数によって定義された場所
  3. デフォルトのウォレットの場所:
    • Linux: /etc/ORACLE/WALLETS/user_name
    • Windows: C:\Users\user_name\ORACLE\WALLETS

Oracle DatabaseクライアントがTLSで使用するウォレットを特定する方法

Oracle Databaseクライアントは、これらの場所を指定の順序で検索して、ウォレットを特定します:

  1. 接続文字列のWALLET_LOCATIONパラメータによって定義された場所
  2. sqlnet.oraファイルのWALLET_LOCATIONパラメータによって定義された場所
  3. $TNS_ADMIN環境変数によって定義された場所
  4. デフォルトのウォレットの場所:
    • Linux: /etc/ORACLE/WALLETS/user_name
    • Windows: C:\Users\user_name\ORACLE\WALLETS
  5. システム証明書ストア

    一方向TLS認証が必要な場合、Oracle Databaseクライアントは、システム証明書ストアに格納されている信頼できるCA証明書を使用できます。クライアントが接続でクライアント認証に対応する必要がある場合は、必要とされる信頼できるCA証明書とともに独自の証明書を含むウォレットを設定する必要があります。

    デフォルトの証明書ストアの場所はプラットフォームによって異なります。現在、Oracle Databaseでは、Microsoft WindowsおよびLinuxでこの方法をネイティブにサポートしています。

    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ファイルである必要があります

ノート:

証明書ストアのデフォルトの場所は変更できません。

21.3.4 弱いDN一致の有効化

SSL_ALLOW_WEAK_DN_MATCHパラメータ制御は、DN一致の動作を以前のデータベース・バージョンに戻します。

Oracle Database 23ai以降、SSL_SERVER_DN_MATCHパラメータの動作が変更されました。

識別名(DN)によるサーバー側の証明書の検証が、リスナー証明書とデータベース・サーバー証明書の両方がチェックされるように変更されました。以前のOracle Databaseリリースでは、データベース・サーバー証明書のみがチェックされていました。本番ではほとんどのケースで、リスナーとデータベースで同じ証明書が使用されます。異なる証明書が使用されている場合、DN一致では、SANまたはホスト名証明書情報での部分DN一致を可能にするために新しい証明書が必要になることがあります。リスナー証明書の確認に加えて、部分DN一致を使用する際にはSERVICE_NAMEパラメータが無視されて、ホスト名接続文字列パラメータのみが証明書共通名(CN)およびサブジェクト代替名(SAN)フィールドに対してチェックされます。以前のリリースでの動作(ホスト名に加えてサービス名を使用し、データベース・サーバー証明書のみをチェックする)に戻すには、新しいパラメータSSL_ALLOW_WEAK_DN_MATCH=TRUEを設定します。デフォルトはFALSEです。

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

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

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

  • 新しい証明書を取得します(自己署名証明書にはorapki wallet addコマンドを使用します)。
  • 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.3.5 秘密キー/証明書の選択

証明書に使用するOracleウォレットまたはシステム証明書ストアのいずれかに、複数の秘密キー/証明書ペアを格納できます。これは、Autonomous Databaseなど、異なるデータベースがmTLSの異なるクライアント資格証明を割り当てる場合に必要になることがあります。

Windows MCSおよびOracleウォレットで使用する秘密キー/証明書のみを指定できます。

データベース接続に使用する正しい秘密キー/証明書を指定する必要があります。Windowsでクライアント認証用の証明書選択パラメータを設定すると、MSCAPI証明書の選択ボックスが表示されなくなり、一致する証明書がTransport Layer Securityに自動的に使用されます。

クライアントはMCSまたはウォレットから特定の秘密キー/証明書を選択する必要がある可能性が高くなりますが、ウォレットに複数の証明書がある場合、サーバーおよびリスナーも使用する特定の証明書を選択する必要があります。

親トピック: 拡張構成とオプション構成

21.3.5.1 SSL_CERTIFICATE_ALIASパラメータの設定

SSL_CERTIFICATE_ALIASパラメータを使用して、クライアント証明書の別名を指定できます。

  1. 別名値を取得するには、次のorapkiコマンドを実行します: 

    orapki wallet display -wallet wallet_directory -pwd wallet_password -complete
    出力は次のようになりますAliasフィールドを参照してください。
    User Certificates:
Alias: sslClient
Subject: CN=ssl
ClientIssuer: CN=sslRoot,C=US
Not Before: Thu Jul 18 22:29:17 UTC 2024
Not After: Sun Jul 16 22:29:17 UTC 2034
Serial Number: 01
Key Length: 2048
MD5 digest: 06:DD:79:AF:E6:D6:70:CE:C3:98:DE:8C:D7:FC:7E:C2
SHA-256 digest: 09:B2:EC:FE:A1:B8:C3:F3:F5:A7:DC:C6:00:26:86:BE:39:54:16:93:B6:A8:42:CC:69:24:0F:B5:59:43:3F:AA
SHA-1 digest: 51:25:6F:45:F8:64:E5:CB:9E:56:D2:F2:0C:5C:A6:D5:61:DA:DB:FE
  2. SSL_CERTIFICATE_ALIASパラメータを使用して、Alias値を設定します。

    たとえば、tnsnames.oraの場合: 

    net_service_name= 
      (DESCRIPTION=
        (ADDRESS=(PROTOCOL=tcps)(HOST=sales-svr)(PORT=1522)) 
        (SECURITY=(SSL_CERTIFICATE_ALIAS=sslClient))
      )

    この例では、sqlnet.oraファイルでSSL_CERTIFICATE_ALIASを設定する方法を示します: 

    SSL_CERTIFICATE_ALIAS=sslClient
21.3.5.2 SSL_CERTIFICATE_THUMBPRINTパラメータの設定

SSL_CERTIFICATE_THUMBPRINTを使用して、クライアント証明書のサムプリントを指定できます。

パラメータの値は、クライアント証明書のSHA-1またはSHA-256サムプリント(algorithm:hash形式)です

  1. サムプリント値を取得するには、次のorapkiコマンドを実行します: 

    orapki wallet display -wallet wallet_directory -pwd wallet_password -complete
    出力は次のようになりますサムプリント値については、SHA-1 digestまたはSHA-256 digestフィールドを参照してください。
    User Certificates:
Alias: sslClient
Subject: CN=ssl
ClientIssuer: CN=sslRoot,C=US
Not Before: Thu Jul 18 22:29:17 UTC 2024
Not After: Sun Jul 16 22:29:17 UTC 2034
Serial Number: 01
Key Length: 2048
MD5 digest: 06:DD:79:AF:E6:D6:70:CE:C3:98:DE:8C:D7:FC:7E:C2
SHA-256 digest: 09:B2:EC:FE:A1:B8:C3:F3:F5:A7:DC:C6:00:26:86:BE:39:54:16:93:B6:A8:42:CC:69:24:0F:B5:59:43:3F:AA
SHA-1 digest: 51:25:6F:45:F8:64:E5:CB:9E:56:D2:F2:0C:5C:A6:D5:61:DA:DB:FE
  2. SSL_CERTIFICATE_THUMBPRINTパラメータを使用してこの値を設定します。次の例は、これをtnsnames.oraファイルで設定する方法を示しています。

    たとえば、tnsname.oraファイルでは次のようになります: 

    net_service_name= 
      (DESCRIPTION=
        (ADDRESS=(PROTOCOL=tcps)(HOST=sales-svr)(PORT=1522)) 
        (SECURITY=(SSL_CERTIFICATE_THUMBPRINT=SHA1:1B:11:01:5A:B1:2C:20:B2:12:34:3E:04:7B:83:47:DE:70:2E:4E:11))
      )

    この例では、sqlnet.oraファイルでSSL_CERTIFICATE_THUMBPRINTを設定する方法を示します: 

    SSL_CERTIFICATE_THUMBPRINT=SHA256:B38A5B1A036383922B5DE15361EE03940A56B456417E4124419B88EBC61E1123
21.3.5.3 SSL_EXTENDED_KEY_USAGEパラメータの設定

SSL_EXTENDED_KEY_USAGEパラメータを使用して、クライアント証明書の拡張キーの使用を指定できます。

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

  • たとえば、sqlnet.oraファイルでは次のようになります: 

    SSL_EXTENDED_KEY_USAGE = "client authentication"
拡張キーの使用は、orapkiを使用して証明書から確認できます:
orapki cert display -cert <certificate> -complete

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

データベース・ユーザーの名前およびパスワード、RADIUS、Kerberos、PKI証明書、MS-EI、OCI IAMなど、すべての認証メカニズムとTLSを同時に使用するようにOracle Databaseを構成できます。

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

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

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

図21-1 認証アダプタを使用したOracle Net Services

図21-1の説明が続きます
「図21-1 認証アダプタを使用したOracle Net Services」の説明

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

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

**INTERNAL XREF ERROR**に、Transport Layer Securityが別の認証方式と併用されている構成を示します。

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

図21-2の説明が続きます
「図21-2 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を使用してデータベースに安全にアクセスできるようになります。

関連トピック

親トピック: 拡張構成とオプション構成

21.3.7 TLSプロトコルおよびTLS暗号スイートの指定

Oracle Database 23aiでは、TLSプロトコル・バージョン1.2および1.3、およびそれに関連付けられたTransport Layer Security (TLS)の暗号スイートがサポートされています。

Oracleには、特定のプロトコル・バージョンおよび暗号スイートを構成するための構成パラメータSSL_VERSIONおよびSSL_CIPHER_SUITEがあります。ただし、Oracleでは、必要でないかぎりこれらのパラメータを指定しないことをお薦めします。これらの値を省略すると、(使用可能な最上位バージョンが選択されていることが保証される)最強の共通TLSバージョンおよび関連する暗号スイートの自動検出が容易になります。Oracle Databaseでは、TLS_AES_256_GCM_SHA384暗号スイートがデフォルトとして使用されます。

  • TLSプロトコル・バージョンの構成
    SSL_VERSIONパラメータとTLS_DISABLE_VERSIONパラメータは、指定されたコンポーネントのエンド・ポイントで強制されるTLSのプロトコル・バージョンを定義します。
  • TLS暗号スイートの構成
    暗号スイートは、ネットワーク・エンティティ間のメッセージ交換に使用される認証、暗号化およびデータ整合性アルゴリズムのセットです。
  • 以前のアルゴリズムからの証明書の許可
    ALLOWED_WEAK_CERT_ALGORITHMS sqlnet.oraまたはlistener.oraパラメータを設定することで、以前の非推奨(および脆弱な)アルゴリズムに関連付けられた証明書を使用できます。

親トピック: 拡張構成とオプション構成

21.3.7.1 TLSプロトコル・バージョンの構成

SSL_VERSIONパラメータとTLS_DISABLE_VERSIONパラメータは、指定されたコンポーネントのエンド・ポイントで強制されるTLSのプロトコル・バージョンを定義します。

SSL_VERSIONおよびTLS_DISABLE_VERSIONは、データベース・サーバー、リスナー、クライアントまたはこれらのコンポーネントの組合せで指定できます。TLSプロトコル・バージョンがこれらの場所の1つ以上で指定されている場合は、すべてのコンポーネントで少なくとも1つのバージョンが共通している必要があります。そうでない場合、接続は拒否されます。また、別のコンポーネントでサポートされていないTLSプロトコル・バージョンが指定されている場合、接続リクエストも拒否されます。

SSL_VERSIONパラメータとTLS_DISABLE_VERSIONパラメータは、クライアントまたはサーバーのsqlnet.oraファイルまたはlistener.oraファイルに設定できます。

SSL_VERSIONパラメータ

サーバーのsqlnet.oraファイルで、SSL_VERSIONパラメータを設定して、サーバーでサポートされているTLSバージョンを指定します。

有効な値は、undetermined (デフォルト)、TLSv1.2およびTLSv1.3です。複数のエントリはカンマで区切ります。次に例を示します:
SSL_VERSION=(TLSv1.2,TLSv1.3)
値に+を付加して、最小バージョンを指定します。次に例を示します:
SSL_VERSION=TLSv1.2+
TLS1.2以降を許可します。
SSL_VERSIONおよびTLS_DISABLE_VERSIONが設定されていないか、SSL_VERSIONがundeterminedに設定されている場合、サポートされているすべてのTLSバージョンが有効になります。

ヒント:

Oracleでは、サーバーとクライアント間で最高バージョンが自動的に検出されるように、これらのパラメータを指定しないことをお薦めします。

TLSv1.3 を明示的に強制する環境では、次のようにプロトコル・バージョンを指定できます:

SSL_VERSION = TLSv1.3

TLS_DISABLE_VERSIONパラメータ

サーバーのsqlnet.oraファイルで、TLS_DISABLE_VERSIONパラメータを設定して、サーバーで許可されないTLSバージョンを指定します。

有効な値は、TLSv1.2およびTLSv1.3です。複数のエントリはカンマで区切ります。次に例を示します:
TLS_DISABLE_VERSION=(TLSv1.2,TLSv1.3)
TLS1.2およびTLS1.3は許可されません。
21.3.7.2 TLS暗号スイートの構成

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

Transport Layer Securityハンドシェイク時に、2つのエンティティがネゴシエーションし、ネットワークを介してメッセージを相互に送信するときに使用する暗号スイートを選択します。

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

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

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

  • 暗号の優先順位と強度: 可能なかぎり最高レベルのセキュリティを確保するために、暗号スイートを最強のものから最弱のものへと優先順位を付けます。

  • 使用するセキュリティのレベル: これを使用して、暗号スイートの弱い、古いクライアントがデータベースに接続しないようにします

  • 強力なTLS暗号スイート
    Oracleは、デフォルトで強力なTransport Layer Security (TLS)暗号スイートを提供します。ただし、Oracle Database 23ai以降では、TLSv1.2以上のみをサポートしています。次の表に、Oracleでサポートされているデフォルトの暗号を示します。
  • 非推奨のTLS暗号スイート
    レガシー製品に対応するために、Oracleでは、安全性が低いと考えられるTLS暗号スイートを提供しています。これらの暗号は、デフォルトで非推奨および無効になっています。次の表に、Oracleでサポートされている非推奨の暗号を示します。
  • 脆弱な暗号スイートの有効化
    SSL_ENABLE_WEAK_CIPHERSパラメータを設定して、非推奨の暗号スイートを有効にできます。弱い暗号スイートで接続を確立するには、3つのコンポーネント(クライアント、リスナーおよびサーバー)すべてで弱い暗号スイートを有効にする必要があります。

親トピック: TLSプロトコルおよびTLS暗号スイートの指定

21.3.7.2.1 強力なTLS暗号スイート

Oracleは、デフォルトで強力なTransport Layer Security (TLS)暗号スイートを提供します。ただし、Oracle Database 23ai以降では、TLSv1.2以上のみをサポートしています。次の表に、Oracleでサポートされているデフォルトの暗号を示します。

表21-6 承認済TLS暗号スイート

暗号スイート 認証 暗号化 データ整合性 TLSの互換性
TLS_AES_128_CCM_SHA256 ECDHE_RSA, DHE_RSA, ECDHE_ECDSA AES 128 CCM SHA256 (SHA 2) TLS 1.3
TLS_AES_128_GCM_SHA256 ECDHE_RSA, DHE_RSA, ECDHE_ECDSA AES 128 GCM SHA256 (SHA-2) TLS 1.3
TLS_AES_256_GCM_SHA384 ECDHE_RSA, DHE_RSA, ECDHE_ECDSA AES 256 GCM SHA384 (SHA-2) TLS 1.3
TLS_CHACHA20_POLY1305_SHA256 (FIPS以外のみ) ECDHE_RSA, DHE_RSA, ECDHE_ECDSA CHACHA20 POLY1305 SHA256 (SHA-2) TLS 1.3
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_GCM_SHA384 DHE_RSA AES 256 GCM SHA384 (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_GCM_SHA384 ECDHE_ECDSA AES 256 GCM SHA384 (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_GCM_SHA384 ECDHE_RSA AES 256 GCM SHA384 (SHA-2) TLS 1.2
21.3.7.2.2 非推奨のTLS暗号スイート

Oracleではレガシー製品に対応するために、安全性が低いと考えられるTLS暗号スイートを提供しています。これらの暗号は、デフォルトで非推奨および無効になっています。次の表に、Oracleでサポートされている非推奨の暗号を示します。

表21-7 非推奨のTLS暗号スイート

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

TLS_DHE_RSA_WITH_AES_128_CBC_SHA256

DHE_RSA

AES 128 CBC

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_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_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_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_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_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.3.7.2.3 脆弱な暗号スイートの有効化

SSL_ENABLE_WEAK_CIPHERSパラメータを設定することにより、非推奨の暗号スイートを有効にできます。弱い暗号スイートで接続を確立するには、3つのコンポーネント(クライアント、リスナーおよびサーバー)すべてで弱い暗号スイートを有効にする必要があります。

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

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

たとえば、非推奨の暗号スイートを有効にするには、次のようにします。

SSL_ENABLE_WEAK_CIPHERS=TRUE
21.3.7.3 以前のアルゴリズムからの証明書の許可

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

ALLOWED_WEAK_CERT_ALGORITHMSを使用すると、以前のアルゴリズムを明示的に有効にできます。ただし、以前のアルゴリズムは新しいアルゴリズムより安全ではないことに注意してください。このパラメータは、Oracle Databaseリリース23ai以降は非推奨であるALLOW_MD5_CERTSおよびALLOW_SHA1_CERTSパラメータに置き換ります。
  1. データベース・サーバーまたはクライアント・サーバーにログインします。
  2. sqlnet.oraまたはlistener.oraパラメータ・ファイルを編集して、ALLOWED_WEAK_CERT_ALGORITHMSパラメータを含めます。

    MD5は、デフォルトで無効になっています。SHA1は、デフォルトで有効になっています。sqlnet.oraファイルのデフォルトの場所は$ORACLE_HOME/network/adminディレクトリ内に存在します。

    次を指定できます:
    • SHA1 - デフォルトで有効になり、SHA1を有効にし、MD5を無効にします
    • MD5 - MD5を有効にし、SHA1を無効にします
    • NONE - MD5とSHA1の両方が無効になります
    SHA1とMD5の両方を指定する場合は、カンマで区切ります。次に例を示します: 
    ALLOWED_WEAK_CERT_ALGORITHMS = (MD5,SHA1)

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

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

親トピック: 拡張構成とオプション構成

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

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

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

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

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

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

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

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

21.3.8.2 使用するCRLの選択方法

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

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

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

21.3.8.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.3.8.4 証明書失効リストによる証明書検証の構成

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

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

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

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

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

ノート:

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

21.3.8.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. 必要に応じて、sqlnet.oraファイルでTLS_CERT_VALIDATION_MODEパラメータを変更します。
    TLS_CERT_VALIDATION=value

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

    • strictは、RFC 5280に従ってCA証明書検証においてより厳密なチェックを強制します。
    • non-strictはデフォルト値であり、CA証明書検証が緩和され、RFC 5280のすべての制約に従わないことを意味します。
  4. CRLがローカル・ファイル・システムに格納されている場合は、次のsqlnet.oraパラメータの一方または両方を設定して、格納場所を指定します。
    • SSL_CRL_PATHは、CRLが格納されているディレクトリへのパスを設定します。この設定を省略すると、デフォルトはウォレット・ディレクトリになります。DERエンコードされた(バイナリ形式) CRLおよびPEMエンコードされた(BASE64) CRLの両方がサポートされています。CRLをローカル・ファイル・システム・ディレクトリに格納する場合は、orapkiユーティリティを使用して、システムが特定できるようにCRLの名前を変更する必要があります。
    • SSL_CRL_FILEは、包括的CRLファイル(PEMエンコードされた(BASE64) CRLが優先度の順に1つのファイルに連結されたもの)へのパスを設定します。ファイルが指定の場所に存在するか、アプリケーションを起動できないことを確認します。
  5. Oracle Internet DirectoryからCRLをフェッチする場合は、ldap.oraファイルを編集してディレクトリ・サーバーおよびポートの情報を含めます。

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

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

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

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

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

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

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

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

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

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

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

ノート:

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

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

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

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

    orapki crl help

ノート:

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

21.3.8.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.3.8.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.3.8.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ポートです。Oracle Internet DirectoryへのCRLのアップロード
21.3.8.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.3.8.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.3.8.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.3.8.7 証明書検証に関連するOracle Netトレース・ファイルのエラー・メッセージ

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

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

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

CRLの署名検証に失敗しました

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

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

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

CRLの日付検証に失敗しました

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

  1. ファイル・システム

  2. Oracle Internet Directory

  3. CRL DP

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

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

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

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

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

  1. Oracle Net Managerを使用して、正しいCRLの場所が構成されているかどうかを確認します。証明書失効リストによる証明書検証の構成を参照してください

  2. 必要に応じて、orapkiユーティリティを使用してシステムで使用するCRLを次のように構成します。

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. orapkiユーティリティを使用して、システムで使用するCRLを構成します。証明書検証用ハッシュ値によるCRLの名前変更を参照してください

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

  1. Oracle Net Configuration Assistantを使用して、ディレクトリ接続情報を含むldap.oraファイルを作成し、構成します。

  2. orapkiユーティリティを使用して、CRLをディレクトリにアップロードします。Oracle Internet DirectoryへのCRLのアップロードを参照してください

21.4 TLSおよびその他のOracle製品

Transport Layer Security (TLS)は、他のOracle Database製品を使用する場合に構成できます。

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

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

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

親トピック: TLSおよびその他のOracle製品

21.4.1.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)))
21.4.1.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インスタンスを再起動します。
21.4.1.3 ステップ3: Transport Layer Securityウォレットおよび証明書の作成

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

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

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

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

  • 各クラスタ・ノード(サーバー)およびリスナーには、ユーザー証明書およびCA証明書を含むウォレットが必要です。
  • 一方向のTLSが構成されている場合、クライアントはリスナーおよびサーバーのCA証明書(ウォレットまたはシステムの証明書ストア内)のみを必要とします。
  • mTLSが構成されている場合、クライアントには、ユーザー証明書とリスナーおよびサーバーのCA証明書を含むウォレットが必要です。
21.4.1.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__wallet_directory>
    3. CAウォレット用の自己署名ルート証明書を作成します。
      $ orapki wallet add -wallet <CA__wallet_directory> -self_signed -dn "CN=test CA,O=test,C=c" -keysize 2048 -validity 3650 -sign_alg sha256
    4. ウォレットからルートCA証明書を抽出します。
      このルート証明書はクラスタ・ウォレットまたはクライアント・ウォレットで信頼できるCA証明書として使用され、PKCS#12ウォレットを管理するユーザーに対し配布または公開できます。
      $ orapki wallet export -wallet <CA__wallet_directory> -dn "CN=test CA,O=test,C=c" -cert testCAroot.cer

      構成を確認するには:

       $ orapki wallet display -wallet <CA__wallet_directory>

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

      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_directory>
    2. ユーザー・アイデンティティ(ユーザーdn)を作成し、証明書リクエストをエクスポートします。
      $ orapki wallet add -wallet <cluster_wallet_directory> -dn "CN=testuser" -keysize 2048


      $ orapki wallet export -wallet <cluster_wallet_directory> -dn "CN=testuser" -request <cluster_wallet_directory>/testuser.req

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

      $ orapki cert create -wallet <CA__wallet_directory> -request <CA__wallet_directory>/testuser.req -cert <cluster_wallet_directory>/testuser.cer -validity 3650 -sign_alg sha256

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

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

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__wallet_directory>/testCAroot.cer
    2. クライアント・ウォレットの内容を表示します。
      $ orapki wallet display -wallet client_wallet_file_directory

Requested Certificates:
User Certificates:
Trusted Certificates:
Subject:        CN=test CA,O=test,C=c
21.4.1.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
21.4.1.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)
    )
  )
21.4.1.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
21.4.1.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
21.4.1.8 ステップ8: リモート・クライアント構成のテスト

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

  1. クラスタ・ノード上のすべてのリモート・クライアントsqlnet.oraファイルで、ウォレット・ディレクトリを定義します。
    WALLET_LOCATION =
  (SOURCE =
    (METHOD = FILE)
    (METHOD_DATA =
      (DIRECTORY = wallet_file_location)
    )
  )
  2. SSLウォレットおよび証明書の設定中に作成したクライアント・ウォレットを、クライアント・ウォレット・ディレクトリに移動します。ウォレット・ディレクトリには、ewallet.p12ファイルとcwallet.ssoファイルが必要です。

    ウォレットの内容を表示して、ウォレット・ディレクトリが正しく設定されていることを確認します。

    $ orapki wallet display -wallet <wallet_file_location>
  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

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

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

My Oracle Supportから、TLSのクライアントおよびサーバー構成を確認してフィードバックを提供するためのユーティリティを入手できます。「DBSecChk Utility 2.0.0.5 (ドキュメントID 3066006.1)」を参照してください。

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

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

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

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

  • sqlnet.oraファイルに正しいウォレット・ロケーションが指定されていることを確認します。これは、ウォレットを保存したディレクトリと同じにする必要があります。

  • Oracle Netトレースを有効にして、開くことができないファイルの名前とその原因を調べます。

  • orapkiまたはmkstoreを使用してウォレットを保存したときに、自動ログインが有効になっていたことを確認します。mkstoreウォレット管理コマンドライン・ツールは、Oracle Database 23aiでは非推奨であり、将来のリリースで削除される可能性があります。

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

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

処置: orapkiを使用して、ウォレットの自動ログイン機能をオンにします。次に、ウォレットを再度保存します。次に例を示します: 

orapki wallet create -wallet wallet_file_location -auto_login

自動ログイン機能が使用されていない場合は、正しいパスワードを入力します。

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

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

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

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

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

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

  • sqlnet.oraファイルをチェックして、クライアントとサーバーの両方のTLSバージョンが一致しているか、互換性があることを確認します。たとえば、サーバーでTLS 1.3のみを受け入れ、クライアントでTLS 1.2のみを受け入れる場合、TLS接続は失敗します。

  • クライアントおよびサーバーで構成されている暗号スイートをチェックし、両方に互換性のある暗号スイートが設定されていることを確認します。

    それでもエラーが解決されない場合は、トレースを有効にして再度接続を試みてください。Oracleサポートに連絡して、トレース出力を提出してください。

    関連項目:

    クライアントとサーバーに互換性のある暗号スイートを設定する方法の詳細は、「TLSプロトコルおよびTLS暗号スイートの指定」を参照してください

    ノート:

    暗号スイートを構成しない場合は、使用可能なすべての暗号スイートが有効になります。

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のキー使用方法の拡張機能を使用して作成されていません。

処置: 適切なX.509バージョン3のキー使用方法の拡張機能を使用して証明書を作成します。次に例を示します:
orapki wallet add -wallet user_wallet -asym_alg ECC -eccurve p384 -sign_alg ecdsasha384 -dn 'cn=user_ecc,c=us' -pwd welcome1 -addext_ku digitalSignature
digitalSignatureだけでなく、次のように多くのキー使用方法を追加できます:
-addext_ku digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment,keyAgreement,keyCertSign,cRLSign,encipherOnly,decipherOnly
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暗号化の構成

21.6 Transport Layer Securityバージョン1.3への移行および構成

Transport Layer Security (TLS)のバージョン1.3は、以前のバージョンのTLSと比較すると、セキュリティが強化され、TLSハンドシェイクが高速になっています。

TLSバージョン1.3は、データベース・サーバーとクライアントの両方がバージョン23aiの場合、デフォルトで23aiでサポートおよび有効化されています。

使用している環境で構成ファイルにSSL_VERSIONパラメータが指定されていない場合、TLSバージョン1.3はデフォルトで有効になります。SSL_CIPHER_SUITESパラメータが明示的に構成されていない場合、TLS 1.3暗号スイートが自動的に選択されます。この製品は、最も強力なTLSバージョンと、そのバージョンで最も強力かつ使用可能な暗号を選択するように設計されています。

Transport Layer Security (TLS)バージョン1.3の拡張は、次のパラメータのいずれかまたは両方が指定されている場合、現在のTLS構成に影響を与える可能性があります。

  • SSL_VERSION: 構成ファイルからこのパラメータを削除して、サポートされているすべてのTLSバージョンを有効にするか、指定された値に文字列TLSv1.3を含めます
    次に例を示します。
    SSL_VERSION = (TLSv1.3, TLSv1.2)
  • SSL_CIPHER_SUITES: 構成ファイルからこのパラメータを削除して、サポートされているすべてのTLS暗号スイートを有効にするか、TLSバージョン1.3暗号スイートを1つ以上含めます
    次に例を示します。
    SSL_CIPHER_SUITES = (TLS_AES_256_GCM_SHA384, TLS_AES_128_GCM_SHA256, TLS_AES_128_CCM_SHA256)

関連トピック

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