- android - 多次调用 OnPrimaryClipChangedListener
- android - 无法更新 RecyclerView 中的 TextView 字段
- android.database.CursorIndexOutOfBoundsException : Index 0 requested, 光标大小为 0
- android - 使用 AppCompat 时,我们是否需要明确指定其 UI 组件(Spinner、EditText)颜色
我想将 TLS/SSL 添加到我的 kafka 设置中。首先,我浏览了主网站上的 kafka SSL 文档。我做了以下事情:
1) 将签名的证书导入 keystore
2) 导入根CA
3) 使用keytool验证keystore和trust store密码是否正确。
4) 启动zookeeper和kafka。
5) 从 server.log 文件确认以下内容:
Registered broker 0 at path /brokers/ids/0 with addresses:
EndPoint(localhost,9092,ListenerName(PLAINTEXT),PLAINTEXT),EndPoint(localhost,9093,ListenerName(SSL),SSL) (kafka.utils.ZkUtils)
我的 server.properties 文件中的 listeners 和 advertised.listeners 设置如下:
PLAINTEXT://localhost:9092,SSL://localhost:9093
我还启用了自动创建主题。当我这样做时:
kafka-console-producer.bat --broker-list localhost:9093 --topic test_ssl --producer.config ....\config\producer.properties
我收到以下错误:
[2017-08-04 16:28:15,265] WARN Error while fetching metadata with correlation id 0 : {test_ssl=LEADER_NOT_AVAILABLE} (org.apache.kafka.clients.NetworkClient)
[2017-08-04 16:28:15,372] WARN Error while fetching metadata with correlation id 1 : {test_ssl=LEADER_NOT_AVAILABLE} (org.apache.kafka.clients.NetworkClient)
[2017-08-04 16:28:15,474] WARN Error while fetching metadata with correlation id 2 : {test_ssl=LEADER_NOT_AVAILABLE} (org.apache.kafka.clients.NetworkClient)
[2017-08-04 16:28:20,302] WARN Error while fetching metadata with correlation id 3 : {test_ssl=LEADER_NOT_AVAILABLE} (org.apache.kafka.clients.NetworkClient)
[2017-08-04 16:28:20,406] WARN Error while fetching metadata with correlation id 4 : {test_ssl=LEADER_NOT_AVAILABLE} (org.apache.kafka.clients.NetworkClient)
[2017-08-04 16:28:20,512] WARN Error while fetching metadata with correlation id 5 : {test_ssl=LEADER_NOT_AVAILABLE} (org.apache.kafka.clients.NetworkClient)
我尝试使用 openssl 打印出 SSL 通信数据
openssl s_client -connect localhost:9093 -debug -tls1 // default kafka broker configs have tlsv1 included
我得到以下信息:
Certificate chain
0 s:/C=GB/ST=Unknown/L=London/O=SOAPYSUDS/OU=SOAPYSUDS/CN=M. Manna
i:/C=GB/ST=Some-State/L=London/O=SOAPYSUDS/OU=SOAPYSUDS/CN=localhost/emailAddress=xyz@xyz.com
1 s:/C=GB/ST=Some-State/L=London/O=SOAPYSUDS/OU=SOAPYSUDS/CN=localhost/emailAddress=xyz@xyz.com
i:/C=GB/ST=Some-State/L=London/O=SOAPYSUDS/OU=SOAPYSUDS/CN=localhost/emailAddress=xyz@xyz.com
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDfDCCAmQCCQDJKjhOy8KBWjANBgkqhkiG9w0BAQsFADCBlTELMAkGA1UEBhMC
R0IxEzARBgNVBAgMClNvbWUtU3RhdGUxDzANBgNVBAcMBkxvbmRvbjEMMAoGA1UE
CgwDU0FQMRcwFQYDVQQLDA5TQVAgRmllbGRnbGFzczESMBAGA1UEAwwJbG9jYWxo
b3N0MSUwIwYJKoZIhvcNAQkBFhZtb2hhbW1lZC5tYW5uYUBzYXAuY29tMB4XDTE3
MDgwNzA5MDU0MFoXDTE5MDgwNzA5MDU0MFowajELMAkGA1UEBhMCR0IxEDAOBgNV
BAgTB1Vua25vd24xDzANBgNVBAcTBkxvbmRvbjEMMAoGA1UEChMDU0FQMRcwFQYD
VQQLEw5TQVAgRmllbGRnbGFzczERMA8GA1UEAxMITS4gTWFubmEwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3+sGslb3XocPzigNOmwi9DRE7U6Gos+k1
ADWCS1UGDXPRuS9JocCc2oZ2GJxwipDpF+xRGmeAXIo77S/4GXFjs+DG1R8kojXn
bth3QRTsI6XAMuWOX3AHd4ob0/WSWsPLkGRggCyqU7qwvhuD+MzXB2Q0isRgab/c
lQl6Bj6ETaYTSY8Q2YjCR0ggL4qpYwO62fUexTB5aJx8JMpEbi0V3NZX/2xpic2m
27NW95j7oxi55Q36sYQNpFxfp9pIft6n3+RYTWIQ0bDV5O4W0TGAGPMDkH+t1K9x
ZZEoLik0aOfHw9sp96LkU5oZGGeWEGt6CmWHZQDiBSAyuTe6IjTpAgMBAAEwDQYJ
KoZIhvcNAQELBQADggEBAC4m+Lpl6pH45VGGvpaolL6PnL5TGcd7FL39C6DxL7Cl
MftcLuG6Egka+eJr/tg+6pdOFfpQjrkeDpeiRIABcLu/VrK99Te7c946QWc8QupC
G/VSQRIHOW6ReBsFf2/wrwT8MWDq2I2GAZSuZ9eTGWggQEwyem6y7C4ujtrcpixq
XwkeE2AU/91O2LlRrP/gW3hwEgD3VruMFhnm/3tTc7ZeLhJPSIE8EMhCk3+j2tgI
ta9J6NZClMxRLgBe1cOH2ru8eGsJtDnT2J+h0m/Ra3t9pD70Amoo84ytE3Iyui8i
kL2gg278c7PF5qosjPkp5sjjvWFypk8iYHTgTidbRCg=
-----END CERTIFICATE-----
subject=/C=GB/ST=Unknown/L=London/O=SOAPYSUDS/OU=SOAPYSUDS/CN=M. Manna
issuer=/C=GB/ST=Some-State/L=London/O=SOAPYSUDS/OU=SOAPYSUDS/CN=localhost/emailAddress=xyz@xyz.com
---
Acceptable client certificate CA names
/C=GB/ST=Some-State/L=London/O=SOAPYSUDS/OU=SOAPYSUDS/CN=localhost/emailAddress=xyz@xyz.com
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 5048 bytes and written 285 bytes
Verification error: self signed certificate in certificate chain
---
New, TLSv1.0, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1
Cipher : ECDHE-RSA-AES256-SHA
Session-ID: 59884152B1D0B4716F30AC8E43BAC10EBBE92E6BD771AAAD31046035564F2B30
Session-ID-ctx:
Master-Key: 124F0A4796CCE67A696105F4F88798CFC31E76885DEDF3EB1F702EA565543462AB1CCC9B4E6D726BD7489C17ED77C744
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1502101842
Timeout : 7200 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
Extended master secret: no
---
即使上面的“自签名证书验证”有错误,我认为如果 CA 证书是自签名的,这很常见。可能是因为 SSL 握手已写入/读取数据,它才起作用。
我可以从 kafka-topics 命令(还有 server.log)确认主题“test_ssl”创建成功。我希望这不是因为这个下划线“_”。
如果存在握手问题,它会被记录在日志中(我认为,除非记录器已关闭),但看起来我的 SSL 配置已被正确接受。只是想知道我是否遗漏了一些我在这里无法完全发现的东西。
注意 - 我的 Zookeeper 没有使用任何 SSL/TLS。此外,因为我是在本地开始 TLS 测试,所以我现在使用的是通用信任库(jre/lib/security 中的 cacerts)。
-- 我的客户端 SSL 配置
advertised.listeners=SSL://localhost:9093
listeners=SSL://localhost:9093
security.protocol=SSL
ssl.truststore.location=$java_path/jre/lib/security/cacerts
ssl.truststore.password=changeit
ssl.keystore.location=/kafka_2.10-0.10.2.1/config/kafka_client.jks
ssl.keystore.password=test1234
ssl.key.password=test1234
-- 我的服务器 SSL 相关属性
security.inter.broker.protocol=SSL
ssl.keystore.location=/kafka_2.10-0.10.2.1/config/kafka_server.jks
ssl.keystore.password=test1234
ssl.key.password=test1234
ssl.truststore.location=$java_path/jre/lib/security/cacerts
ssl.truststore.password=changeit
ssl.endpoint.identification.algorithm=HTTPS
ssl.secure.random.implementation=SHA1PRNG
ssl.client.auth=required
启动后我的服务器日志的一部分(启用 SSL 调试):
Using SSLEngineImpl.
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
Using SSLEngineImpl.
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
kafka-network-thread-0-ListenerName(SSL)-SSL-0, fatal: engine already closed. Rethrowing javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack?
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
kafka-network-thread-0-ListenerName(SSL)-SSL-0, called closeOutbound()
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1
kafka-network-thread-0-ListenerName(SSL)-SSL-0, closeOutboundInternal()
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
[Raw write]: length = 7
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
0000Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
: 15Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1.1
03Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
03 00Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
02 02Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1.1
%% No cached client session
50*** ClientHello, TLSv1.2
我不确定我缺少什么配置才能让它正常工作。我认为我的证书导入顺序没有任何问题,因为我已经通过匹配说明确认了我的方法 here .
问候,
最佳答案
这只是一个配置 - 但我希望文档对此有稍微更长的解释 - 但仍然是我的错。
ssl.endpoint.identification.algorithm
我将其设置为 HTTPS - 这意味着我的客户将根据以下其中一项验证我的完全限定域名 FQDN:
1) 通用名称 (CN)
2) 主题备用名称 (SAN)
当我创建我的证书时,我出于礼貌添加了我的名字和姓氏,心想“这是我的名字和姓氏”。由于我的原始证书没有以下任何一项:
1) localhost
作为 CN
2) localhost
作为 DNS
客户端无法根据提供的证书的 SAN/CN 值验证代理的 FQDN。我相信这就是我在颁发新的自签名 SAN 证书(并将它们导入客户端信任库)后让它工作的原因。
关于ssl - 使用 TLS/SSL 实现后控制台生产者错误,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/45512063/
我在 Cloudflare 的域名服务器上有一个域名 example.com。该域指向我的专用服务器的 IP 地址,该服务器运行 CentOS/WHM/cPanel。该站点可访问 - 一切都很好。 我
我正在努力将 SSL 支持添加到我们现有的应用程序中,并已开始考虑向后兼容性。 与我读过的其他帖子不同的一个特殊情况是服务器可能不一定使用 SSL 代码更新。所以我将有一个 SSL 客户端连接到一个对
我有几个 https://*.rest-service.mydomain.com。随着服务数量的增加,我觉得管理 SSL 证书的成本很高。我为 *.mydomain.com 购买了通配符证书。 新添加
我的客户要求我在他的网站上做反向 ssl。但我是这个学期的新手。谁能帮我解决这个问题。 请描述或引用如何做。 最佳答案 查看 this wiki article . In the case of se
关闭。这个问题是opinion-based .它目前不接受答案。 想改进这个问题?更新问题,以便 editing this post 可以用事实和引用来回答它. 去年关闭。 Improve this
我连接到我的网络服务器上的存储库,但是当我尝试推送我的更改时,它显示:“错误 403:需要 ssl”,但在我的存储库设置中我已经激活了 ssl 选项。 有什么建议吗? 最佳答案 当您连接到存储库时,您
抱歉,如果这听起来像是转储问题,我已经阅读了很多关于 SSL 握手和 SSL 工作原理的文章和文档。我对一件事感到困惑,如果有人能澄清我就太好了。 我知道私钥要保密。但是我已经看到通过在请求中指定私钥
随着物联网越来越主流,越来越需要从硬件发送http请求。 一个主要问题是硬件微 Controller 无法发送 ssl 请求,但大多数服务器/网站/服务都在使用 ssl。 所以,问题是,有没有桥(一个
我有一个 ssl 页面,它还从非 ssl 站点下载头像。我能做些什么来隔离该内容,以便浏览器不会警告用户混合内容吗? 最佳答案 只是一个想法 - 或者: 尝试在头像网站上使用 ssl url,如有必要
我在 Digital Ocean droplet(使用 nginx)上设置了两个域。我已经在其中一个(domain1)中安装了一个 SSL 证书,并且那个证书一切正常。第二个域 (domain2) 不
我收到这个错误: Error frontend: 502 Bad gateway 99.110.244:443 2017/09/28 13:03:51 [error] 34080#34080: *10
关闭。这个问题不符合Stack Overflow guidelines .它目前不接受答案。 这个问题似乎与 help center 中定义的范围内的编程无关。 . 关闭 6 年前。 Improve
我遇到了一个问题,我正在构建一个 nginx 反向代理以定向到不同 url 路径上的多个微服务。 该系统完全基于 docker,因此开发和生产使用相同的环境。这在安装 SSL 时给我带来了问题,因为
所以我知道要求 SSL 证书和接受之间的根本区别,一个意味着您必须拥有 SSL 证书,另一个意味着您不需要。 在某个网页的 IIS 管理器中,我有以下设置: 我遇到的问题是,当我设置需要 SSL 证书
我今天才发现 .app 域名需要 SSL 证书。我购买它是为了将 DNS 重定向到已经设置了 SSL 证书的站点,所以我的问题是是否可以设置它? 我正在使用 Google Domains,在将合成临时
堆栈 : react ,NGINX 1.14.0,GUnicorn,Django 2.2.8,Python 3.6.9 错误 : 在浏览器:当 React 调用 Django API(当然是在请求头中
假设我在计算机上编辑主机文件以使 google.com 指向我的 VPS 服务器 IP,并且服务器具有通过 Apache 或 Nginx 配置的 google.com 的虚拟主机/服务器 block
我有一个场景,我正在处理用于 URL 路由的 IIS 网站配置。我已添加网站并在服务器上导入所需的证书。 我的情况是(我有多个网站 URL 和两个 SSL 证书 - 如下所示): qatest1.ab
我知道服务器发送的证书无法伪造(仍然存在 MD5 冲突,但成本高昂),但是伪造客户端又如何呢?在中间人攻击中:我们不能告诉服务器我们是合法客户端并从该服务器获取数据并对其进行操作,然后使用合法客户端公
我已通读相关问题,但无法完全找到我要查找的内容。我设置了一个名为“domain.com”的域,并创建了两个子域“client.domain.com”和“client-intern.domain.com
我是一名优秀的程序员,十分优秀!