ServiceNow で受信証明書ベースの認証 (相互認証) を構成する方法Summary<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } 「Secure Sockets Layer (SSL) 証明書を交換することによって相互認証で信頼を確立する」を API で有効にする方法 (各ステップを詳しく説明)。 この記事は、正式には証明書ベースの認証 (CBA) として知られている受信相互認証のみを対象としています。送信相互認証については、KB0696002を参照してください。 Release<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Quebec 以降 Instructions<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } 注意：受信 https 接続の証明書ベースの認証 (CBA) は、Quebec 以降でのみサポートされています。 自己署名証明書は、証明書ベースの認証ではサポートされていないことにも注意してください。プラットフォーム自体は自己署名証明書をサポートしていますが、デフォルトではシステムによってブロックされます。 証明書ベースの認証 (CBA) のセットアップ 前提条件： このインスタンスでは、ADCv2 と ServiceNow インスタンスの間で mTLS を有効にする必要があります (「追加情報」セクションを参照)。ADC からアプリへの mTLS を有効にするには、アプリケーションノードのローリング再起動が必要ですが、すべてのノードが同時に再起動されるわけではないため、影響はありません。インスタンスで ADC からアプリへの mTLS が有効になっているかどうかを確認するには、https:///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 形式の公開クライアント証明書であり、通常は統合エンドポイントアドミニストレーターから提供されます。セットアップ全体の概要：証明書ベースの認証のセットアップ Related Links<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } 証明書ベースの認証 (Certificate Based Authentication、CBA) の仕組み CBA が有効で、信頼できる CA 証明書がインスタンスに追加されている場合、その証明書は Application Delivery Controller (ADC) に展開され、そのインスタンスでオプションのクライアントから ADC への mTLS が機能するように構成されます。 つまり、TLS ハンドシェイク中に、ADC が信頼する CA のリストに沿ってクライアント証明書を要求します。これはオプションであるため、クライアント証明書が提示されていなくても、既存の認証メカニズムは引き続き機能します。 有効なクライアント証明書が提示されてその検証が終わると、ADC はクライアント証明書を要求メタデータにエンコードしてアプリケーションサーバーに中継します。アプリケーションサーバーは、クライアント証明書を使用して、さらに検証、認証、および承認を行います。 受信する証明書を ADC で適切に検証し、改ざんが行われないようにするには、ADC から APP への mTLS を実装する必要があります。非 mTLS 認証接続を介してクライアント証明書メタデータを受信した場合、アプリケーションは証明書を受け付けません。