Skip to content

Commit 68f2e3c

Browse files
authored
security: add steps to validate TLS between components (#21811)
1 parent 9276cf6 commit 68f2e3c

File tree

1 file changed

+35
-1
lines changed

1 file changed

+35
-1
lines changed

enable-tls-between-components.md

Lines changed: 35 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -173,7 +173,7 @@ To verify the caller's identity for a component, you need to mark the certificat
173173
> **Note:**
174174
>
175175
> - Starting from v8.4.0, the PD configuration item `cert-allowed-cn` supports multiple values. You can configure multiple `Common Name` in the `cluster-verify-cn` configuration item for TiDB and in the `cert-allowed-cn` configuration item for other components as needed. Note that TiUP uses a separate identifier when querying component status. For example, if the cluster name is `test`, TiUP uses `test-client` as the `Common Name`.
176-
> - For v8.3.0 and earlier versions, the PD configuration item `cert-allowed-cn` can only be set to a single value. Therefore, the `Common Name` of all authentication objects must be set to the same value. For related configuration examples, see [v8.3.0 documentation](https://docs.pingcap.com/tidb/v8.3/enable-tls-between-components).
176+
> - For v8.3.0 and earlier versions, the PD configuration item `cert-allowed-cn` can only be set to a single value. Therefore, the `Common Name` of all authentication objects must be set to the same value. For related configuration examples, see [v8.3.0 documentation](https://docs-archive.pingcap.com/tidb/v8.3/enable-tls-between-components/).
177177

178178
- TiDB
179179

@@ -228,6 +228,40 @@ To verify the caller's identity for a component, you need to mark the certificat
228228
cert-allowed-cn = ["tiproxy", "tidb", "test-client", "prometheus"]
229229
```
230230

231+
## Validate TLS between TiDB components
232+
233+
After configuring TLS for communication between TiDB components, you can use the following commands to verify that TLS has been successfully enabled. These commands print the certificate and TLS handshake details for each component.
234+
235+
- TiDB
236+
237+
```sh
238+
openssl s_client -connect <tidb_host>:10080 -cert /path/to/client.pem -key /path/to/client-key.pem -CAfile ./ca.crt < /dev/null
239+
```
240+
241+
- PD
242+
243+
```sh
244+
openssl s_client -connect <pd_host>:2379 -cert /path/to/client.pem -key /path/to/client-key.pem -CAfile ./ca.crt < /dev/null
245+
```
246+
247+
- TiKV
248+
249+
```sh
250+
openssl s_client -connect <tikv_host>:20160 -cert /path/to/client.pem -key /path/to/client-key.pem -CAfile ./ca.crt < /dev/null
251+
```
252+
253+
- TiFlash (New in v4.0.5)
254+
255+
```sh
256+
openssl s_client -connect <tiflash_host>:<tiflash_port> -cert /path/to/client.pem -key /path/to/client-key.pem -CAfile ./ca.crt < /dev/null
257+
```
258+
259+
- TiProxy
260+
261+
```sh
262+
openssl s_client -connect <tiproxy_host>:3080 -cert /path/to/client.pem -key /path/to/client-key.pem -CAfile ./ca.crt < /dev/null
263+
```
264+
231265
## Reload certificates
232266

233267
- If your TiDB cluster is deployed in a local data center, to reload the certificates and keys, TiDB, PD, TiKV, TiFlash, TiCDC, TiProxy, and all kinds of clients reread the current certificates and key files each time a new connection is created, without restarting the TiDB cluster.

0 commit comments

Comments
 (0)