MID Server connection failures when upgrading to Quebec or a later versionProblem When upgrading the MID Server to Quebec or a later version, the MID Server fails to connect and the agent log lists the following error: 10/04/20 10:58:44 (222) Worker-Expedited:MIDWorker-9619b95fdbaf5410bc2e9b3c8a961968 WARNING *** WARNING *** Request not sent to uri= https://jenkins-alpha.lab3.service-now.com/job/triggers/job/nightly-build-completed/build?json=%7B%22parameter%22%3A%5B%7B%22name%22%3A%22branch_name%22%2C%22value%22%3A%22track%2Fdtac%22%7D%2C%7B%22name%22%3A%22branch%22%2C%22value%22%3A%22track%2Fdtac%22%7D%2C%7B%22name%22%3A%22is_nightly%22%2C%22value%22%3Atrue%7D%2C%7B%22name%22%3A%22run_tests%22%2C%22value%22%3Atrue%7D%2C%7B%22name%22%3A%22nightly_build%22%2C%22value%22%3Atrue%7D%2C%7B%22name%22%3A%22release_branch%22%2C%22value%22%3A%22release%2F19.dtac.0.9%22%7D%2C%7B%22name%22%3A%22glide_version%22%2C%22value%22%3A%2219.dtac.0.9%22%7D%2C%7B%22name%22%3A%22sys_id%22%2C%22value%22%3A%22c959cdd31be7101045782f07b04bcb39%22%7D%2C%7B%22name%22%3A%22build_properties%22%2C%22value%22%3A%22none%22%7D%2C%7B%22name%22%3A%22priority%22%2C%22value%22%3A%225%22%7D%2C%7B%22name%22%3A%22has_commits%22%2C%22value%22%3Atrue%7D%2C%7B%22name%22%3A%22force_run%22%2C%22value%22%3Afalse%7D%2C%7B%22name%22%3A%22dmt_tests%22%2C%22value%22%3A%22dmt-dynamictranslation-test%22%7D%2C%7B%22name%22%3A%22request_id%22%2C%22value%22%3A%22none%22%7D%2C%7B%22name%22%3A%22prefix%22%2C%22value%22%3A%22none%22%7D%5D%7D&cause=NightlyComplete_alpha&delay=5400&token=e90d7205a34d9304e38263657c9710c2: org.apache.commons.httpclient.HttpException: Session contains no certificates - Untrusted10/04/20 10:58:44 (224) Worker-Expedited:MIDWorker-9619b95fdbaf5410bc2e9b3c8a961968 Enqueuing: /glide/mid-pod/work/monitors/ECCSender/output_1/ecc_queue.9619b95fdbaf5410bc2e9b3c8a961968.xml10/04/20 10:58:44 (224) Worker-Expedited:MIDWorker-9619b95fdbaf5410bc2e9b3c8a961968 Worker completed: RESTProbe source: https://jenkins-alpha.lab3.service-now.com/job/triggers/job/nightly-build-completed/build time: 0:00:00.024 The error occurs when: The certificate presented by the target server is not signed by a well known root Certificate AuthorityTarget server is a self signed certificateTarget server is not hosting any certificateThe target you are connecting to has an invalid / untrusted certificate Solution Verify why the certificate presented by the target server is untrusted or suspicious. Access the URL on a browser and analyze the certificate. Ensure that the certificate is signed by a trusted certificate authority. For more information about inspecting certificates, see MID Server shows certificate chain errors with self-signed cert [KB0864241]. For additional information about MID Servers and certificates, see MID Servers and Certificates [KB0863673]. Workaround UPDATED Alternative workaround: If your instance is using a certificate other than the defaults (such as "*.servicenow.com" seen below), you can add a new record to the Certificate Check Policies table with the name of that new end certificate. Then, assuming the cert is uploaded to the MID keystore, the MID will check for that cert when connecting to the instance and should be able to pass the checks Note: This workaround disables all TLS security checks and is not recommended. On the instance, Navigate to MID Server > MID Security Policy, set the certificate check, hostname check, and revocation check to false for the appropriate policy. (Make sure Active field is true)In most cases you only need to set above for *.servicenow.com policy. Add the following to the config.xml on the MID Server: <parameter name="mid.ssl.bootstrap.default.check_cert_chain" value="false"/><parameter name="mid.ssl.bootstrap.default.check_cert_hostname" value="false"/><parameter name="mid.ssl.bootstrap.default.check_cert_revocation" value="false"/> Regulated and Self-Hosted instances If your instance name does not contain 'servicenow', or you are self-hosted, then also add this parameter to the MID Server config.xml. Replace the value with your FQDN of your instance name. This is also valid for instances with the 'servicenowservices.com' domain experiencing the issue noted above. <parameter name="mid.ssl.bootstrap.default.target_endpoint" value="FQDN_OF_THE_INSTANCE"/> Note: DO NOT include https:// or http:// and trailing '/' in the value column. The following is a correctly formatted example: <parameter name="mid.ssl.bootstrap.default.target_endpoint" value="kennytan.mycompany.com"/>