MID サーバーの SSL に関する問題のトラブルシューティング - Support and Troubleshooting

MID サーバーの SSL に関する問題のトラブルシューティング Issue このドキュメントでは、MID サーバーで作成された HTTPS 接続のトラブルシューティングを行う際のプロパティと実行する手順について説明します。

目次 セキュリティチェック ブートストラップパラメーター 一般的なエラー トラブルシューティング SSL デバッグの設定 トラブルシューティングの例 証明書チェーンエラー OCSP エラー セキュリティチェック MID サーバーは、ターゲットへの接続を暗号化する前にセキュリティチェックを実行します。MID サーバーは次のチェックを実行します。

ホスト名チェック ホスト名の検証は、クライアントが正しいサーバーと通信していることを確認するためのサーバー ID チェックを含む HTTPS の一部です。このチェックは、中間者攻撃によってリダイレクトされた後にサーバーに情報を送信することを防ぎます。このチェックでは、サーバーから送信された証明書の dnsName が、要求の実行に使用された URL と一致することを確認します。 失効チェック OCSP レスポンダ (通常は証明書発行者によって実行されるサーバー) は、証明書が「良好」、「失効」、または「不明」であるという署名付き応答を返します。要求を処理できない場合は、エラーコードが返されることがあります。 証明書チェーンチェック 証明書チェーン内の証明書が MID サーバーの cacerts にあるかどうか。 ターゲットアドレスに対して実行するチェックの構成は、テーブル [mid_cert_check_policy] で確認できます。MID サーバー証明書チェックポリシーの詳細については、以下を参照してください。

MID サーバー証明書チェックポリシー MID サーバーと証明書の詳細については、以下を参照してください。

MID サーバーと証明書 MID サーバー TLS/SSL 証明書チェックポリシー Quebec アップグレード情報 MID サーバーの OCSP 要件の詳細 MID サーバーが自己署名証明書による証明書チェーンのエラーを表示する ブートストラップパラメーター 明示的に設定されていない限り、MID サーバーは起動時に次のパラメーターを次のデフォルト値でロードします。

上記のパラメーターは、MID サーバーとインスタンス間の初期接続用です。MID サーバーがインスタンスに接続すると、MID サーバーは mid_cert_check_policy で構成されているチェックを実行します。インスタンスへの接続時の証明書エラーが原因で MID サーバーがダウンした場合、上記のブートストラップパラメーターを調整できます。セルフホストインスタンス、または「.service-now.com」で終わらない URL に接続する MID サーバーの場合、ターゲット URL と一致するように target_endpoint を更新する必要があります。

注意： mid.security.validation.endpoints と com.glide.communications.httpclient.verify_revoked_certificate は、Orlando と Paris で使用されます。Quebec 以降では、この mid_cert_check_policy を最大限に活用しています。

一般的なエラー PKIX パスの構築に失敗しました 証明書チェーンが見つかりません 証明書パスに証明書の発行者証明書が見つかりません ピアが認証されていません certificate_unknown セッションに証明書が含まれていません - 信頼できません OCSP 取り消しチェック 証明書がアルゴリズムの制約に準拠していません 証明書失効の検証に失敗しました OCSP 証明書失効チェックが処理されませんでした インスタンスから証明書ポリシーが返されませんでした 注意： 証明書の問題をトラブルシューティングするときに「インスタンスから証明書ポリシーが返されませんでした」というエラーが表示された場合、このエラーは、以下に示すファイルがカスタマイズされている可能性があることを示しています。このファイルがカスタマイズされている場合は、OOB に戻してください。

sys_web_service.do?sys_id=9d5754c5ff7200006857361332f49d5c トラブルシューティング SSL デバッグの設定： MID サーバーを停止します。 ファイル \agent\conf\wrapper-override.conf を開きます。 いずれかのパラメーターを追加します。 -Djavax.net.debug=ssl,handshake -Djavax.net.debug=all (きめ細かく非常に詳細) たとえば、次のようになります。 wrapper.java.additional.3=-Djavax.net.debug=ssl,handshake ファイル \agent\config.xml を開き、次のパラメーターを追加します。 MID サーバーを起動します。 問題を再現します。 ファイルを確認します。 agent\log\wrapper log 注意： Quebec 以降では、パラメーター mid.log.level = debug を指定するとセキュリティポリシーのデバッグメッセージも追加されます。たとえば、次のようになります。

08/23/21 13:46:49 (168) ECCQueueMonitor.1 DEBUG: MIDSecPolicy: calculating security Policy to be applied on instance.service-now.com 08/23/21 13:46:49 (168) ECCQueueMonitor.1 DEBUG: MIDSecPolicy: returning a security policy from the fast cache! 08/23/21 13:46:49 (168) ECCQueueMonitor.1 DEBUG: MIDSecPolicy: hostname verification for host[instance.service-now.com] is true 08/23/21 13:46:49 (168) ECCQueueMonitor.1 DEBUG: MIDSecPolicy: calculating security Policy to be applied on instance.service-now.com 08/23/21 13:46:49 (168) ECCQueueMonitor.1 DEBUG: MIDSecPolicy: returning a security policy from the fast cache! 08/23/21 13:46:49 (168) ECCQueueMonitor.1 DEBUG: MIDSecPolicy: Certificate revocation check for host[instance.service-now.com] is true 08/23/21 13:46:49 (168) ECCQueueMonitor.1 DEBUG: Server certificate chain: 追加のプロパティ glide http ログもオンにすると、http 呼び出しがデバッグされますが、SSL の問題では必要ない場合があります。

MID サーバーを停止します。 \agent\properties\glide.properties を開きます。 プロパティを追加します。 glide.http.log_debug=true MID サーバーを起動します。 または

MID サーバーを停止します。 agent\config.xml を開きます。 パラメーター glide.http.log_debug を追加します。 MID サーバーを起動します。 トラブルシューティングの例 証明書チェーンエラー トラブルシューティングの手順：

デバッグレベルを設定します。 不足している証明書を特定します。 不足している証明書を MID サーバーにインポートします。 SSL デバッグを有効にして、問題を再現します。エージェントログに次のエラーが表示されます。

08/23/21 06:50:40 (816) StartupSequencer SEVERE *** ERROR *** Request not sent to uri= https://instancename.service-now.com/InstanceInfo.do?SOAP : javax.net.ssl.SSLHandshakeException: PKIX path building failed: java.security.cert.CertPathBuilderException: No issuer certificate for certificate in certification path found. ラッパーログには、次のように表示されます。

クライアント Hello Produced ClientHello handshake message ( "ClientHello": { サーバー Hello Consuming ServerHello handshake message ( "ServerHello": { 証明書チェーン Consuming server Certificate handshake message ( "Certificates": [ エラー 2021/08/23 06:52:41 | javax.net.ssl|ERROR|52|StartupSequencer|2021-08-23 06:52:41.890 PDT|TransportContext.java:318|Fatal (CERTIFICATE_UNKNOWN): PKIX path building failed: java.security.cert.CertPathBuilderException: No issuer certificate for certificate in certification path found. ( 2021/08/23 06:52:41 | "throwable" : { 2021/08/23 06:52:41 | sun.security.validator.ValidatorException: PKIX path building failed: java.security.cert.CertPathBuilderException: No issuer certificate for certificate in certification path found. 2021/08/23 06:52:41 | at java.base/sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:439) 上記の手順は、SSL ハンドシェイクの標準です。ただし、証明書チェーンステップが失敗し、接続が確立されません。証明書チェーンのステップでは、エラーの前に MID サーバーに返送された証明書を確認できます。

証明書の分析

Windows

MID サーバーホストから、MID で設定されているものと同じプロキシ (存在する場合) を使用して、ターゲット URL を開き、証明書を分析します。

Linux

Linux MID サーバーでは、OpenSSL コマンドラインツールを使用して証明書を表示できます。次に例を示します (INSTANCENAME を置き換えて、ポート番号が正確であることを確認してください)。

openssl s_client -showcerts -servername INSTANCENAME.service-now.com -connect INSTANCENAME.service-now.com:443 2>/dev/null 次の例は、すべての証明書をファイルに出力する方法を示しています。

openssl s_client -showcerts -servername INSTANCENAME.service-now.com -connect INSTANCENAME.service-now.com:443 2>/dev/null all.crts この時点で、ブラウザ、openssl からの出力、および MID サーバーラッパーログに同じ証明書が表示されます。次に、MID サーバー cacerts ファイル内の証明書を一覧表示します。OOB JRE を使用する場合、cacerts は \agent\jre\lib\security\cacerts になります。keytool を使用して、証明書を一覧表示できます。たとえば、次のようになります。

上記のコマンドでは、keytool を使用して証明書をテキストファイルに送信しました。keytool のデフォルトのパスワードは「changeit」です。

keytool -list -v -keystore "..\lib\security\cacerts" > C:\temp\certificates.txt 証明書を cacerts にあるものと比較すると、中間証明書が cacerts に存在しないことがわかります。証明書が実際に存在しないため、接続は終了します。これはセキュリティ上の理由によるものです。このような場合の簡単なワークアラウンドは、このターゲットのポリシーを作成し、[証明書チェーンチェック] オプションを false に設定することです。MID サーバー証明書チェックポリシーの作成については、「 MID サーバー証明書チェックポリシー 」を参照してください。また、接続の失敗が MID サーバーとインスタンス間の初期接続である場合は、MID サーバーの config.xml に次のパラメーターを追加できます。

ただし、より適切な解決策は次のとおりです。

この証明書が有効/安全であることをチームに確認します 証明書を MID サーバー cacerts に追加します

証明書が提供されたら、「 KB0816002 ブラウザから SSL 証明書を取得する方法 」の手順に従って証明書を取得し、次のコマンド例を使用して証明書を cacerts に追加することもできます。

keytool -import -alias -file "" -keystore "\lib\security\cacerts" たとえば、次のように入力します。

keytool -import -alias MyCA -file "C:\myca.cer" -keystore "C:\Program Files\Java\jre1.8.0_161\lib\security\cacerts" 証明書が追加されると、エラーは表示されなくなり、接続は成功します。

注意： ルート証明書と中間証明書のみを信頼証明書信頼リストに追加する必要があります。リーフ (エンドエンティティ) 証明書を証明書信頼リストに追加しないでください。

OCSP エラー トラブルシューティングの手順：

MID サーバーログを確認します OCSPCheck 機関を決定します MID サーバーと OCSPCheck 機関間の通信を許可します OCSPCheck 機関が certStatus 「good」で応答することを確認します SSL デバッグを有効にして問題を再現すると、MID サーバーエージェントログに次の例のようなエラーが表示されます。

08/23/21 08:38:29 (563) StartupSequencer WARNING *** WARNING *** OCSPCheck authority: http://ocsp.entrust.net, error: java.net.ConnectException: Connection timed out: connect 08/23/21 08:38:29 (563) StartupSequencer WARNING *** WARNING *** Request not sent to uri= https://instance.service-now.com/InstanceInfo.do?SOAP : org.apache.commons.httpclient.HttpException: Connection timed out: connect *.service-now.com ECCQueueMonitor.1 WARNING *** WARNING *** OCSP revoke check IOException for *.service-now.com ECCQueueMonitor.1 WARNING *** WARNING *** org.apache.commons.httpclient.HttpException: OCSP communication error 403 Method failed: (/) with code: 403 - Forbidden username/password combo File sync worker: ecc_agent_jar WARNING *** WARNING *** Socket error File sync worker: ecc_agent_jar WARNING *** WARNING *** OCSP revoke check IOException for *.service-now.com File sync worker: ecc_agent_jar WARNING *** WARNING *** org.apache.commons.httpclient.HttpException: Connection reset 注意：上記の例では、OCSPCheck 機関は https://ocsp.entrust.net/ です。この情報は証明書から取得されるため、別のアドレスである可能性があります。

ラッパーログでは、ハンドシェイクが成功したことがわかります。ただし、上記のエラーにより、MID サーバーは証明書が失効しているかどうかを確認できませんでした。ハンドシェイクの「証明書」ステップでは、ラッパーログに「AuthorityInfoAccess」が表示されます。これは、証明書が失効していないことを確認するために MID サーバーが接続するエンドポイントのアドレスです。

MID サーバーが accessLocation URIName に到達できない場合、失効テストは合格しません。

問題を解決するには、次を実行します。

MID サーバーと OCSP サーバー間の通信を確認し、certStatus の結果を確認します。 MID サーバーが OCSP サーバーと通信できることを確認します。通信がブロックされている場合は、ネットワークチームの関与が必要になる場合があります トラフィックを確認し、サーバーが certStatus「good」で応答したことを確認します。wireshark を使用した次の例では、MID サーバーが OCSP サーバーに到達でき、certStatus が「good」であることがわかります または、OCSP チェックが実行されないようにターゲット URI のポリシーを作成します。これは推奨されるワークアラウンドではありません 注意： セキュリティチームは、上記の 2 つのうち、最も安全なソリューションと考えるものを決定する必要があります。

OCSP エラーが原因で MID サーバーがダウンしている場合は、一時的なワークアラウンドとして、config.xml で次の MID サーバーパラメーターを設定することもできます。