gpt4 book ai didi

java - 几分钟后,为什么Spring Boot应用程序和Consul之间的SSL连接会失败?

转载 作者:行者123 更新时间:2023-12-01 09:39:27 24 4
gpt4 key购买 nike

我正在使用新版本的Ubuntu,Consul和Spring Boot升级环境。乍一看,一切似乎都很好。该应用程序连接到Consul,请求其配置并启动。几分钟后,出现故障,此消息大约每2秒重复一次:

com.ecwid.consul.transport.TransportException: javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
at com.ecwid.consul.transport.AbstractHttpTransport.executeRequest(AbstractHttpTransport.java:77)
at com.ecwid.consul.transport.AbstractHttpTransport.makeGetRequest(AbstractHttpTransport.java:34)
at com.ecwid.consul.v1.ConsulRawClient.makeGetRequest(ConsulRawClient.java:128)
at com.ecwid.consul.v1.catalog.CatalogConsulClient.getCatalogServices(CatalogConsulClient.java:120)
at com.ecwid.consul.v1.ConsulClient.getCatalogServices(ConsulClient.java:372)
at org.springframework.cloud.consul.discovery.ConsulCatalogWatch.catalogServicesWatch(ConsulCatalogWatch.java:129)
at org.springframework.scheduling.support.DelegatingErrorHandlingRunnable.run(DelegatingErrorHandlingRunnable.java:54)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
at java.base/sun.security.ssl.SSLSocketImpl.handleEOF(SSLSocketImpl.java:1313)
at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1055)
at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:395)
at org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:394)
at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:353)
at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:134)
at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:353)
at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:380)

我追踪到该消息每2秒显示一次,以检查应用程序的运行状况。错误首次发生后,将在以后的每次运行状况检查中继续发生。通过关闭运行状况检查并重新启动可以确认这一点。当达到领事数据上的TTL时,这将导致错误仅发生一次。

这就是我对问题的理解的终点。我试图将其追溯到几件事,但是这些都没有导致解决方案:
  • 检查证书-使用的证书由保险柜生成,由中间证书签名,由自签名根证书签名。然后将这些与 key 一起放入pkcs12捆绑软件中,并提供给应用程序。这适用于所有TLS连接,也适用于CLI工具和curl。这似乎是一个死胡同。
  • 网络连接-由于连接被重置,我试图查看是否是由于防火墙或安全组问题引起的。但是,相关的端口(8501)对TCP和UDP流量都是开放的,并且所有带有nc的手动测试均显示该端口可访问。
  • IPv6错误-在某处,我发现一个帖子说这可能是由于IPv6的错误所致。我尝试关闭计算机上的IPv6,重新启动所有内容,然后重试。没有运气,仍然是同样的错误。
  • Consul的版本-我尝试在我们的旧环境中运行该应用程序,在该环境中Consul 1.2.3正在运行,并且那里的错误没有出现。我仍在尝试确定是否有特定的Consul版本开始出现此问题,但尚未找到它。
  • TLS错误-在Consul 1.2.3和1.7.2之间,对Consul的TLS支持以及底层的Go TLS实现进行了一些更改。在使用Consul 1.4.0进行测试时发现这一点,后者提供了稍微不同的TLS错误。互联网上的一些建议是,Go和OpenJDK之间的实现存在冲突。我尝试强制Java应用程序使用TLS 1.2,但是再次失败了。
  • 握手调试-基于注释的提示,我使用-Djavax.net.debug=ssl:handshake来了解握手过程中发生的情况。在最初的几分钟内,产生的额外输出显示了我对正常握手的感觉。一旦出现问题,握手的输出就在带有“远程主机终止握手”的“生产的客户端Hello消息”之后立即停止。我无法在此连接的另一端执行相同的操作。 Consul是一个Golang应用程序。如果有人知道如何为Golan应用程序获取相同的调试信息,请提出建议。

  • 我希望有人对如何找到此问题的原因有所了解,或者更好的办法是找到解决方案。

    最佳答案

    经过更多的挖掘和尝试其他形式的事情。我发现使用GraalVM会产生不同的但更具描述性的错误。尝试连接到Consul应用程序时,它立即终止,并显示以下消息:

    Caused by: javax.net.ssl.SSLHandshakeException: extension (5) should not be presented in certificate_request
    at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
    at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
    at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:307)
    at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:263)
    at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:254)
    at java.base/sun.security.ssl.SSLExtensions.<init>(SSLExtensions.java:90)
    at java.base/sun.security.ssl.CertificateRequest$T13CertificateRequestMessage.<init>(CertificateRequest.java:818)
    at java.base/sun.security.ssl.CertificateRequest$T13CertificateRequestConsumer.consume(CertificateRequest.java:922)
    at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
    at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443)
    at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:421)
    at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:177)
    at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
    at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1151)
    at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1062)
    at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
    at org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:394)
    at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:353)
    at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:134)
    at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:353)
    at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:380)
    at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
    at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
    at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
    at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
    at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
    at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:71)
    at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:220)
    at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:164)
    at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:139)
    at com.ecwid.consul.transport.AbstractHttpTransport.executeRequest(AbstractHttpTransport.java:61)

    然后,这导致我在Golang GitHub页面上遇到了一个问题: https://github.com/golang/go/issues/35722。它详细介绍了来自不同人士的类似问题,但细节总是稍有不同。在该线程中,提到了Go和Java之间的TLS 1.3实现之间的差异。 OpenJDK维护人员也加入其中,并引用了此问题: https://bugs.openjdk.java.net/browse/JDK-8236039

    它已经修复并关闭,但是在我的任何常规二进制发行版中都没有。我将尝试检查该版本是否确实解决了该问题。但是,有一种解决方法,可以在Java中禁用TLS1.2。您可以通过在启动参数中添加 -Djdk.tls.client.protocols=TLSv1.2来实现。

    关于java - 几分钟后,为什么Spring Boot应用程序和Consul之间的SSL连接会失败?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/61813667/

    24 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com