We upgraded an on-premises Splunk Enterprise Security search-head cluster from ES 8.2.x to ES 8.5.1. Before the upgrade, the ES/SOAR integration was working. Since the upgrade: ES can still send information to SOAR. When SOAR tries to call back to ES or run an action through the Mission Control SOAR proxy, it sometimes fails with: HTTPSConnectionPool(host='<es-vip-fqdn>', port=8089): Max retries exceeded with url: /servicesNS/-/missioncontrol/v1/internal/soar_proxy Caused by SSLError( SSLCertVerificationError( '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate' )) The SOAR connection uses an ES VIP on port 8089. Testing that endpoint with: openssl s_client \ -connect <es-vip-fqdn>:8089 \ -servername <es-vip-fqdn> \ -showcerts </dev/null shows a wildcard certificate with the correct SAN. However, Certificate chain contains only certificate 0, and OpenSSL reports: verify error:num=20:unable to get local issuer certificate verify error:num=21:unable to verify the first certificate Verify return code: 21 (unable to verify the first certificate) The server certificate is issued by a public intermediate CA, but the endpoint appears not to be sending that intermediate certificate. The direct ES search heads use Splunk’s internal SplunkCommonCA certificate. The wildcard certificate is therefore likely being presented by the load balancer/VIP. The confusing part is that some SOAR-to-ES requests succeed. In splunkd_access.log, we see the SOAR source address and integration account receiving HTTP 200 responses: <soar-ip> - soar_proxy_user [...] "GET /servicesNS/-/missioncontrol/v1/internal/soar_proxy?... HTTP/1.1" 200 ... We also see successful JWT validation for soar_proxy_user. Other actions reportedly fail with the certificate error and leave no ES access-log entry, presumably because TLS fails before Splunk receives HTTP. Pairing state currently reports Pairing Success, and internal search-head-cluster REST calls return HTTP 200. Has anyone seen this after an ES 8.5.1 upgrade? Specific questions: Did ES 8.5.1 change SOAR/Mission Control certificate verification? Could the upgrade have refreshed the pairing and caused SOAR to begin using the VIP on port 8089? Can different SOAR workers use different certificate stores? Could an inconsistent certificate chain across load-balancer nodes explain the mix of successful and failed requests? Is configuring the VIP to serve the server certificate plus its intermediate CA the expected correction? Is re-pairing required after correcting the certificate chain? We are avoiding disabling TLS verification and would prefer to correct the certificate chain or integration configuration properly. Splunk Enterprise Security  Splunk App for SOAR  ... View more