MID Server と証明書Summary Table of Contents イントロダクションMID サーバー証明書チェックの概要 導入タイムラインの確認 1. MIDサーバーからインスタンス、統合、またはプロキシ/ファイアウォールへのアウトバウンド 1.1 OCSP チェック1.2 証明書チェーンチェック1.3 ホスト名チェック 2. MID Server サーバーからインスタンス (検証/暗号化用)3. MID Server からインスタンス (認証用)4. 統合から MID Server Web サーバー拡張へのインバウンド 4.1 SSL/TLS 接続 4.2 キーベース認証4.3 mTLS認証 イントロダクション MID Server に関連する証明書と Java KeyStore が混同されている場合があるため、この KB で説明します。これは、文書化されていない変更がパッチとホットフィックスで行われ際に、Orlando/Paris の期間内にテクニカルサポートによって最初に公開されました。Quebec のドキュメントおよび要件は現在、開発者によって公開されているため、 まずは Quebec に関するページを参照していただき、それから下記の詳細をお読みください。 MID Server 証明書チェックポリシー(以下をカバーしています。) TLS/SSL 証明書の検証ホスト名の検証Online Certificate Status Protocol (OCSP)MID Server セキュリティポリシー (証明書チェーンを含む)MID セキュリティセンター KB0864770 MID Server certificate check security policies for self-hosted customers (URLが... service-now.com ではないホスト型インスタンスもカバー)KB0867397 MID Server TLS/SSL certificate check policy Quebec upgrade informationKB0864766 MID Server connection failures when upgrading to Quebec (3 つのチェックすべてに関する Quebec の一時的なワークアラウンドが含まれますが、これは長期的なソリューションとして使用すべきものではありません) 注意：相互認証が使用されている場合、このワークアラウンドは使用できません。 MID Server のリリースノート (Quebec) デバッグに関するヒント：Quebec 以降、証明書関連の問題のデバッグログは大きく向上しています。問題の対処に時間をかける前に、下記の MID Server パラメーターを config.xml に追加し、MID Server を再起動してください。 <parameter name="mid.log.level" value="debug"/> MID サーバー証明書チェックの概要 SSL/TLS 証明書には主に 3 種類あります。 信頼されたルート CA 署名証明書。Windows/Linux/Java で既に広く信頼されているベンダーから購入します。内部 CA 署名証明書。社内の Active Directory/ドメインサーバーによって生成されます。デフォルトでは、この CA は信頼されません。自己署名証明書。証明書チェーンや CA は関与せず、通常はエンドポイント/ターゲットデバイス自身によって生成されます。デフォルトでは、これらは信頼されません。 3 つの方法でチェックされます。 失効チェック。証明書が予定の有効期限前に廃止された場合に備えます。証明書内の OCSP 情報と、指定された OCSP サーバー URL へのアクセスが必要です。証明書チェーンチェック。中間証明書とルート証明書が有効であることを確認します。内部ルート CA 証明書を 'cacerts' ファイルに追加する必要がある場合があります。ホスト名チェック。アクセス先の URL を、証明書内のサブジェクト CN またはサブジェクト代替名の値と比較します。 3 つの異なる IP 範囲について： デフォルトでは「*.service-now.com」がインスタンスです。オンプレミス/カスタムURLインスタンスのセルフホスト型ではオーバーライド可能です。イントラネット（プライベートIPネットワーク範囲：10.0.0.0/8、172.16.0.0/12、192.168.0.0/16）インターネット（その他すべてのIP） 導入タイムラインの確認 バージョンOCSP チェック証明書チェーンチェックホスト名チェックNew York 以前NNNOrlandoYNNOrlando Patch 8 (and 7a)YYNParisYNNParis Patch 2 (and 1 Hot Fix 3a, 1 Hot Fix 5a)YYNQuebecYYY 1. MIDサーバーからインスタンス、統合、またはプロキシ/ファイアウォールへのアウトバウンド 1.1 OCSP チェック Orlando 以降、MID Server は証明書が何らかの理由で取り消されていないことを検証する必要があるため、MID Server ホストは証明書の OCSP/CRL サーバーとインスタンス URL に接続できる必要があります。 Paris リリース以降、Entrust から購入しており、Entrust OCSP/CRL サーバーの URL をファイアウォールで開く必要があります。Entrust は DNS ベースによる負荷分散を使用し、IP の解決は毎回異なる可能性があるため、URL を常にファイアウォールで開く必要があります。CRL：http://crl.entrust.net/level1k.crlOCSP：http://ocsp.entrust.net サードパーティの「SSL ラボ」 Web サイトのツールを使用して、インスタンスの証明書の OCSP/CRL URLを確認できます。「hi.service-now.com」URL をインスタンス URL に置き換えます。[失効情報 (Revocation information)] セクションに、ファイアウォールで開く必要がある MID Server ホストの URL が表示されます。OCSP/CRL サーバーにとっては HTTP ポート 80 が一般的であり、これはセキュリティプロトコルであるため、通常、会社のセキュリティポリシーで例外にすることができます。 証明書が実際に失効している場合は、このツールによっても確認されます。そのような状況において適切なのは、MID Server がそのエンドポイントをブロックすることです。 MID Server エージェントログには、次のエラーが複数のスレッドに記録されます。 WARNING *** WARNING *** OCSP revoke check IOException for *.service-now.com WARNING *** WARNING *** org.apache.commons.httpclient.HttpException: Connection reset ドキュメントのリンク： MID Server のシステム要件Wikipedia： Online Certificate Status Protocol (OCSP)MID Server 証明書チェックポリシー (Quebec) ナレッジベース記事： KB0854165 MID server OCSP requirement details (Orland/Paris のための一時的なワークアラウンドが含まれますが、それは長期的な解決策として使用すべきものではありません)KB0864766 MID Server connection failures when upgrading to Quebec (3 つのチェックすべてに関する Quebec の一時的なワークアラウンドが含まれますが、これは長期的なソリューションとして使用すべきものではありません) 関連する問題： PRB1385357 MID Server can fail to install or upgrade to Orlando due to new external connectivity requirement to ocsp.entrust.net for OCSP certification revocation verification checkPRB1417416 Concurrency performance: JVM locks on OCSPCheckedCertificateCache are not released leading to import schedules taking exponentially longer (WARNING *** Freed stuck JVM lock: OCSPCheckedCertificateCache) - Quebec の修正。PRB1419209 MID Server OCSP timeouts not throwing exceptions causing connection to instance to stay foreverPRB1473617 1.2 証明書チェーンチェック キーストアファイル：.\agent\jre\lib\security\cacertsデフォルトパスワード：changeit これらは、発信 HTTPS 接続の SSL/TLS (Transport Layer Security) 証明書の公開鍵です。インスタンス、LDAPS サーバー、その間のプロキシ/ファイアウォールなどの送信統合では、証明書を使用して安全な HTTPS 接続を設定する必要があります。ServiceNow インスタンスへの接続では、HTTP 接続は禁止されています。要求するサーバーに自己署名証明書がある場合、またはチェーンに通常のルート証明書がない証明書の場合は、cacerts ファイルに証明書をロードする必要があります。 最善の長期ソリューションは、ネットワークデバイス用に、認識されたルート CA から証明書を購入することです。MID Server は、何もすることなくこれらを自動的に信頼します。 これは、agent\jre\bin\keytool.exe (Linux の場合は /agent/jre/bin/keytool) を使用して行われます。中間証明書を含む、証明書チェーン全体を追加することが必要な場合があります。 すべてのインスタンスと MID Server に必要なすべての証明書を同じ cacerts ファイルにロードし、そのファイルをすべての MID Server にコピーすることが可能です。そのファイルのバックアップを保持することもお勧めします。 これは、サードパーティ統合に使用されるだけではありません。プロキシサーバー、ファイアウォール、ロードバランサー、またはその他の透過的なネットワークデバイスが、MID Server からインスタンスへのトラフィックをインターセプトしている場合、MID Server が信頼する必要がある証明書はネットワークデバイスのものであり、インスタンスのものではありません。これを確認するには、MID Server ホストのブラウザーでインスタンスを開き、証明書を確認します。それが、Entrust によってサポートされている *.service-now.com の場合は、何もする必要はありません。そうでない場合は、ブラウザーからその証明書をエクスポートし、またチェーンのそこまでのすべての証明書をエクスポートし、それらを cacerts ファイルにインポートします。 MID Server ホストからインスタンスにアクセスするブラウザーでは、証明書チェーンは次のようになります (Paris 以降)。URl の横にある南京錠アイコンをクリックし、証明書を選択します。 HTTPS インスペクション/SSL インターセプト チェーンが異なるように見える場合は、透過的なネットワークデバイスが中間にあり、インスタンスとの間で通常の証明書を使用していますが、MID Server とそれ自体の間の HTTPS 接続を別の証明書に置き換えている可能性があります。以下の例では、黒塗りの部分はお客様の会社名であり、独自の CA サーバーから生成された自己署名証明書を示しています。 これは通常、Web アプリケーションファイアウォール (WAF) で HTTPS/SSL インスペクション/インターセプトを実装しているためであり、何らかの悪意のあるものをフィルター、監視、ブロックするためのディープパケットインスペクション (DPI) の 1 つの形式 (実質的には中間者攻撃) です。MID Server は、そのデバイスによって発行された証明書は信頼できるということを通知されていて、許可されているものであり悪意のある中間者攻撃ではないことを認識している必要があります。 一部のプロキシ/ファイアウォール/ロードバランサーデバイスは、証明書を定期的に変更するように設定されている場合があり、手動で cacerts に追加した証明書は機能しなくなります。たとえば、Zscaler ロードバランサーは 2 週間ごとにこれを実行します。唯一の解決策は、例外をデバイスに追加して、インスタンス URL に接続している中間サーバーホストのインターセプト/インスペクションをオフにするか、パブリックルート CA から適切な証明書を購入することです。 従来のプロキシサーバーを使用している場合、ホスト名は MID Server フォームの MID Server 構成パラメーターに表示されます。mid.proxy.use_proxy = true パラメーターが表示されない場合は、引き続きプロキシ/ファイアウォールが接続をインターセプトしている可能性があります。 ワーカーノードを含むインスタンスで、MID Server がワーカーノードの特別な URL に接続するように設定されている場合は、同じ証明書が使用されます。これは、インストールおよびアップグレードファイルを持つ install.service-now.com サーバーでも使用されます。 Orlando パッチ 7A/8、Paris パッチ 1 ホットフィックス 3A/5A、Paris パッチ 2、および Quebec は、TLS 証明書 (PRB1419895) を使用して、すべてのアウトバウンド要求の証明書チェーンをチェックするコードを追加します。これにより、以前にチェックされていなかった証明書が cacerts 内に欠落しているためにエラーが発生する場合があり、統合およびインスタンスへの接続が切断されることあります。OCSP チェックをオフにするという上記の回避策では、このチェックも一時的にオフになります。 ナレッジベース記事： KB0816002 How to obtain SSL certificate from the browserKB0863109 MID Server cannot connect to ServiceNow instance, error in agent log: org.apache.commons.httpclient.HttpException: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticatedKB0746078 Retiring TLS1.0 and 1.1MID Servers and Worker NodesKB0854165 MID server OCSP requirement details (Orland/Paris のための一時的なワークアラウンドが含まれますが、それは長期的な解決策として使用すべきものではありません)KB0864766 MID Server connection failures when upgrading to Quebec (3 つのチェックすべてに関する Quebec の一時的なワークアラウンドが含まれますが、これは長期的なソリューションとして使用すべきものではありません) ドキュメントのリンク： Add SSL certificates for the MID ServerOracle Java：keytoolWikipedia：HTTPS、トランスポートレイヤーセキュリティ (TLS/SSL)、Java KeyStoreMID Server 証明書チェックポリシー (Quebec) 関連する問題： PRB1419895 Lack of Certificate Validation/KB0861038 Orlando Patch 7a/KB0861889 Paris Patch 1 Hotfix 3aセキュリティ修正リリースノート PRB1447511 Hotfix for PRB1419895 Lack of Certificate Validation causes MID Server DOWN. PRB1320637 A MID Server upgrade that includes a new JRE version will overwrite the cacerts file PRB1451866 The fix for PRB1320637 requires that the cacerts Truststore file password remains as the default "changeit", which many customers won't allow, causing certificate deletion during JRE upgrades (e.g. Quebec) and subsequent MID Server and Integration outagePRB1454071 MID Server TrustStore migrator will not migrate certificates flagged as CA-issuedPRB1473617 Changing password of cacerts file prior to JRE upgrade causes error: Failed to load the jvm key store using the default password or specified password 例 最初の 2 つの例には「URI に送信されない要求 (Request not sent to uri)」が含まれています。これは、MID Server はその URI を信頼しないと判断し、すべての要求を送信していないことを意味します。これは、エンドポイント証明書に関して問題があることを示す良い手掛かりとなります。 プロキシ/ファイアウォールを介してインスタンスに接続すると、エージェントログにこのエラーが表示されることがあります。これは JAR ファイル要求からのものですが、インスタンスに対する他のすべての要求にも同様のエラーが発生します。エラーの「URI」は、この原因の診断エラーであるインスタンスに対するものであることに注意してください。この場合、必要な証明書はインスタンス URL ではなく、ネットワークデバイス URL に対するものになります。ここで手掛かりとなるのは「証明書チェーンを見つけられない (Unable to find certificate chain)」ことです。 File sync worker: ecc_agent_jar WARNING *** WARNING *** Request not sent to uri= https://<INSTANCE_NAME>.service-now.com/MIDFileSyncSnapshot.do?SOAP : javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: java.security.cert.CertPathBuilderException: Unable to find certificate chain.File sync worker: ecc_agent_jar SEVERE *** ERROR *** SOAP Request: <SOAP-ENV:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:tns="http://www.service-now.com/GetMIDInfo" xmlns:m="http://www.service-now.com" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Body><m:execute><attachments xsi:type="xsd:string">true</attachments><type xsi:type="xsd:string">ecc_agent_jar</type></m:execute></SOAP-ENV:Body></SOAP-ENV:Envelope>File sync worker: ecc_agent_jar SEVERE *** ERROR *** SOAP Response: Status code=0, Response body=nullFile sync worker: ecc_agent_jar WARNING *** WARNING *** Could not get file sync snapshot because: Request not sent to uri= https://<INSTANCE_NAME>.service-now.com/MIDFileSyncSnapshot.do?SOAP : javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: java.security.cert.CertPathBuilderException: Unable to find certificate chain. Entrust ルート証明書が利用できず、cacerts ファイルに追加する必要があるインスタンス証明書の同様のエラー。これは InstanceInfo 要求からのものですが、インスタンスに対する他のすべての要求にも同様のエラーが発生します。ここで手掛かりとなるのは「認証されていないペア (peer not authenticated)」です。 StartupSequencer WARNING *** WARNING *** Unable to get InstanceInfo: Request not sent to uri= https://<INSTANCE_NAME>.service-now.com/InstanceInfo.do?SOAP : org.apache.commons.httpclient.HttpException: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated(Network Configuration issue) Please check that the MID server can ping the instance: https://<INSTANCE_NAME>.service-now.com/You may also need to configure the network that the MID server uses to allow traffic over TCP port 443. インスタンスのテストロードレコードフォームに表示される、AD サーバーの証明書が欠落している LDAPProbe インポート。MID Server エージェントログにも表示されます。ここでの手掛かりは、「証明書パスに証明書の証明書発行者が見つかりません (No issuer certificate for certificate in certification path found)」となります。 MID Server reported error: javax.naming.CommunicationException: RTCDOMPRD03.rt.corp:636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: java.security.cert.CertPathBuilderException: No issuer certificate for certificate in certification path found.]at com.sun.jndi.ldap.Connection.<init>(Connection.java:238)at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:137)at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1609)at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2749)at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)at javax.naming.InitialContext.init(InitialContext.java:244)at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)at com.service_now.mid.probe.LDAPProbe.verifyConnectivity(LDAPProbe.java:124)at com.service_now.mid.probe.LDAPProbe.doWork(LDAPProbe.java:99)at com.service_now.mid.probe.LDAPProbe.probe(LDAPProbe.java:77)at com.service_now.mid.probe.AProbe.process(AProbe.java:103) エンドポイントの証明書が欠如した JavascriptProbe： Agent Log:Worker-Standard:JavascriptProbe-05422d31db9c9050d6f9f9b2f396193f WARNING *** WARNING *** javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: java.security.cert.CertPathBuilderException: Unable to find certificate chain.Caused by error in MID Server script include 'CSMIDServerRemoteFileImport' at line 23 Wrapper Log:Worker-Standard:JavascriptProbe-05422d31db9c9050d6f9f9b2f396193f, SEND TLSv1.2 ALERT: fatal, description = certificate_unknownWorker-Standard:JavascriptProbe-05422d31db9c9050d6f9f9b2f396193f, WRITE: TLSv1.2 Alert, length = 2Worker-Standard:JavascriptProbe-05422d31db9c9050d6f9f9b2f396193f, called closeSocket()Worker-Standard:JavascriptProbe-05422d31db9c9050d6f9f9b2f396193f, handling exception: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: java.security.cert.CertPathBuilderException: Unable to find certificate chain. 1.3 ホスト名チェック Quebec の新機能。 エラーの例：確認中 ドキュメントのリンク：MID Server 証明書チェックポリシー (Quebec) ナレッジベース記事：KB0864766 MID Server connection failures when upgrading to Quebec (3 つのチェックすべてに関する Quebec の一時的なワークアラウンドが含まれますが、これは長期的なソリューションとして使用すべきものではありません) 2. MID Server サーバーからインスタンス (検証/暗号化用) キーストアファイル：.\agent\keystore\agent_keystore.jks これは MID Server の起動時に自動的に作成される秘密キーであり、インスタンスと MID Server 間の信頼を確立し、Discovery 資格情報や暗号化されたその他の ecc_queue ペイロードデータなどのデータを復号化するための証明書が含まれています。そのファイルが正しくない限り、ジョブを実行するために MID Server を検証することはできません。または、ジョブの実行時に使用するインスタンスから資格情報を復号化することもできません。 このファイルは多くの場合、アップグレード後の最初の起動時に自動的に再作成され、また定期的に更新されます。 その更新が機能している場合、MID Server のエージェントログでは次のようになります。 StartupSequencer Updated public key, new certificate: [0] Version: 3 SerialNumber: 1603732292 IssuerDN: CN=snc-mid-datacenterdev_dva400_disco_midserver17-52721102f0331010e36955d33f0f9500,DC=service-now,DC=com Start Date: Mon Oct 26 10:11:32 PDT 2020 Final Date: Tue Oct 26 10:11:32 PDT 2021 SubjectDN: CN=snc-mid-datacenterdev_dva400_disco_midserver17-52721102f0331010e36955d33f0f9500,DC=service-now,DC=com Public Key: RSA Public Key [30:57:b5:a0:57:98:94:a2:e2:66:dd:79:b3:7f:37:6c:d8:9a:31:ff],[56:66:d1:a4] modulus: d2cd8c54a36990c57bd4146eea3677913b491fd82541ea462d15cf22a057a010c88bcd154f910134251ceccbbcbc5bbf00315199f557428986fc21b041fe4f8941ddc43a79d0257cc01c48fd681a39a7490255a6b2fb63dbaf01184727d15dcebfc9d1d2e3a532ece1512b418626f8c663d193d9cb896db29bec44fafcea63458b5497964155580d6389653a4613c4ceabd52d4a60228f127e59da4c32d394eab013ea0d3bb236c1ad1d5642135869de2047124164f7ea2f1a692df2e6bf174d896ea4c49c93e979cd905875c528061df8867fd06ac79f17b882ecaedf75bb54535a71d52368dff6a3baecc45e9ae9202289ccda7621015ff2372ac22906e0d1public exponent: 10001 Signature Algorithm: SHA512WITHRSA Signature: 6a6202d16462659433f461c5153207a2aa6a63dc 5c4263c1ac2af3aba7da8b2b0208606db958ae5a 577f38df6a2fdfb80d21f5306a1ec0e695a64cf6 aa97b4da715f19d41907df95e4e6a2e4e6157577 9e68407d48a794248a76890e6bfc22cb60e29db2 7100976fd5d2f947aa267cda262e6b2ba52e705d af47ff7cb972b44b0238b5d0eda24a252499d304 8845e00bb112e762186755ce3079ec45194cfc0f 23b3adca0f7a38137aea35e1bf978f3f65b4cfe2 68aae654469716d54e2fda433b1142fe478fccb0 f1ae683e050ba14062e8593e4cc4e684c68f339e 09e376c3b8f74fc8d54bd4452dbc4a4cfbf9d047 a42cdad2e608eeab1ea16a753bb54923 失敗した場合は次のようになります。 StartupSequencer SEVERE *** ERROR *** UpdatePublicKey error: Digital signature of new public key must be provided. MID Server encryption keys do not match and are no longer valid. To restore proper functionality, invalidate and re-validate the MID Server.StartupSequencer WARNING *** WARNING *** Unable to update public key, will try again next MID Server restart 通常、署名がないというのではなく、署名が適切ではないと表示されます。例： SEVERE *** ERROR *** Unable to load keystore: Unexpected IOException loading KeyStore, caused by: Keystore was tampered with, or password was incorrect SEVERE *** ERROR *** Keystore and config.xml files out of sync. 1) Delete keystore/agent_keystore.jks or restore config.xml to its previous state, 2) ensure MID server has write permissions to config.xml and to keystore directory, 3) restart MID server. WARNING *** WARNING *** Encountered error: [Unable to load keystore] while starting up the service. Retry... MID Server が稼働している場合は、MID Server フォームの [関連リンク] で [リキー] をクリックすると解決することがあります。 MID Server がダウンした場合は通常、.\agent\keystore\agent_keystore.jks ファイルを削除し、config.xml ファイルから keypairs.mid_id パラメーター値をクリアし、MID Server サービスを再起動すると解決します。起動時に新しい適切なファイルが自動的に作成されます。MID Server は、インスタンス内の MID Server レコードから検証することが必要な場合があります。注意：Quebec 以降、このファイルには Web サーバー証明書、相互認証証明書も含まれる場合があり、後でこれらを再インポートする必要があります。 MID Server のリキー カスタム証明書を使用すると、MID Server のインスタンスでリキーと検証の UI アクションが無効になります。[カスタム証明書の削除 (Remove custom certificate)] という新しい UI アクションを使用して、自己署名証明書の使用に戻すことができます。このアクションを使用すると、MID Server はカスタム証明書を削除し、リキーオプションと同様に新しい自己署名証明書を生成します。 ドキュメント：統一キーストア (Quebec) Rome リリースでは、この統一キーストアを agent/keystore/agent_keystore.jks から新しい場所 agent/security/agent_keystore に移動します。FIPS モードが有効になっている場合は、BCFKS 形式にも変換されます。 3. MID Server からインスタンス (認証用) キーストア：統一キーストア Quebec から、MID Server はオプションで、ユーザー名/パスワードの基本認証の代わりに、相互認証 (mTLS) を使用してインスタンスを認証できます。 少なくとも Quebec までは、送信 Web サービスの相互認証 (インスタンス以外のもの) は MID Server でサポートされていません (例：証明書がインスタンスに追加された場合、インスタンスから直接エンドポイントへの REST メッセージを実行できますが、MID Server 経由では実行できません)。 ドキュメント：統一キーストア (Quebec) MID Server の相互認証を有効にする MID Server のリリースノート (Quebec) Quebec リリースの新機能 Windows への MID Server のインストール (Quebec)： [認証タイプ] フィールドを参照してください。 4. 統合から MID Server Web サーバー拡張へのインバウンド 4.1 SSL/TLS 接続 キーストアファイル: 統合キーストア (Quebec 以降) MID サーバーが、プッシュ通知の受信 (インバウンド REST/SOAP、イベント管理イベント収集、エージェントクライアントコレクターのインストールなど) 用の Web サーバーとして動作している場合、この Web サーバーの証明書はデフォルトで自動生成された自己署名証明書になります。これはセキュリティポリシーに問題を引き起こす可能性があり、信頼できる証明書 (通常は社内 CA によって生成された証明書、またはインターネットに公開されている Web サーバーの場合は購入済みの証明書) に置き換える必要があります。 これは、お客様が提供または生成した Web サーバーの秘密鍵になります。 これは、Keytool ユーティリティを使用して統合キーストア (.\agent\securuty\keystore) に追加されます。ホストの証明書のみを追加する必要があるため、ファイルには証明書が 1 つだけ含まれます。 この証明書は、MID サーバーの Web サーバーにリクエストを送信する際に使用される URL 用です。DNS エイリアスやロードバランサーが使用されている場合、この URL は必ずしも MID サーバーのホスト名とは異なる場合があります。 イベント管理機能（エージェント・クライアント・コレクターからのメトリクス収集用）には、この証明書に関する最も優れたドキュメントが用意されています。ただし、他の機能でも同じ Web サーバー拡張機能統合機能を使用しています。 Quebec 以降のバージョン（統合キーストアを使用） Configure the MID Web Server extensionEvent Management MID Web Server extension formInstall custom certificates in the MID Server unified key store 注: Paris バージョン以前では、.\agent\keystore\webserver_keystore.jceks に証明書を追加するという異なる方法で実行されていました。この点について言及しているドキュメントやナレッジベースは無視してください。 PRB1454515 MID Web サーバーにカスタムキーストア機能を復活（MID Web サーバーの証明書チェーンをサポートするため） - Rome で修正済み。 4.2 キーベース認証 これはエージェントクライアントコレクターが MID サーバーとの認証に使用します。 Configure keybased MID Web Server authentication 注: Romeでは、MIDサーバーごとに1つのキーに制限されています。San Diegoリリースでは、キーのローテーションを容易にするため、複数のキーを同時に使用できます。 4.3 mTLS認証 Romeパッチ4以降、証明書ベースの相互認証が利用可能になりました。 MID Web Server mTLS Authentication