MID サーバー相互認証 - Support and Troubleshooting

MID サーバー相互認証 .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: ; } } 説明 このナレッジベース記事では、MID サーバー相互認証の設定の主な手順について説明します。このナレッジベース記事では、MID サーバーとインスタンス間の相互認証のみに焦点を当てています。

目次 説明 セットアップ トラブルシューティング インスタンスのトラブルシューティング PEM ファイルの分割 エラー Q&A 既知の問題 追加情報 セットアップ インスタンスで証明書ベースの認証をセットアップする手順を確認します。 証明書ベースの認証 CA から証明書を取得する 注: セキュリティチームまたは証明書プロバイダーは、ルート証明書、中間証明書、およびクライアント証明書の作成方法を理解している必要があります。このような証明書を作成するために、ServiceNow またはインスタンスからの情報は必要ありません。 PEM 証明書を 3 つの異なる PEM ファイルに分割します。次のファイルが必要です。 秘密鍵とリーフ証明書 リーフ証明書 中間証明書 + ルート証明書 注: これは、証明書チェーンを表す単一の PEM バンドルファイルである必要があります。詳細については、以下のドキュメントを参照してください。 証明書ベースの認証の設定 TLS/SSL 証明書インストール用の .pem ファイルの作成 インスタンスで、ファイル 3 を CA 証明書チェーンテーブル (sys_ca_certificate) にアップロードします。 インスタンスにアップロードされた CA 証明書レコードの [公開ステータス] が [存在する] に移行するまで待ちます。 注意: 公開ステータスが「存在する」に更新されるまで続行しないでください。 リーフ証明書をsys_user_certificateにのみ添付します。秘密鍵は必要ありません。 MID サーバーがすでに検証されている場合は、続行する前に MID サーバーを無効にしてください。 MID サーバーが実行されている場合は、MID サーバーを停止します MID サーバーで、次の手順に従って秘密鍵 + 証明書を追加します。 MID サーバー相互認証の有効化 MID サーバーを起動します。 トラブルシューティング 注意: 次の手順の一部では、システム管理者が機能を有効にするためにサポートケースが必要な場合があります。

インスタンスが ADCv2 ロードバランサーでセットアップされていることを検証します。 検証するには、コマンド curl -I https:// .service-now.com を実行して、インスタンスに送信された要求の「Server」ヘッダーを確認します。 サーバーヘッダーの値が「snow_adc」の場合、インスタンスは ADCv2 上にあります。 他の値がある場合、インスタンスは ADCv2 上にありません。 インスタンスは ADCv2 ロードバランサーを使用してセットアップされていますか? はい：続行します。 いいえ:ADCv2 ロードバランサーへの移行を要求します。 ロードバランサーが相互認証用にセットアップされていることを検証します。 検証するには、URL にアクセスしてください: /adcv2/supports_tls mixed または true が返される場合、インスタンスはインバウンド TLS をサポートします。 ページが見つからないかリダイレクトされた場合、インスタンスはインバウンド TLS をサポートしていません。 ロードバランサーは相互認証用にセットアップされていますか? はい：続行します。 いいえ:相互認証用にロードバランサーを構成するように要求します。 相互認証プラグインが有効であることを検証する。 移動先： https:// .service-now.com/$allappsmgmt.do?sysparm_redirect=true&sysparm_search=com.glide.auth.mutual プラグインが「インストール済み」であることを確認する。 相互認証プラグインは有効になっていますか? はい：続行します。 いいえ:プラグインを有効にするか、プラグインのアクティベーションを要求します。 sys_ca_certificateまたはsys_user_certificateをセットアップするためのドキュメントに従ってエラーはありますか? はい:証明書はサポートされている形式ですか?(PEM) はい:続行します。 いいえ:証明書ベンダーの指示に従って、証明書を PEM 形式に変換します。 いいえ：続行します。 sys_ca_certificateとsys_user_certificateはアクティブですか? はい：続行します。 いいえ:フィールドをアクティブ = true に設定します。 相互認証用の MID サーバーのセットアップに関するドキュメントに従ってエラーが発生していますか? はい:エラーを解決します。 いいえ：続行します。 MID サーバーのセットアップ SSL デバッグ MID サーバー SSL デバッグの設定 必要に応じて、インスタンスでデバッグパラメーターをセットアップします。 (この KB の「インスタンスのトラブルシューティング」セクションを参照) 問題を再現します。 MID サーバーラッパーファイルにハンドシェイクエラーがないか確認し、次のリンクでハンドシェイクの手順を確認してください。 クライアント認証 TLS ハンドシェイク インスタンスのトラブルシューティング 注意: 問題を回避するため、テクニカルサポートに相談せずに次のプロパティ/スクリプトを変更しないでください。

サポートでは、次のプロパティを true に設定する必要がある場合があります。

glide.auth.debug.enabled glide.auth.ssl.debug.enabled サポートでは、スクリプトインクルード MutualAuth (sys_script_include.do?sys_id=94d0d81373211010978acff8faf6a7c9) を次のように更新する必要がある場合もあります。

getAuthorized : function() { var request = GlideTransaction.get().getRequest(); var certHeader = request.getHeader("X-Client-Cert"); gs.log("MutualAuth certHeader===>" + certHeader); ... ... } PEM ファイルの分割 PEM ファイルは、次のような BEGIN / END ブロック内のキー/証明書の集まりにすぎません。

-----BEGIN ENCRYPTED PRIVATE KEY----- -----END ENCRYPTED PRIVATE KEY----- 目的のキー/証明書を抽出して、新しいファイルに保存できます。

エラー ServiceNow インスタンスでユーザー「null」を認証できませんでした。 MID サーバーは、最初の起動時にテストを実行します。テストの 1 つは、MID サーバーからインスタンスへの接続と、MID サーバーユーザーの権限をチェックします。このエラーは、テストが失敗した場合に返されます。ユーザーは、config.xmlファイルで設定されているものである必要があります。MID サーバーで相互認証を設定すると mid.instance.username パラメーターが削除されるため、エラーはユーザー「null」を返します。このエラーは通常、相互認証の失敗の副作用です。

Quebec ユーザーのクライアント証明書 UI アクション「ストア/証明書の検証」エラー「無効なclient_cert:証明書をロードできません、pem」 UI アクションは、ユーザークライアント証明書に対して入力されていないフィールド pem_certificate チェックするため、エラーが発生します。この UI アクションは CA 証明書専用です。新しいリリースでは、この UI アクションがユーザークライアント証明書から削除されました。

クライアント証明書チェーンの検証に失敗しました/証明書チェーンの検証が不完全なため、証明書チェーンの検証に失敗しました。 sys_ca_certificateレコードの「アクティブ」フィールドが false に設定されている。 中間証明書またはルート証明書が sys_ca_certificate にアップロードされていません。 ユーザークライアント証明書 (sys_user_certificate) の追加が「CA からの証明書を検証できません (Unable to validate the certificate from CA)」というエラーで失敗する。 証明書チェーンがsys_ca_certificateに追加されましたか? はい：続行します。 いいえ:証明書チェーンをsys_ca_certificateに追加します。 証明書チェーンが ADCv2 ロードバランサーに公開されたかどうかを確認します。 [公開ステータス] 列をsys_ca_certificateに追加します。 「公開ステータス」は「存在する」に設定されていますか? はい:PEM ファイルをレビューして、必要な証明書がすべて存在することを確認します。 いいえ:ステータスが「存在する」に変わるまで待ちます。 注:チェーンをsys_ca_certificateに追加してから数分かかります。 MID サーバーラッパーログに「証明書」が またはクライアント認証用の X.509 証明書なしと表示されます。 OOB ではなく *.service-now.com の MID セキュリティポリシー 注意: これが根本原因である場合、MID サーバーは最初にインスタンスに正常に接続します。ただし、MID セキュリティポリシーがインスタンスから取得されると、認証できなくなります。

MID サーバーの相互認証を機能させるには、次の MID セキュリティポリシーに OOB 値を設定する必要があります。

https://.service-now.com/nav_to.do?uri=mid_cert_check_policy.do?sys_id=f30ab21a5b311010eff60e281d81c78c ソリューション：

MID サーバーを停止します。 ポリシーを OOB に戻すか、次のオプションを true に設定します。 証明書チェーンチェック ホスト名チェック 失効チェック MID サーバーの config.xml で次のパラメーターを true に更新します。 MID サーバーを起動します。 証明書チェーンが不完全 相互認証プロセスの一環として、MID サーバーはインスタンスから証明書のリスト (sys_ca_certificate にアップロードされたルート証明書と中間証明書) を受け取ります。MID サーバーは、インスタンスから取得されたいずれかの証明書によって署名されている場合、クライアント証明書を使用します。MID サーバーラッパーログから抽出された次の例では、ラボ環境で返された証明書のリストが表示されます。

| "CertificateRequest": { | "certificate types": [...] | "supported signature algorithms": [...] | "certificate authorities": [CN=CS Automation Lab Certificate Authority Intermediate, OU=CS Automation Lab Certificate Authority, O=CS Automation Lab, ST=Florida, C=US, CN=CS Automation Lab Certificate Authority Root, OU=CS Automation Lab Certificate Authority, O=CS Automation Lab, L=Orlando, ST=Florida, C=US, ... ] | } | ) 上記の例では、中間証明書とルート証明書の両方が MID サーバーによって受信されていることがわかります。この例では、認証は正常に完了しています。ただし、MID サーバーが受信した証明書チェーンが空または不完全な場合、MID サーバーは空のクライアント証明書を返します。

ソリューション：

sys_ca_certificateに移動します。 必要な証明書がすべてアップロードされ、公開ステータス = 「存在する」であることを確認してください。 MID サーバーへのクライアント証明書の追加に失敗しました 問題を解決するには、次を実行します。

MID サーバーを停止します。 .\agent\security\agent_keystore を別のディレクトリにバックアップします。 MID サーバーを再起動して新しいagent_keystoreを生成します。 MID サーバーを停止します。 クライアント証明書と秘密鍵を MID サーバーに追加する手順に従います。 相互認証の有効化します。 MID サーバーを起動します。 MID サーバーに追加された証明書はクライアント証明書ではありません。 次のコマンドを実行すると、証明書タイプを確認できます。

openssl x509 -in certificatePath.cert.pem -text -noout 次の例では、クライアント証明書の拡張キー使用率を示しています。

X509v3 Extended Key Usage:

TLS Web Client Authentication, E-mail Protection 次の例では、サーバー証明書の拡張キー使用率がわかります。

X509v3 Extended Key Usage:

TLS Web Server Authentication 注: [拡張キー使用法] に「TLS Web クライアント認証」が含まれている場合、証明書は問題ありません。

ソリューション：

証明書プロバイダーにクライアント証明書と秘密鍵を要求する。 MID サーバーを停止します。 クライアント証明書と秘密鍵を MID サーバーに追加する手順に従います。 相互認証の有効化します。 MID サーバーを起動します。 Q&A 自己署名証明書はサポートされていますか? いいえ。自己署名証明書は、現時点ではサポートされていません。

相互認証を使用している MID サーバーを無効にできますか? いいえ

相互認証を使用して MID サーバーをリキーできますか? いいえ

MID サーバーが相互認証を使用していることをどうやって確認しますか? MID サーバーのフィールド [相互認証を使用していますか?(Is using mutual authentication?)] を確認してください。

sys_user_certificate の下に添付ファイルがなく、フィールド pem_certificate が空であるのはなぜですか? 証明書が sha256 フィンガープリントに変換され、添付ファイルが削除されます。これが想定される動作です。

相互認証を有効にすると、すべての MID サーバーで相互認証を使用する必要がありますか? いいえ。引き続きベーシック認証を使用して MID サーバーを使用できます。

証明書チェーンが有効であることを確認するにはどうすればよいですか? OpenSSL 検証コマンドを使用して、証明書チェーンが有効であることを確認します。コマンド例:

openssl verify -CAfile rootCert.pem \ -untrusted intermediateCert.pem \ clientCert.pem または、発行者ハッシュを使用して、チェーンが有効であることを確認することもできます。コマンド例:

openssl x509 -hash -issuer_hash -noout -in .pem 上記では、MID サーバーに追加されたリーフ証明書のハッシュを確認します。このようにして、チェーンを確認できます。

次の例では、テスト環境のハッシュを示しています。

openssl x509 -hash -issuer_hash -noout -in UserExampleCert.pem 70f02020 20403030

openssl x509 -hash -issuer_hash -noout -in IntermediateCert.pem 20403030 20d05000

openssl x509 -hash -issuer_hash -noout -in RootCert.pem 20d05000 20d05000 上記では、 70f02020 >>> 20403030 >>> 20d05000 のチェーンが表示されていることに注意してください

既知の問題 (PRB1556363) - 無効で誤解を招くエラーメッセージ:「MID サーバー暗号化キーが一致せず、無効になっています。mTLS が有効な MID サーバーの場合は、適切な機能を復元するには、MID サーバーを無効にしてから再検証してください 追加情報 ServiceNow で受信証明書ベースの認証 (相互認証) を構成する方法