TiDB PD TLS setup with cert-manager — “tls: bad certificate” and handshake errors #66525
Replies: 4 comments
-
|
Original author: TiDB-AI-Assistant Troubleshooting TLS Certificate Issues in TiDB PD ComponentsTable of Contents
Overview of TiDB PD’s TLS RequirementsThe Placement Driver (PD) component in TiDB requires properly configured TLS certificates to ensure secure communication with other components in the TiDB cluster. When deployed in Kubernetes using TiDB Operator, PD needs certificates that:
PD uses TLS for:
Common Causes of TLS Certificate Validation FailuresWhen encountering “tls: bad certificate” errors in TiDB PD components, several issues might be at play: 1. Certificate Expiration
2. Missing or Incorrect SAN Entries
3. Certificate Chain Issues
4. Kubernetes Secret Management Problems
|
Beta Was this translation helpful? Give feedback.
-
|
Original author: Hazel
Hi @hamid May I know if you have configured certificates for both TiKV and TiDB? |
Beta Was this translation helpful? Give feedback.
-
|
Original author: hamid Hi @Hazel |
Beta Was this translation helpful? Give feedback.
-
|
Original author: Hazel Hi @hamid Just to confirm, have you enabled mTLS for all components? If not, we recommend doing so by following this guide: Enable TLS between TiDB Components |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Original author: hamid
Original time: 2025-06-03 07:31:33.716461
Original ID/Slug: 10498 / tidb-pd-tls-setup-with-cert-manager-tls-bad-certificate-and-handshake-errors
Hi guys,
I am deploying TiDB with TLS enabled for PD components in a Kubernetes cluster using cert-manager to generate certificates. However, PD logs show errors such as:
tls: bad certificate
tls: first record does not look like a TLS handshake
transport: authentication handshake failed: client certificate authentication failed
I am struggling to get the TLS certs properly validated between TiDB and PD, and my cluster is stuck with failed connections.
What I have done so far:
Created a Certificate resource with cert-manager to issue certificates for TiDB PD servers and clients.
Used cert-allowed-cn = [“tidb-server”] in PD config to specify allowed client CN.
Enable tls in cluster config
Configured SANs for the certificate to include relevant Kubernetes service DNS names.
Mounted certificates into PD and TiDB pods and configured their TLS options accordingly.
PD server TLS config snippet (in config file or Helm values):
[security]
ca-path = “/var/lib/tls/ca.crt”
cert-path = “/var/lib/tls/tidb-server.crt”
key-path = “/var/lib/tls/tidb-server.key”
Errors in PD logs:
[WARN] [config_logging.go:170] [“rejected connection on client endpoint”] [remote-addr=10.42.6.51:39266] [server-name=global-pd.tidb-cluster] [error=“remote error: tls: bad certificate”]
[WARN] [config_logging.go:170] [“rejected connection on client endpoint”] [remote-addr=10.42.6.37:37590] [server-name=] [error=“tls: first record does not look like a TLS handshake”]
[FATAL] [“run server failed”] [error=“transport: authentication handshake failed: client certificate authentication failed”]
Questions:
Am I correctly configuring SANs for the PD server certificates?
Is using “tidb-server” as commonName and cert-allowed-cn sufficient for client cert verification?
Could the errors mean that some clients connect without TLS? How can I identify and fix this?
What are the common pitfalls when setting up TLS with cert-manager for TiDB PD?
How to verify certs inside the pods properly?
Additional info:
Thanks in advance for your help!
Beta Was this translation helpful? Give feedback.
All reactions