在一個由三個Kafka服務器組成的集群中出現SSL錯誤，這些服務器通過SSL（僅）進行通信。 為什么會發生這種情況/我怎么才能解決這個問題呢？
server.properties
listeners=SSL://some_host_name.corp.com:9092
inter.broker.listener.name=SSL
ssl.keystore.location=/some/path/to/keystore.p12
ssl.keystore.password=***。
ssl.key.password=****
ssl.truststore.location=/some/path/to/server.truststore.jks
ssl.truststore.password=***。
ssl.enabled.protocols=TLSv1.2
ssl.client.auth=required
ssl.keystore.type=PKCS12
ssl.truststore.type=JKS
#listener.security.protocol.map=PLAINTEXT:PLAINTEXT，SSL:SSL，SASL_PLAINTEXT:SASL_PLAINTEXT，SASL_SSL:SASL_SSL
# Kafka運行時使用了-Djavax.net.debug=ssl
# 假設localhost的IP地址是1.2.3.4
18:31:29.479 [data-plan-kafka-socket-acceptor-ListenerName(SSL)-SSL-9092] DEBUG kafka.network.Acceptor - Accepted connection from /1.2.3.4:46732 on /1.2.3.4:9092 and assigned it to processor 1, sendBufferSize [actual|requested]: [212992|1048576] recvBufferSize [實際|要求]: [212992|1048576]
18:31:29.479 [data-plane-kafka-network-thread-1-ListenerName(SSL)-SSL-1] DEBUG kafka.network.Processor - Processor 1 listening to new connection from /1.2.3.4:46732
使用SSLEngineImpl。
允許不安全的重新協商：false
允許遺留的Hello資訊：true
是否初始握手：true
是否安全的重新協商：false
data-plane-kafka-network-thread-1-ListenerName(SSL)-SSL-1, fatal error: 80: problem unwrapping net record
javax.net.ssl.SSLException。未識別的SSL訊息，純文本連接？
data-plane-kafka-network-thread-1-ListenerName(SSL)-SSL-1, SEND TLSv1.2 ALERT: fatal, description = internal_error
data-plane-kafka-network-thread-1-ListenerName(SSL)-SSL-1, WRITE: TLSv1.2 Alert, length = 2
data-plane-kafka-network-thread-1-ListenerName(SSL)-SSL-1, called closeOutbound()
data-plane-kafka-network-thread-1-ListenerName(SSL)-SSL-1, closeOutboundInternal()
data-plane-kafka-network-thread-1-ListenerName(SSL)-SSL-1, called closeInbound()
data-plane-kafka-network-thread-1-ListenerName(SSL)-SSL-1, fatal: engine already closed. 重新拋出javax.net.ssl.SSLException。Inbound closed before receiving peer's close_notify: possible truncation attack?
18:31:29.481 [data-plane-kafka-network-thread-1-ListenerName(SSL)-SSL-1] DEBUG o.a.k.c.network.SslTransportLayer - [SslTransportLayer channelId=1.2.3.4:9092-1.2.3.4:46732-108 key=sun.nio.ch.SelectionKeyImpl@33a4cffe] SSLEngine.closeInBound()引發了一個例外。
javax.net.ssl.SSLException。在收到peer的close_notify之前就關閉了Inbound：可能是截斷攻擊？
at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) ~[na:1.8.0_181]
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666) ~[na:1.8.0_181]
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1634) ~[na:1.8.0_181]
at sun.security.ssl.SSLEngineImpl.closeInbound(SSLEngineImpl.java:1561) ~[na:1.8.0_181]
at org.apache.kafka.common.network.SslTransportLayer.handshakeFailure(SslTransportLayer.java:871) [kafka-lients-2.7.0.jar:na]
at org.apache.kafka.common.network.SslTransportLayer.maybeProcessHandshakeFailure(SslTransportLayer.java:909) [kafka-lients-2.7.0.jar:na] 。
at org.apache.kafka.common.network.SslTransportLayer.handshake(SslTransportLayer.java:295) [kafka-lients-2.7.0.jar:na]
at org.apache.kafka.common.network.KafkaChannel.prepare(KafkaChannel.java:173) [kafka-lients-2.7.0.jar:na]
at org.apache.kafka.common.network.Selector.pollSelectionKeys(Selector.java:543) [kafka-lients-2.7.0.jar:na]
at org.apache.kafka.common.network.Selector.poll(Selector.java:481) [kafka-lients-2.7.0.jar:na]
at kafka.network.Processor.poll(SocketServer.scala:923) [kafka_2.12-2.7.0.jar:na]
at kafka.network.Processor.run(SocketServer.scala:826) [kafka_2.12-2.7.0.jar:na]
at java.lang.Thread.run(Thread.java:748) [na:1.8.0_181]
18:31:29.481 [data-plane-kafka-network-thread-1-ListenerName(SSL)-SSL-1] INFO o.a.kafka.common.network.Selector - [SocketServer brokerId=1] Failed authentication with /1.2.3.4 (SSL handshake failed)
data-plane-kafka-network-thread-1-ListenerName(SSL)-SSL-1, called closeOutbound()
data-plane-kafka-network-thread-1-ListenerName(SSL)-SSL-1, closeOutboundInternal()
在另一個集群成員的日志中，認證成功了。那么，為什么它在不同的節點之間起作用，而不是從一個節點到它自己呢？
20:07:39.479 [data-plane-kafka-network-thread-3-ListenerName(SSL)-SSL-1] DEBUG o.a.k.c.network.SslTransportLayer - [SslTransportLayer channelId=1.2.3.6:9092-1.2.3.5:41182-0 key=sun.nio.ch.SelectionKeyImpl@69864b7d] SSL握手成功，peerHost '1.2.3.5' peerPort 41182 peerPrincipal '...' cipherSuite 'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384' 。
20:07:39.480 [data-plane-kafka-network-thread-3-ListenerName(SSL)-SSL-1] DEBUG o.a.kafka.common.network.Selector - [SocketServer brokerId=3] 成功認證了/1.2.3.5
uj5u.com熱心網友回復：
我已經通過將SSL監聽器從默認的9092埠移開來解決了這個問題。
這給我留下了一個不同的問題：如果我在 9092 埠只配置了一個帶有 SSL 的監聽器，那么為什么在同一埠會有任何 PLAINTEXT 活動？
上面顯示的錯誤是由于每個代理試圖在 9092 埠連接到自己，可能使用 PLAINTEXT，盡管我只配置了 SSL。
另外：下面的設定（1）和（2）之間有什么區別？
# (1) socket服務器監聽的地址。它將獲得從
# java.net.InetAddress.getCanonicalHostName() 如果沒有配置的話。
# 格式化。
# listeners = listener_name://host_name:port
# 舉例說明。
# listeners = PLAINTEXT://your.host.name:9092
#listeners=PLAINTEXT://:9092
listeners=SSL://$auto_host:9092
# (2) 套接字服務器監聽的埠
port=9092
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/317196.html
標籤：
上一篇：如何等待多個嵌套的承諾解決？