前言在 Kubernetes 日志平台中Kibana 无法登录是一个比较常见但又容易误判的问题。很多时候表面现象看起来像是账号密码错误实际上问题可能出在 Kibana 与 Elasticsearch 之间的 HTTPS 证书链上。这次故障的核心问题就是Elasticsearch 证书过期导致 Kibana 无法完成 TLS 校验最终表现为平台登录失败。本文记录一次完整的排查与修复过程供后续类似问题参考。一、环境说明本次环境部署在 Kuberneteslogging命名空间主要组件包括ElasticsearchKibanaFilebeat资源类型如下StatefulSet/elasticsearch-masterDeployment/kibana-kibanaDaemonSet/filebeat-filebeat这说明当前环境属于自建 / Helm StatefulSet 部署模式而不是 ECK Operator 托管模式。这一区别非常重要因为自建模式下证书不会自动轮换需要手工维护。二、问题现象现场故障表现如下Kibana 页面可以打开但输入账号密码后无法正常登录Elasticsearch、Kibana、Filebeat 的 Pod 基本都在运行Kibana 日志中持续出现以下报错certificate has expired unable to verify the first certificate从现象上看很容易误以为是用户名密码错误Elasticsearch 认证异常Kibana 自身故障但实际上这类报错已经明确指向了TLS 证书校验失败。三、问题分析1. 为什么 Kibana 无法登录Kibana 的登录认证并不是完全独立完成的。用户在页面输入账号密码后Kibana 需要调用 Elasticsearch 进行认证。如果 Kibana 与 Elasticsearch 之间的 HTTPS 连接存在问题比如证书过期CA 不受信任证书链不完整那么认证请求在真正校验账号密码之前就已经失败了。也就是说这次“无法登录”并不是典型的账号问题而是Kibana 无法通过 HTTPS 正常连接 Elasticsearch。2. 证书是否真的过期为了确认是不是证书问题首先查看 Elasticsearch 当前实际加载的证书curl -k -u elastic:你的密码 https://10.233.52.179:9200/_ssl/certificates?pretty返回结果显示当前加载的以下证书都已过期/usr/share/elasticsearch/config/certs/ca.crt/usr/share/elasticsearch/config/certs/tls.crt这一步基本可以直接定性Elasticsearch 当前挂载的 CA 证书和服务端证书都已过期。3. 证书来自哪里继续查看 Elasticsearch 的 StatefulSet 配置kubectl -n logging get sts elasticsearch-master -o yaml | egrep -A5 -B2 secretName:|mountPath:|xpack.security|ssl可以确认证书挂载目录为/usr/share/elasticsearch/config/certs使用的 Secret 为elasticsearch-master-certsHTTP 和 Transport 层都使用该 Secret 中的ca.crttls.crttls.key这说明问题已经非常明确本次故障的根因就是elasticsearch-master-certs这套证书已过期。四、解决思路由于本次不只是服务端证书tls.crt过期连签发它的ca.crt也已经过期因此不再适合继续沿用旧 CA。正确的处理方式是重新生成新的 CA使用新的 CA 重新签发 Elasticsearch 证书更新 Kubernetes Secret重启 Elasticsearch重启 Kibana使其重新加载新的 CA 信任链五、解决过程1. 确认资源状态先确认环境中的组件状态kubectl get all -n logging确认当前环境为自建 StatefulSet/Deployment 模式而非 ECK。2. 确认 Elasticsearch 当前证书已过期curl -k -u elastic:你的密码 https://10.233.52.179:9200/_ssl/certificates?pretty确认ca.crt已过期tls.crt已过期3. 确认证书 Secret 来源kubectl -n logging get sts elasticsearch-master -o yaml | egrep -A5 -B2 secretName:|mountPath:|xpack.security|ssl确认 Elasticsearch 使用的证书 Secret 为elasticsearch-master-certs4. 在 Elasticsearch Pod 中生成新证书进入 Elasticsearch Podkubectl -n logging exec -it elasticsearch-master-0 -- bash创建工作目录mkdir -p /tmp/es-cert-renew cd /tmp/es-cert-renew创建实例配置文件cat instances.yml EOF instances: - name: elasticsearch-master dns: - elasticsearch-master - elasticsearch-master.logging - elasticsearch-master.logging.svc - elasticsearch-master.logging.svc.cluster.local - elasticsearch-master-0 - elasticsearch-master-0.elasticsearch-master-headless - elasticsearch-master-0.elasticsearch-master-headless.logging - elasticsearch-master-0.elasticsearch-master-headless.logging.svc - elasticsearch-master-0.elasticsearch-master-headless.logging.svc.cluster.local ip: - 10.233.52.179 EOF生成新的 CA/usr/share/elasticsearch/bin/elasticsearch-certutil ca --pem --days 1095 --out /tmp/es-cert-renew/ca.zip unzip -o /tmp/es-cert-renew/ca.zip -d /tmp/es-cert-renew/ca使用新 CA 生成 Elasticsearch 证书/usr/share/elasticsearch/bin/elasticsearch-certutil cert --pem \ --ca-cert /tmp/es-cert-renew/ca/ca/ca.crt \ --ca-key /tmp/es-cert-renew/ca/ca/ca.key \ --days 1095 \ --in /tmp/es-cert-renew/instances.yml \ --out /tmp/es-cert-renew/es.zip unzip -o /tmp/es-cert-renew/es.zip -d /tmp/es-cert-renew/es find /tmp/es-cert-renew -type f | sort5. 导出新证书到宿主机mkdir -p /root/es-cert-renew-20260415 cd /root/es-cert-renew-20260415 kubectl -n logging exec elasticsearch-master-0 -- cat /tmp/es-cert-renew/ca/ca/ca.crt ca.crt kubectl -n logging exec elasticsearch-master-0 -- cat /tmp/es-cert-renew/es/elasticsearch-master/elasticsearch-master.crt tls.crt kubectl -n logging exec elasticsearch-master-0 -- cat /tmp/es-cert-renew/es/elasticsearch-master/elasticsearch-master.key tls.key检查新证书openssl x509 -in ca.crt -noout -dates -subject -issuer openssl x509 -in tls.crt -noout -dates -subject -issuer6. 备份并更新 Elasticsearch Secret先备份原有 Secretkubectl -n logging get secret elasticsearch-master-certs -o yaml /root/elasticsearch-master-certs.bak.yaml然后更新 Secretkubectl -n logging create secret generic elasticsearch-master-certs \ --from-fileca.crtca.crt \ --from-filetls.crttls.crt \ --from-filetls.keytls.key \ --dry-runclient -o yaml | kubectl apply -f -7. 重启 Elasticsearchkubectl -n logging rollout restart statefulset/elasticsearch-master kubectl -n logging rollout status statefulset/elasticsearch-master kubectl -n logging get pod -n logging -w重启后Elasticsearch 一度出现Running 0/1但继续查看日志后发现节点已正常启动已完成主节点选举9200/9300 已正常监听索引已恢复Elasticsearch 已进入started状态说明证书更新已经成功只是 readiness probe 在等待集群状态恢复。8. 再次验证 Elasticsearch 新证书是否生效curl -k -u elastic:你的密码 https://10.233.52.179:9200/_ssl/certificates?pretty确认新证书的有效期已经更新。9. 检查 Kibana 的 CA 配置查看 Kibana Deploymentkubectl -n logging get deploy kibana-kibana -o yaml | egrep -A8 -B3 elasticsearch.ssl|ELASTICSEARCH|certificateAuthorities|verificationMode|secretName|mountPath确认 Kibana 已配置ELASTICSEARCH_HOSTShttps://elasticsearch-master:9200ELASTICSEARCH_SSL_CERTIFICATEAUTHORITIES/usr/share/kibana/config/certs/ca.crt并且挂载的 Secret 也是elasticsearch-master-certs说明 Kibana 的证书信任路径本身没有问题。10. 重启 Kibana虽然 Secret 已经更新但 Kibana 进程仍可能继续持有旧的 TLS 信任状态因此需要重启 Kibanakubectl -n logging rollout restart deployment/kibana-kibana kubectl -n logging rollout status deployment/kibana-kibana kubectl -n logging get pod -n logging -w11. 验证 Kibana 日志和登录情况查看 Kibana 最新日志kubectl -n logging logs deploy/kibana-kibana --tail200 | egrep certificate|x509|security_exception|unable to verify|No living connections|expired|SSL|tls确认以下错误已消失certificate has expired unable to verify the first certificate随后再次访问 Kibana 页面确认已恢复正常登录。六、处理结果最终结果如下Elasticsearch 新证书已成功生效Kibana 已重新加载新的 CA 证书Kibana 不再报证书校验错误平台恢复正常登录七、经验总结这次问题有几个典型经验1. 自建 Elasticsearch 证书不会自动续期只要不是 ECK就必须自己维护证书生命周期。2. Kibana 登录失败不一定是账号问题出现certificate、x509、unable to verify时应优先排查 TLS 证书链。3. 更新 ES 证书后Kibana 也需要同步处理即使 Kibana 配置没问题也需要重启以重新加载新的 CA。4. 建议建立证书到期告警至少应对以下证书设置提前预警Elasticsearch HTTP 证书Elasticsearch CA 证书Kibana 对外证书Ingress / 代理层证书结语这次故障的本质并不复杂但排查过程中很容易被“登录失败”这个表象误导。真正的问题并不是账号本身而是Kibana 与 Elasticsearch 之间的 HTTPS 信任链失效。遇到类似问题时建议优先确认三件事Elasticsearch 当前实际加载的证书是否过期Kibana 是否信任当前 CA证书更新后相关组件是否已重启并重新加载配置把这三步走清楚问题基本都能快速收敛。