実装ガイド:証明書ベースの認証の設定方法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: ; } } 必須条件： 1.インスタンスは ADCv2 上にある必要があります。以下のコマンドを実行し、応答に「Server:snow_adc」が含まれているかどうかを確認します。 curl -I https://<Instancename>.service-now.com 2. mTLS はインスタンスレベルで有効にする必要があります。以下の URL は「true」を返す必要があります https://<instancename>.service-now.com/adc/supports_tls 3.証明書ベースの認証プラグイン (com.glide.auth.mutual) をインスタンスでアクティブ化する必要があります。 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: ; } } すべてのリリース 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: ; } } ServiceNow で証明書ベースの認証を設定するために従う必要がある手順は次のとおりです。 回答：証明書の作成 セットアップ時に、ServiceNow と統合するサードパーティアプリチームがこれらの必要な証明書を提供するのが理想的です。以下のコマンドは、情報提供のみを目的として共有しています。コマンドの実行中に問題が発生した場合は、社内チームと協力してサポートを求めてください。 ステップ 1.keytool genkeypair コマンドを使用してキーストア (証明書のペア) を作成します。次のコマンドは、公開鍵と秘密鍵を持つキーストアを作成します。 keytool -genkeypair -alias letstestcba -keyalg RSA -keysize 2048 -validity 365 -keypass ServiceNow123 -keystore letstestcba.jks -storepass ServiceNow123 ステップ 2.キーストアが作成されたら、CSR を生成し、外部 CA に署名してもらう必要があります。 keytool -certreq -alias letstestcba -file mycsr.pem -keystore letstestcba.jks ステップ 3.証明書署名要求 (CSR) を作成して認証局 (CA) に送信すると、通常、次の証明書を受け取ります サーバー証明書中間証明書ルート証明書 ステップ 4.キーストアを設定するには、証明書をキーストアにアップロードし直す必要があります。次のコマンドを使用して、受信した証明書をキーストアにアップロードし直します。 ルート証明書をインポートします。 keytool -import -trustcacerts -alias root -file root.pem -keystore letstestcba.jks -storepass ServiceNow123 中間証明書をインポートします。 keytool -import -trustcacerts -alias intermediate -file intermediate.pem -keystore letstestcba.jks -storepass ServiceNow123 注:複数の中間証明書がある場合は、それぞれに対してこの手順を繰り返し、それぞれに一意のエイリアス(intermediate1、intermediate2 など)を付与します。 署名済みサーバー証明書をインポートします。 keytool -importcert -alias letstestcba -file SignedServerCert.pem -keystore letstestcba.jks -storepass ServiceNow123 注:上記のインポートコマンド(署名付きサーバ証明書のインポート)で使用したエイリアスが、最初にキーストアを作成し、CSRを生成したときに使用したエイリアス(ステップ1およびステップ2で使用したエイリアス)と一致していることを確認してください。これにより、サーバー証明書がキーストア内の対応する秘密鍵にバインドされます。 「ServiceNow123」は、上記のコマンドで使用されるサンプルパスワードであることに注意してください。これらのコマンドを使用する場合は、ご自身のパスワードを使用してください。 これでキーストアを使用する準備が整いました。このキーストアをサードパーティアプリにアップロードすると、双方向 SSL を使用して ServiceNow への発信呼び出しを行うことができます。 ステップ 5.テスト目的でこの統合に自己署名証明書を使用するには、ステップ 1 の直後に次のコマンドを実行してキーストアから公開証明書をエクスポートします (ステップ 2、3、4 で説明したコマンドを実行する必要はありません)。 自己署名証明書の使用は推奨されないことに注意してください。CA 署名付き証明書を使用することを常にお勧めします。自己署名証明書は、テスト目的でのみ使用できます。ただし、提供される信頼と検証が欠如しているため、本番環境での使用には適していません。 CA 署名付き証明書を使用すると、より高いレベルのセキュリティ、信頼性、およびコンプライアンスが確保されます。 keytool -exportcert -alias letstestcba -file ServerCert.pem -keystore letstestcba.jks -storepass ServiceNow123 -rfc openssl x509 -inform der -in ServerCert.pem -out ServerCertNew.pem B.CA 証明書チェーンをアップロード > [証明書ベースの認証 - CA 証明書チェーン> (Certificate Based Authentication - CA Certificate Chain)] に移動します > [新規] をクリックします > 名前を設定します。 > タイプが [CA 証明書] であることを確認します。 > ルート証明書を添付します。 > [送信] をクリックします。 > 中間証明書についても同じ手順を繰り返します。中間証明書をアップロードするときに、中間証明書がロードバランサーにも同期されるように、タイプを「CA 証明書」に設定します。 注:ルート証明書と中間証明書の両方を単一の証明書としてアップロードし、タイプを CA 証明書として選択することもできます。 > タイプが「CA 証明書」に設定された証明書をアップロードするとすぐに、証明書を ServiceNow ロードバランサーに同期するのに時間がかかります。証明書がロードバランサーにアップロードされると、公開ステータスはアクティブに設定されます。 > テスト目的でアップロードしたサンプル証明書を以下に示します。 C.サーバー証明書をアップロードし、ユーザーにマッピングします。 > [証明書ベースの認証 - ユーザーから証明書へのマッピング> (Certificate Based Authentication - User to Certificates Mapping)] に移動します > [新規] をクリックします > 名前を設定します。 > ユーザーの選択 > 灰色のヘッダーの [添付ファイルを管理] をクリックし、サーバー証明書をアップロードします。 > [送信] をクリックします。 > テスト目的でアップロードしたサンプル証明書を以下に示します。 D.証明書ベースの認証を有効にする > [証明書ベースの認証 - >プロパティ] に移動します > 「証明書ベースの認証」を有効にする > [保存] をクリックします これで、証明書ベースの認証のセットアップの準備ができました。以下の CURL コマンドを使用してテストできます。 E.CURL コマンドを使用してテストします。 > これをcurlからテストするには、キーストアの秘密鍵が必要です。keytool は主にキーストア内の証明書とキーを管理するために設計されており、セキュリティ上の理由から秘密キーを直接エクスポートするオプションを提供していないため、keytool を使用したキーストアからの秘密キーの直接エクスポートはサポートされていません。ただし、次の手順に従って、openssl ツールと keytool を使用してこれを実現できます。 ステップ1: まず、keytool を使用して Java KeyStore (JKS) を PKCS12 形式に変換します。PKCS12 形式は OpenSSL と互換性があります。 keytool -importkeystore -srckeystore letstestcba.jks -destkeystore letstestcba.p12 -deststoretype PKCS12 -srcalias letstestcba -deststorepass ServiceNow123 -srcstorepass ServiceNow123 ステップ 2:openssl を使用して、PKCS12 キーストアから秘密鍵を抽出します。 openssl pkcs12 -in letstestcba.p12 -nocerts -nodes -out private_key.pem -passin pass:ServiceNow123 > 以下の CURL コマンドを使用して、証明書ベースの認証セットアップをテストできます。テスト中にキャプチャされたスクリーンショットをご覧ください。 curl -v -k -GET --key private_key.pem --cert ServerCert.pem "https://<Instancename>.service-now.com/api/now/table/incident?sysparm_limit=1" 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: ; } } これは、ServiceNow がサーバーとして機能し、ServiceNow への API 呼び出しを開始するサードパーティアプリがクライアントである ServiceNow への受信シナリオです。 SSL ハンドシェイクでの相互認証中に、サーバー (つまり ServiceNow) は、セクション B (CA 証明書チェーンのアップロード) で ServiceNow ロードバランサーにアップロードされた識別名 (DN) のリストを含む「証明書要求」メッセージを送信します。 このメッセージを受信すると、クライアントアプリケーション (サードパーティアプリケーション) は「証明書」メッセージで応答します。このメッセージには、セクション C (サーバー証明書をアップロードしてユーザーとマッピングする) でユーザーにマップされたクライアント証明書が含まれています。 「証明書」メッセージを受信すると、ServiceNow ロードバランサーはそれをトラストストアと照合して検証し、さらなる通信を許可し、さらに処理するために要求をアプリケーションノードに転送します。以下は 2 方向 SSL ハンドシェイクの図です。 セットアップの詳細とその仕組みについては、以下の記事を参照してください。 https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0993615 https://docs.servicenow.com/bundle/washingtondc-platform-security/page/integrate/authentication/task/set-up-mutual-auth.html