相互認証の構成

  • リリースバージョン: Zurich
  • 更新日 2025年07月31日
  • 所要時間：4分

    • 相互認証では、SSL (Secure Sockets Layer) 証明書を交換することによって信頼を確立します。

    SSL ハンドシェイク中に、サーバーはクライアントに証明書を提示します。その後、サーバーの構成によっては、クライアントからの証明書をサーバーが要求する場合があります。サーバーとクライアントの両方が証明書の検証手順を実行して、提示された証明書の信頼性と整合性を確保します。

    検証が成功した後、HTTPS 接続を開始する前に確認応答が交換されます。

    注:
    カスタム HTTPS プロトコルプロファイルを使用して相互認証を有効にする方法については、「 Create a protocol profile」を参照してください。

    アドミニストレーターは、認定要求を実行する前に、クライアントキーストアを設定して証明書を生成する予備作業を行います。

    警告:
    この機能で相互認証が可能になるのは、送信 HTTPS 接続だけです。

    キーストアの作成

    インスタンスは現在、秘密鍵と公開証明書のペアを含む Java キーストアファイルのアップロードをサポートしています。公開証明書にはルート証明書を含む完全なチェーンが含まれています。

    クライアントキーストアを設定するには、

    • 信頼できる認証局 (CA) によって署名された証明書が必要です。
    • API エンドポイントプロバイダーがキーストアの生成を支援する場合があります。

    キーストアを生成する必要がある場合、このプロセスには、コマンドラインインターフェイスコマンドを使用して新しいキーストアファイルを生成し、証明書署名要求 (CSR) を作成して、署名済み証明書をインポートするいくつかの手順が含まれます。ルート証明書や中間証明書はいずれも、ドメインのプライマリ証明書をインポートする前にインポートする必要があります。ステップバイステップの手順は次のとおりです。

    1. Java キーストアとキーペアを生成します。
      keytool -genkey -alias mydomain -keyalg RSA -keystore my.keystore
    2. 既存の Java キーストアの CSR を生成します。
      keytool -certreq -alias mydomain -keystore my.keystore -file mydomain.csr
    3. CSR を CA 署名機関に送信します。CA 署名機関は証明書ファイルに署名し、署名済み証明書とともに中間証明書とルート証明書を含む証明書ファイルを返します。
    4. ルートまたは中間認証局 CA 証明書を既存の Java キーストアにインポートします。
      keytool -import -trustcacerts -alias root -file Thawte.crt -keystore my.keystore
      注:
      すべての証明書を 1 つのファイルにバンドルしてインポートできます。これが推奨されるオプションです。このようにすると、手順 5 をスキップできます。
      keytool -import -alias mydomain -file merged.crt -keystore my.keystore
    5. 署名済みプライマリ証明書を既存の Java キーストアにインポートします。
      keytool -import -trustcacerts -alias mydomain -file mydomain.crt -keystore my.keystore

    キーストアの設定

    キーストアが作成されたので、証明書テーブルにアップロードできます。対象： システム定義 > 証明書 ページで、[ 新規 ] をクリックして次のフィールドを設定します。
    • 証明書の名前を入力します。
    • キーストアをアクティブとして格納します。
    • タイプを [Java キーストア] に設定します。
    • キーストアパスワードを入力します。これは、キーストアの作成に使用されたパスワードです。
    [送信] をクリックして Java キーストアエントリを作成します。
    図 : 1. キーストア

    信頼できるサーバー証明書の指定

    送信 SSL 接続 (HTTPS Web サービス呼び出し) では、サービスプロバイダーによって提供される証明書を指定して、SSL 接続中のサービスプロバイダーの妥当性を保証することができます。たとえば、証明書で識別される安全なサービスにブラウザが接続しようとしている場合などです。

    信頼できるサーバー証明書をアップロードすることで、ServiceNow により、接続しているサービスの妥当性と安全性を確保できます。

    「信頼ストア証明書」タイプで新しい証明書エントリを作成し、DER 形式の証明書を添付するか、その PEM 形式をコピーして [PEM 証明書] フィールドに貼り付けます。

    プロトコルプロファイル

    図 : 2. 証明書の交換
    • クライアントが認証のためにサーバー証明書を要求すると、証明書署名要求 (CSR) が生成されます。
    • CSR に応答するために、サーバーは 2 つの一意の暗号化キー：サーバーへのメッセージを暗号化するために使用される公開鍵とメッセージを復号化するために使用される秘密鍵を生成します。両方のキーがキーストアに保持されます。
    • キーを使用して、クライアントの安全なメッセージを復号化し、サーバーで読み取りができるようにします。HTTPS になるすべての送信接続は、キーストアを確認してその公開認定を提供することで、認定を検証し、トラストストア証明書を使用して相互の信頼性を検証します。
    • クライアントとサーバーとの間で安全なリンクを確立するために、サーバーは証明書を対応する秘密鍵と照合します。サーバーのみが秘密鍵にアクセスできるため、サーバーはクライアントからのデータを復号化できます。
    注:
    カスタム HTTPS プロトコルプロファイルを使用して相互認証を有効にする方法については、「 Create a protocol profile」を参照してください。

    サーバーは証明書を送信して応答します。これがクライアントが受け入れる証明書ですか？そうである場合、証明書を受け入れるメッセージがサーバーに送信され、安全なチャネルが開始されます。証明書が承認されない場合は、認定にルート権限が必要であることを意味します。