ServiceNow で受信証明書ベースの認証 (相互認証) を構成する方法Description「Secure Sockets Layer (SSL) 証明書を交換することによって相互認証で信頼を確立する」を API で有効にする方法 (各ステップを詳しく説明)。 この記事は、証明書ベースの認証 (Certificate-Based Authentication、CBA) と公式に呼ばれる受信相互認証のみを対象としています。送信相互認証については、KB0696002 を参照してください。 Release or EnvironmentQuebec 以降Instructions注意：受信 https 接続の証明書ベースの認証 (CBA) は、Quebec 以降でのみサポートされています。 自己署名証明書は、証明書ベースの認証ではサポートされていないことにも注意してください。プラットフォーム自体は自己署名証明書をサポートしていますが、デフォルトではシステムによってブロックされます。 証明書ベースの認証 (CBA) のセットアップ 前提条件： ADCv2 上にインスタンスが存在する必要があります。証明書ベースの認証のセットアップと、そこからたどれる KB0952875 を参照してください。インスタンスが ADCv2 対応であれば、コマンドライン curl -I https://<instance>.service-now.com を実行すると、server: snow_adc と表示されるはずです。 このインスタンスでは、ADCv2 と ServiceNow インスタンスの間で mTLS を有効にする必要があります (「追加情報」セクションを参照)。ADC からアプリへの mTLS を有効にするには、アプリケーションノードのローリング再起動が必要ですが、すべてのノードが同時に再起動されるわけではないため、影響はありません。インスタンスで ADC からアプリへの mTLS が有効になっているかどうかを確認するには、 https://<instance_fqdn>/adcv2/supports_tls にアクセスします。 戻り値が「true」であれば、インスタンスは ADCv2-to-APP mTLS 用に構成されています。false が返された場合は、サポートエンジニアに連絡して、インスタンスで ADC から APP への mTLS を有効にするように依頼してください。インスタンスで Now Platform の証明書ベースの認証プラグイン (com.glide.auth.mutual) を有効にする必要があります。 ServiceNow と統合するサードパーティエンドポイントの所有者/アドミニストレーターは、クライアント PKI キーペアを提供する必要があります。そこに、jks ファイルや pkcs12 ファイルなどのクライアント証明書のほか、このクライアント証明書のすべての中間 CA 証明書とルート CA 証明書 (DER エンコード PEM 形式の x.509 証明書) を含めます。これらの証明書は、(ServiceNow ではなく) 「他の」エンドポイントが送信する 2 つの Web サービスエンドポイント間の SSL ハンドシェイクに使用されます。 PEM 形式の証明書はすべて -----BEGIN CERTIFICATE----- と END CERTIFICATE----- で囲む必要があることに注意してください。ユーザーにマッピングされるクライアント証明書は、ServiceNow と通信しているサードパーティエンドポイントの非公開証明書と一致する公開証明書である必要があります。 考慮事項： インスタンスで CBA を有効にするとリスクが生じるため、まず準本番環境でテストする必要があります。ServiceNow が 2021 年初頭に初めて CBA 機能のロールアウトを開始した当初のアプローチは、デフォルトですべてのインスタンスに対してオプションのクライアントから ADC への mTLS を有効にし、TLS ハンドシェイク中は信頼できる証明書バンドルで独自の内部 PKI CA のみをアドバタイズするというものでした。 お客様は、CBA を有効にして CA 証明書をインスタンスにアップロードすることで、このバンドルに追加できました。 その目的は、お客様のクライアントには ServiceNow CA からクライアント証明書が発行されないため、お客様の CA 証明書がアップロードされるまではクライアント証明書を受け取らないようにすることです。 ただし、サーバーから提示された信頼できる CA を無視して、自身のクライアント証明書をなんとか送信しようとするクライアントもあります。 その結果、ADC で証明書検証エラーが発生して、HTTP 400 エラーとなることがあります。 アップロードする証明書は、PEM 形式である必要があります。mTLSを有効にするには、ノードの再起動が必要です。すべてのノードが同時に再起動されるわけではないため、通常は大きな影響はないと想定されます。しかし、予期せぬ事態に備え、アップデート中はアクセスを制限する時間を設けることをお勧めします。 手順： 証明書ベースの認証のアクティブ化、証明書ベースの認証のセットアップ CA 証明書の登録 さらに次の手順を実行：証明書ベースの認証のセットアップ 重要： 最初に SSL ハンドシェイクのクライアント証明書のルート CA 証明書をインポートし、次にルート証明書から下位レベルの証明書へ順に中間 CA 証明書をインポートします証明書は、PEM 形式である必要があります。他の形式は、ADCv2 にインストールできません PEM 証明書をユーザーにマッピング：この手順では、ロールと ACL に従ってデータへのアクセスを可能にする相互認証の統合ユーザーを、https プロトコルの SSL ハンドシェイクの一部として ADCv2 に送信されるクライアント証明書にリンクします。ここでロードする PEM 証明書は、PEM 形式の公開クライアント証明書であり、通常は統合エンドポイントアドミニストレーターから提供されます。セットアップ全体の概要：証明書ベースの認証のセットアップ Additional Information証明書ベースの認証 (Certificate Based Authentication、CBA) の仕組み CBA が有効で、信頼できる CA 証明書がインスタンスに追加されている場合、その証明書は Application Delivery Controller (ADC) に展開され、そのインスタンスでオプションのクライアントから ADC への mTLS が機能するように構成されます。 つまり、TLS ハンドシェイク中に、ADC が信頼する CA のリストに沿ってクライアント証明書を要求します。これはオプションであるため、クライアント証明書が提示されていなくても、既存の認証メカニズムは引き続き機能します。 有効なクライアント証明書が提示されてその検証が終わると、ADC はクライアント証明書を要求メタデータにエンコードしてアプリケーションサーバーに中継します。アプリケーションサーバーは、クライアント証明書を使用して、さらに検証、認証、および承認を行います。 受信する証明書を ADC で適切に検証し、改ざんが行われないようにするには、ADC から APP への mTLS を実装する必要があります。非 mTLS 認証接続を介してクライアント証明書メタデータを受信した場合、アプリケーションは証明書を受け付けません。