@@ -43,8 +43,6 @@ This section describes how to issue certificates for the TiDB cluster using two
4343
44441 . Download ` cfssl ` and initialize the certificate issuer:
4545
46- {{< copyable "shell-regular" >}}
47-
4846 ``` shell
4947 mkdir -p ~ /bin
5048 curl -s -L -o ~ /bin/cfssl https://pkg.cfssl.org/R1.2/cfssl_linux-amd64
@@ -114,8 +112,6 @@ This section describes how to issue certificates for the TiDB cluster using two
114112
1151134. Generate CA by the configured option:
116114
117- {{< copyable " shell-regular" > }}
118-
119115 ` ` ` shell
120116 cfssl gencert -initca ca-csr.json | cfssljson -bare ca -
121117 ` ` `
@@ -124,8 +120,6 @@ This section describes how to issue certificates for the TiDB cluster using two
124120
125121 First, create the default ` server.json` file:
126122
127- {{< copyable " shell-regular" > }}
128-
129123 ` ` ` shell
130124 cfssl print-defaults csr > server.json
131125 ` ` `
@@ -155,8 +149,6 @@ This section describes how to issue certificates for the TiDB cluster using two
155149
156150 Finally, generate the server-side certificate:
157151
158- {{< copyable " shell-regular" > }}
159-
160152 ` ` ` shell
161153 cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=server server.json | cfssljson -bare server
162154 ` ` `
@@ -165,8 +157,6 @@ This section describes how to issue certificates for the TiDB cluster using two
165157
166158 First, create the default ` client.json` file:
167159
168- {{< copyable " shell-regular" > }}
169-
170160 ` ` ` shell
171161 cfssl print-defaults csr > client.json
172162 ` ` `
@@ -182,8 +172,6 @@ This section describes how to issue certificates for the TiDB cluster using two
182172
183173 Finally, generate the client-side certificate:
184174
185- {{< copyable " shell-regular" > }}
186-
187175 ` ` ` shell
188176 cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=client client.json | cfssljson -bare client
189177 ` ` `
@@ -192,8 +180,6 @@ This section describes how to issue certificates for the TiDB cluster using two
192180
193181 If you have already generated two sets of certificates as described in the above steps, create the Secret object for the TiDB cluster by the following command:
194182
195- {{< copyable " shell-regular" > }}
196-
197183 ` ` ` shell
198184 kubectl create secret generic ${cluster_name} -tidb-server-secret --namespace=${namespace} --from-file=tls.crt=server.pem --from-file=tls.key=server-key.pem --from-file=ca.crt=ca.pem
199185 kubectl create secret generic ${cluster_name} -tidb-client-secret --namespace=${namespace} --from-file=tls.crt=client.pem --from-file=tls.key=client-key.pem --from-file=ca.crt=ca.pem
@@ -218,8 +204,6 @@ You can generate multiple sets of client-side certificates. At least one set of
218204
219205 First, create a directory which saves the files that ` cert-manager` needs to create certificates:
220206
221- {{< copyable " shell-regular" > }}
222-
223207 ` ` ` shell
224208 mkdir -p cert-manager
225209 cd cert-manager
@@ -269,8 +253,6 @@ You can generate multiple sets of client-side certificates. At least one set of
269253
270254 Finally, execute the following command to create an Issuer:
271255
272- {{< copyable " shell-regular" > }}
273-
274256 ` ` ` shell
275257 kubectl apply -f tidb-server-issuer.yaml
276258 ` ` `
@@ -338,8 +320,6 @@ You can generate multiple sets of client-side certificates. At least one set of
338320
339321 Execute the following command to generate the certificate:
340322
341- {{< copyable " shell-regular" > }}
342-
343323 ` ` ` shell
344324 kubectl apply -f tidb-server-cert.yaml
345325 ` ` `
@@ -382,8 +362,6 @@ You can generate multiple sets of client-side certificates. At least one set of
382362
383363 Execute the following command to generate the certificate:
384364
385- {{< copyable " shell-regular" > }}
386-
387365 ` ` ` shell
388366 kubectl apply -f tidb-client-cert.yaml
389367 ` ` `
@@ -521,8 +499,6 @@ You can generate multiple sets of client-side certificates. At least one set of
521499
522500 2. Create the certificate by running the following command:
523501
524- {{< copyable "shell-regular" >}}
525-
526502 ``` shell
527503 kubectl apply -f tidb-components-client-cert.yaml
528504 ```
@@ -645,24 +621,18 @@ In this step, you create a TiDB cluster and perform the following operations:
645621
6466222. Deploy the TiDB cluster:
647623
648- {{< copyable " shell-regular" > }}
649-
650624 ` ` ` shell
651625 kubectl apply -f tidb-cluster.yaml
652626 ` ` `
653627
6546283. Back up the cluster:
655629
656- {{< copyable " shell-regular" > }}
657-
658630 ` ` ` shell
659631 kubectl apply -f backup.yaml
660632 ` ` `
661633
6626344. Restore the cluster:
663635
664- {{< copyable " shell-regular" > }}
665-
666636 ` ` ` shell
667637 kubectl apply -f restore.yaml
668638 ` ` `
@@ -673,18 +643,39 @@ To connect the MySQL client with the TiDB cluster, use the client-side certifica
673643
674644Execute the following command to acquire the client-side certificate and connect to the TiDB server:
675645
676- {{< copyable " shell-regular" > }}
677-
678646` ` ` shell
679647kubectl get secret -n ${namespace} ${cluster_name} -tidb-client-secret -ojsonpath=' {.data.tls\.crt}' | base64 --decode > client-tls.crt
680648kubectl get secret -n ${namespace} ${cluster_name} -tidb-client-secret -ojsonpath=' {.data.tls\.key}' | base64 --decode > client-tls.key
681649kubectl get secret -n ${namespace} ${cluster_name} -tidb-client-secret -ojsonpath=' {.data.ca\.crt}' | base64 --decode > client-ca.crt
682650` ` `
683651
684- {{< copyable " shell-regular" > }}
685-
686652` ` ` shell
687653mysql --comments -uroot -p -P 4000 -h ${tidb_host} --ssl-cert=client-tls.crt --ssl-key=client-tls.key --ssl-ca=client-ca.crt
688654` ` `
689655
690656Finally, to verify whether TLS is successfully enabled, refer to [checking the current connection](https://docs.pingcap.com/tidb/stable/enable-tls-between-clients-and-servers#check-whether-the-current-connection-uses-encryption).
657+
658+ # # Reload certificates
659+
660+ The certificate reload process depends on how you generate certificates:
661+
662+ - If you generate the certificate and key files manually using ` cfssl` , you must update the corresponding Secret manually.
663+ - If you generate the certificate and key files using ` cert-manager` , the Secret is updated automatically whenever a new certificate is issued.
664+
665+ To let TiDB use the new certificate, run [` ALTER INSTANCE RELOAD TLS` ](https://docs.pingcap.com/tidb/stable/sql-statement-alter-instance/# reload-tls).
666+
667+ To verify the certificate validity period, run the following SQL statement to check the ` Ssl_server_not_before` and ` Ssl_server_not_after` status variables:
668+
669+ ` ` ` sql
670+ SHOW GLOBAL STATUS LIKE ' Ssl\_server\_not\_%' ;
671+ ` ` `
672+
673+ ` ` `
674+ +-----------------------+--------------------------+
675+ | Variable_name | Value |
676+ +-----------------------+--------------------------+
677+ | Ssl_server_not_after | Apr 23 07:59:47 2026 UTC |
678+ | Ssl_server_not_before | Jan 24 07:59:47 2025 UTC |
679+ +-----------------------+--------------------------+
680+ 2 rows in set (0.011 sec)
681+ ` ` `
0 commit comments