Keycloak TLS 异常：读取时意外EOF，OpenShift集成Keycloak身份认证失败

看起来你在实验室环境搭建Keycloak并和OpenShift集成时，卡在了TLS连接这一步——从OpenShift日志里的connection reset by peer报错来看，这大概率是TLS握手失败或者网络层面的阻隔导致的。我给你整理几个实用的排查方向，你可以逐一验证：

1. 确认Keycloak的TLS证书是否被OpenShift信任 #

• 如果Keycloak用的是自签名证书，OpenShift默认不会信任它，这会直接导致TLS握手失败。你可以在OpenShift任意一个pod（比如openshift-authentication命名空间下的pod）里执行以下命令测试握手情况：

  openssl s_client -connect 10.10.25.199:443
  

  观察输出里有没有Verify return code: 18 (self signed certificate)这类证书验证失败的信息，如果有的话，需要把Keycloak的CA证书添加到OpenShift的信任存储中。
• 同时检查Keycloak的证书是否过期、域名和访问IP是否匹配（如果证书基于域名签发，但你用IP访问Keycloak，也会触发证书验证错误）。

2. 排查网络连通性问题 #

• 先确认OpenShift控制平面组件能访问到Keycloak的443端口：在openshift-authentication命名空间下的pod里，执行以下命令测试端口可达性：

  nc -zv 10.10.25.199 443
  

  如果显示Connection refused或者超时，说明网络层面有拦截，要检查防火墙、安全组或者OpenShift的网络策略是否阻断了流量。
• 也可以测试ping Keycloak的IP，确认网络路由是通的。

3. 检查Keycloak的TLS服务配置 #

• 确认Keycloak确实在监听443端口：登录到Keycloak所在机器，执行：

  ss -tulpn | grep 443
  

  确保看到Keycloak进程在监听该端口。
• 检查Keycloak的TLS协议配置，比如是否禁用了OpenShift支持的TLS版本（比如OpenShift默认支持TLS 1.2+，如果Keycloak只开启了TLS 1.0就会不兼容）。你可以在Keycloak的配置文件里查看相关参数，或者通过管理控制台验证。

4. 核对OpenShift的IDP配置细节 #

• 确认你在OpenShift里配置的Keycloak身份提供商URL是正确的，必须以https开头，且路径没有拼写错误。
• 如果用了自签证书，要确保在OpenShift的OAuth配置里指定了信任该证书：你可以通过编辑oauth.openshift.io/v1类型的cluster资源，在spec.idp对应的Keycloak配置里添加ca字段，引用包含Keycloak CA证书的secret。

另外，建议你同时查看Keycloak的日志，看看有没有收到OpenShift的连接请求，有没有TLS握手失败的具体报错——这能帮你快速定位是Keycloak这边拒绝了连接，还是OpenShift这边发起连接时出了问题。

备注：内容来源于stack exchange，提问作者Grant Curell