Elasticsearch Kibana连接JiraSM数据中心版SSL错误配置咨询

对接Jira Service Management数据中心版触发的SSL报错如下：

Error:
Action][Jira]: Unable to get capabilities. Error: write EPROTO 140447345760192:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../deps/openssl/openssl/ssl/record/ssl3_record.c:332: . Reason: unknown: errorResponse was null

ssl3_get_record:wrong version number不属于证书过期、证书不信任类错误，本质是Kibana发起HTTPS握手时，对端返回的内容不符合TLS报文格式，按以下要求完成SSL相关配置即可解决，满足创建事件工单的对接需求。

• 核对连接协议与端口匹配关系
  90%以上的同类型报错都是协议、端口不匹配导致：用HTTPS协议访问了Jira的明文HTTP端口，对端返回的HTTP明文报文会被OpenSSL识别为非法TLS内容。
  • 直连Jira服务场景：Jira默认明文HTTP端口为8080，对应连接器地址需写为http://<jira域名/IP>:8080；如果Jira配置了Tomcat原生SSL，默认HTTPS端口为8443，对应连接器地址写为https://<jira域名/IP>:8443
  • 前置反向代理场景：如果Jira前部署了Nginx/Apache做SSL卸载，代理默认HTTPS端口为443，对应连接器地址写为https://<jira域名>，不要误填代理后端连通Jira的8080明文端口
• 对齐两端TLS支持版本
  新版Elasticsearch、Kibana内置的OpenSSL默认仅支持TLS1.2及以上版本，旧版本JiraSM DC内置Tomcat可能默认未开启高版本TLS协议：
  • 直连Jira场景：修改Jira安装目录下conf/server.xml中的HTTPS Connector配置项，显式开启TLS1.2、TLS1.3支持，禁用SSLv3、TLS1.0、TLS1.1等旧版不安全协议，修改完成后重启Jira服务生效
  • 前置代理场景：在反向代理的SSL配置中增加TLS1.2、TLS1.3支持，移除旧版协议配置，重载代理服务配置生效
• 配置链路SSL拦截规则
  如果Kibana到JiraSM DC之间部署了企业防火墙、WAF、上网行为管理设备并开启了SSL解密，需完成两项配置：
  • 将JiraSM的访问地址加入设备SSL解密白名单，避免设备拦截请求后返回HTTP明文的认证、拦截页面，触发TLS格式错误
  • 如果设备要求双向SSL认证，在Kibana侧的Jira连接器配置中上传对应的客户端证书，同时将设备的根CA证书导入Kibana节点的系统信任库
• 补全证书信任链
  如果JiraSM DC使用自签名证书、企业内部CA签发的证书，需将完整证书链（根CA证书+中间CA证书，不要只导入站点本身的叶子证书）导入Kibana节点的系统信任库，或者Kibana配置中指定的Jira连接器专用信任库，避免证书校验阻断连接

• 先在Kibana部署节点执行命令做前置校验：curl -v https://<JiraSM实际访问地址>/rest/api/2/serverInfo
  • 如果curl返回和Kibana内一致的wrong version number报错，说明问题出在端口、协议或中间链路拦截，和Kibana本身配置无关
  • 如果curl返回证书不信任报错，重新导入完整证书链即可
  • 如果curl能正常返回Jira服务信息的JSON内容，说明链路SSL配置正常，回到Kibana侧重试连接即可
• 连接测试通过后，给连接器使用的Jira账号分配对应服务项目的工单创建权限，即可正常触发JiraSM事件工单创建流程

内容的提问来源于stack exchange，提问作者DevopsDevelop