@Steffen：我会检查脚本部分。我刚刚注意到 wget 命令现在服务 url 无法建立 SSL 连接
[root@XXXX rpms]# wget https://testuser:testpwd.service-now.com/u_incident_interface.do
--2018-06-10 13:00:07-- https://srv_SOAPimporterNagios:password@rwe.service-now.com/u_incident_interface.do
Resolving rwestproxy-neurathdc.rwe.com... 10.88.253.20
Connecting to rwestproxy-neurathdc.rwe.com|10.88.253.20|:8080... connected.
Unable to establish SSL connection.
[root@XXXX rpms]#
你能就 SSL 连接问题提出建议吗？
TL;DR：服务器以普通流量而不是预期的 TLS 进行响应。其原因可能是对客户端的错误期望、错误配置或旧有缺陷的软件。
SSL 连接尝试失败错误：140770FC：SSL 例程：SSL23_GET_SERVER_HELLO：未知协议
如果另一台设备根本无法正确使用 SSL，则会发生类似unknown protocol或也SSL_ERROR_RX_RECORD_TOO_LONG 或wrong version number通常会发生的错误。这意味着客户端正在启动与 ClientHello 的 TLS 握手，而服务器正在使用与 SSL/TLS 完全不同的内容进行响应。客户端仍然会尝试将非 TLS 答案解释为 TLS，因此会抱怨一些奇怪的 TLS 版本或一些损坏的 TLS 记录。
如果您尝试使用 HTTPS 与普通 HTTP 服务器通信，通常会发生这种情况。这可能是因为服务器一开始从未配置为 HTTPS，人们错误地认为将 URL 从 更改http://为https://会神奇地使服务器 HTTPS 准备就绪。也可能是那个人访问了服务器上的错误端口，即纯 HTTP 端口而不是 HTTPS 端口。还有一些情况，由于服务器配置错误，只说普通的 HTTP 而配置看起来应该说 HTTPS——就像在这个问题中一样。或者可能是因为代理配置错误，即假设代理将被HTTPS访问即使对于这个问题中的HTTPS URL，它也可以通过普通 HTTP 访问。
如果服务器在切换到 TLS 之前需要一些初始纯数据，也会发生这种情况。例如，当使用代理连接到最终目标时。在 HTTP 代理的情况下，客户端需要首先发送一个普通的 HTTPCONNECT请求，从服务器读取普通的 HTTP 响应并检查是否成功，然后才能从 TLS 握手开始。例如，如果您使用旧版本的 LWP，就会发生这种情况，因为 6.00 和 6.06 之间对 HTTPS 的代理支持被破坏了。