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

MID サーバー相互認証 Description (説明) このナレッジベースの記事では、MID サーバー相互認証の設定に関連する主な手順について説明します。このナレッジベース記事では、MID サーバーとインスタンス間の相互認証のみに焦点を当てています。

目次 説明 セットアップ ファイル トラブルシューティング インスタンスのトラブルシューティング PEM ファイルの分割 エラー Q&A 追加情報 セットアップ インスタンスで証明書ベースの認証をセットアップする手順を確認します 証明書ベースの認証 CA から証明書を取得する 注: セキュリティチームまたは証明書プロバイダーは、ルート証明書、中間証明書、およびクライアント証明書の作成方法に精通している必要があります。このような証明書を作成するために、ServiceNow またはインスタンスからの情報は必要ありません。 PEM 証明書を 3 つの異なる PEM ファイルに分割します。次のファイルがあるはずです。 秘密鍵とリーフ証明書 リーフ証明書 中間証明書 + ルート証明書 インスタンスで、ファイル 3 を CA 証明書チェーンテーブル (sys_ca_certificate) にアップロードします 注 : バンドルではなく個別にアップロードする場合は、ルート証明書から始めて、中間証明書から始めます 複数のファイルに分割するのではなく、ファイル 3 を PEM バンドル (この場合はタイプを "CA Cert" に設定) としてアップロードすることをお勧めします インスタンスにアップロードされた 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 をサポートしません ロードバランサーは相互認証用にセットアップされていますか? はい：続行します いいえ:要求ロードバランサーを相互認証用に構成します 相互認証プラグインが有効になっていることを検証します 移動先： .service-now.com/$allappsmgmt.do?sysparm_redirect=true&sysparm_search=com.glide.auth.mutual">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 からの証明書を検証できません」というエラーで失敗する 証明書チェーンは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 サーバーフィールドの [相互認証を使用していますか?] を確認します。

[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 で受信証明書ベースの認証 (相互認証) を構成する方法