MID Server と証明書Summary 目次 はじめにMID Server 証明書チェックの概要 導入タイムラインを確認する 1.MID Server からインスタンス、統合、またはその間のプロキシ/ファイアウォールへの送信 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キーストアについてはいくつかの混乱がありますが、この KB ではこれを明確にしたいと考えています。これは、パッチやホットフィックスで文書化されていない変更が行われ際に、Orlando/Paris の期間内にテクニカルサポートによって最初に公開されました。Quebec のドキュメントおよび要件は現在、開発者によって公開されているため、以下で説明する詳細に深く入り込む前に、まずは次の Quebec に関するページを参照してください。 MID Server 証明書チェックポリシー これには以下が含まれます。 TLS/SSL 証明書の検証ホスト名の検証Online Certificate Status Protocol (OCSP)MID Server セキュリティポリシー (証明書チェーンを含む)MID セキュリティセンター KB0864770 self-hosted顧客の MID Server 証明書チェックセキュリティポリシー (URL が...service-nowやcomでないhostedインスタンスも含みます。)KB0867397 MID Server TLS/SSL 証明書チェックポリシー Quebec アップグレード情報KB0864766 Quebec へのアップグレード時に MID Server の接続エラーが発生する (3 つのチェックすべてに対する Quebec の一時的なワークアラウンドが含まれていますが、これは長期的な解決策として使用しないでください) 注意:相互認証が使用されている場合、このワークアラウンドは使用できません。 MID Server リリースノート (Quebec) デバッグに関するヒント:Quebec 以降、証明書関連の問題のデバッグログは大きく向上しています。問題の対処に時間をかける前に、下記の MID Server パラメーターを config.xml に追加し、MID Server を再起動してください。 <parameter name="mid.log.level" value="debug"/> MID Server 証明書チェックの概要 SSL / TLS証明書には主に3つの種類があります。 Windows/Linux/Java で既に広く信頼されているベンダーから購入した、署名された信頼されたルート CA。会社の Active Directory/ドメイン サーバーによって生成された、署名済みの内部 CA。デフォルトでは、その 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 パッチ 8 (および 7a)YYNParisYNNParis パッチ 2 (および 1 ホットフィックス 3a、1 ホットフィックス 5a)YYNQuebecYYY 1.MID Server からインスタンス、統合、またはその間のプロキシ/ファイアウォールへの送信 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 HTTP port 80 is normal for OCSP/CRL servers, and as it is a security protocol, should normally be possible to make an exception for in your company's security policies. このツールをサード パーティの "SSL Labs" Web サイトで使用して、インスタンスの証明書の OCSP/CRL URL を確認できます。「hi.service-now.com」URL をインスタンス URL と入れ替えます。「失効情報 (Revocation information)」セクションには、MIDサーバーホストのファイアウォールで開く必要があるURLが表示されます。HTTPポート80はOCSP/CRLサーバーでは一般的であり、セキュリティプロトコルであるため、通常、会社のセキュリティポリシーで例外にすることができます。 証明書が実際に失効している場合は、このツールによっても確認されます。そのような状況において適切なのは、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のシステム要件ウィキペディア: オンライン証明書ステータスプロトコル (OCSP)MID Server 証明書チェックポリシー (Quebec) ナレッジベース記事: KB0854165 MID Server の OSCP 要件の詳細 (Orlando/Paris の一時的な回避策を含みますが、これを長期的な解決策として使用しないでください)KB0864766 Quebec へのアップグレード時に MID Server の接続エラーが発生する (3 つのチェックすべてに対する Quebec の一時的なワークアラウンドが含まれていますが、これを長期的な解決策として使用しないでください) 関連する問題: PRB1385357 OCSP 証明書の失効検証チェックを ocsp.entrust.net するための新しい外部接続要件が原因で、MID Server のインストールまたは Orlando へのアップグレードに失敗することがあるPRB1417416同時実行パフォーマンス:OCSPCheckedCertificateCache の JVM ロックが解放されないため、インポートスケジュールに指数関数的に時間がかかります (警告 *** スタックした JVM ロックを解放しました:OCSPCheckedCertificateCache) - Quebec の修正PRB1419209 MID Server OCSP タイムアウトが例外をスローしないため、インスタンスへの接続が永久に残るPRB1473617 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 サーバーから生成された自己署名証明書を示しています。 これは通常、ディープパケットインスペクション(DPI)の一種であるHTTPS/SSLインスペクション/インターセプトを実装しているWebアプリケーションファイアウォール(WAF)が原因であり、悪意のあるものをフィルタリング、監視、ブロックするために、事実上の中間者攻撃です。MID サーバは、そのデバイスによって発行された証明書を信頼できることを通知し、悪意のある中間者攻撃ではなく、承認されていることを確認する必要があります。 一部のプロキシ/ファイアウォール/ロードバランサーデバイスは、証明書を定期的に変更するように設定されている場合があり、手動で cacerts に追加した証明書は機能しなくなります。たとえば、Zscaler ロードバランサーは 2 週間ごとにこれを実行します。唯一の解決策は、デバイスに例外/バイパスを追加して、インスタンス URL に接続する MID Server ホスト の代行受/検査を有効にするか、Java のデフォルトの cacerts ファイルがすでに信頼しているパブリック ルート CA から証明書を購入することです。 従来のプロキシサーバーを使用している場合、ホスト名は MID Server フォームの MID Server 構成パラメーターに表示されます。mid.proxy.use_proxy = true パラメーターが表示されない場合は、引き続きプロキシ/ファイアウォールが接続をインターセプトしている可能性があります。 ワーカーノードを持つインスタンスで、 MIDサーバーがワーカーノード用の特別なURLに接続するように設定されている場合、同じ証明書が使用され、インストールファイルとアップグレードファイルがある install.service-now.com Server でも使用されます。 Orlando パッチ 7A/8、Paris パッチ 1 ホットフィックス 3A/5A、Paris パッチ 2、および Quebec は、TLS 証明書 (PRB1419895) を使用して、すべてのアウトバウンド要求の証明書チェーンをチェックするコードを追加します。これにより、以前にチェックされていなかった証明書が cacerts 内に欠落しているためにエラーが発生する場合があり、統合およびインスタンスへの接続が切断されることあります。OCSP チェックをオフにするという上記の回避策では、このチェックも一時的にオフになります。 ナレッジベース記事: KB0816002 ブラウザからSSL証明書を取得する方法KB0863109 MID Server が ServiceNow インスタンスに接続できません。エージェントログにエラー:org.apache.commons.httpclient.HttpException:javax.net.ssl.SSLPeerUnverifiedException:ピアが認証されていませんTLS1.0 および 1.1 の廃止KB0746078MID Server とワーカーノードKB0854165 MID Server の OSCP 要件の詳細 (Orlando/Paris の一時的なワークアラウンドを含みますが、これは長期的な解決策として使用しないでください)KB0864766 Quebec へのアップグレード時に MID Server の接続エラーが発生する (3 つのチェックすべてに対する Quebec の一時的な回避策が含まれていますが、これは長期的な解決策として使用しないでください) ドキュメントのリンク: MID Server用の SSL 証明書を追加するOracle Java: keytoolWikipedia: HTTPS, Transport Layer Security (TLS/SSL), Java KeystoreMID Server 証明書チェックポリシー (Quebec) 関連する問題: PRB1419895 証明書の検証の欠如 KB0861038 Orlando Patch 7a / KB0861889 Paris Patch 1 Hotfix 3a セキュリティ修正リリースノート PRB1447511証明書の検証が不足しているPRB1419895に対するホットフィックスが原因で MID Server がダウンします。 PRB1320637 新しいバージョンの JRE を含む MID Server のアップグレードによって、cacerts ファイルが上書きされる PRB1451866 PRB1320637 の修正では、cacerts トラストストアファイルのパスワードをデフォルトの「changeit」のままにする必要があります。これは多くのお客様が許可しないため、JRE のアップグレード中 (Quebec など) やそれに続く MID Server と統合の停止中に証明書が削除されるPRB1454071 MID Server トラストストア移行で、CA 発行のフラグが立てられた証明書を移行しないPRB1473617 JRE のアップグレード前に cacerts ファイルのパスワードを変更すると、次のエラーが発生する:デフォルトのパスワードまたは指定したパスワードを使用して jvm キーストアをロードできませんでした 例 最初の 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リクエストからのものですが、インスタンスに対する他のすべてのリクエストには、「ピアが認証されていません」という同様のエラーが表示されます。 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://c<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 Quebec へのアップグレード時に MID Server の接続エラーが発生する (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) MID Server 相互認証の有効化 Quebec MID Server リリースノート Quebec リリースの新機能 Windows (Quebec)への MID Server のインストール - [認証タイプ] フィールドを参照してください。 既知の問題: サブジェクト CN が SAN DNS 名と異なる特定の証明書で、AMB チャネルが接続に失敗することがある (Problem 確認中)ユーザー名/パスワードを使用して既に検証された後に MID Server を mTLS に変換する (Problem 確認中) 注意:少なくとも Quebec までは、 送信 Web サービス (インスタンス以外) の相互認証は MID Server ではサポートされていません。たとえば、証明書がインスタンスに追加されている場合は、インスタンスから直接エンドポイントへの REST メッセージを実行できますが、MID Server を経由することはできません。 4.統合からの MID Server Web サーバー拡張への受信 4.1 SSL/TLS 接続 キーストアファイル: 統合キーストア (Quebec 以降) MID Server が、受信 REST/SOAP、Event Management によるイベント収集、または Agent Client Collector インストールなどのプッシュ統合を受信する Web サーバーとして機能している場合、この Web サーバーに使用する証明書は、デフォルトで自動生成された自己署名証明書です。これは、セキュリティ ポリシーに問題を引き起こす可能性が高く、信頼できるポリシー (通常は内部 CA によって生成されたもの) または購入したもの (特にインターネットに接続する Web サーバーの場合) に置き換える必要があります。 これは、お客様によって提供/生成された Web サーバーの秘密鍵です。 これは、Keytoolユーティリティを使用して統合キーストア(.\agent\securuty\keystore)に追加されます。 追加する必要があるのはホストの証明書のみであるため、ファイルには証明書が 1 つしかありません。 この証明書は、MID Server の Web サーバーに要求を送信するときに使用される URL 用であり、DNS エイリアスまたはロードバランサーが使用されている場合、MID Server のホスト名であるとは限りません。 Event Management 機能には、これに関する最良のドキュメントがあります (Agent Client Collector からのメトリック収集について)。ただし、他の機能は同じ Web サーバー拡張統合機能を使用します。 統一キーストアを使用する Quebec バージョン: MID Web サーバー拡張の設定Event Management MID Web Server 拡張のフォームMID Server の統一キーストアへのカスタム証明書のインストール 注意:Paris バージョン以前では、これは .\agent\keystore\webserver_keystore.jceks に追加された証明書を使用して、別の方法で行われていました。まだそれについて言及しているドキュメントやKBは無視してください。 PRB1454515 Adding back the custom keystore ability on the MID web server (to support certificate chains for MID web servers) - Fixed in Rome. 4.2 鍵ベースの認証 これは、Agent Client Collector が MID Server での認証を行うために使用されます。 キーベースの MID Web サーバー認証の設定 注:Rome では、これは MID Server ごとに 1 つのキーに制限されています。San Diego リリースでは、キーのローテーションに役立つように、一度に複数のキーを使用できます。 4.3 mTLS 認証 Rome パッチ 4 以降では、証明書ベースの相互認証を使用できます。 MID Web Server の mTLS 認証