Can I replace the client-ca-file to invalidate all users on kubernetes?

Changing the client-ca-file will not invalidate the kubernetes-admin.

Referring to your case:

During creating a config file for generating a Certificate Signing Request you need to (CSR substitute the values marked with angle brackets (e.g. <MASTER_IP>) with real values before saving this to a file (e.g. csr.conf). Value for MASTER_CLUSTER_IP is the service cluster IP for the API server. I assume that you are using cluster.local as the default DNS domain name.

Did you add the same parameters into the API server start parameters ?

Submit the CSR to the CA, just like you would with any CSR, but with the -selfsign option. This requires your CA directory structure to be prepared first, which you will have to do anyway if you want to set up your own CA. You can find an tutorial on that here, for example. Submitting the request can be done as follows:

ca -selfsign -keyfile dist/ca_key.pem -in ca_csr.pem -out dist/ca_cert.pem \    -outdir root-ca/cert -config openssl/ca.cnf

A client node may refuse to recognize a self-signed CA certificate as valid. For a non-production deployment, or for a deployment that runs behind a company firewall, you can distribute a self-signed CA certificate to all clients and refresh the local list for valid certificates.

On each client, perform the following operations:

$ sudo cp ca.crt /usr/local/share/ca-certificates/kubernetes.crt

$ sudo update-ca-certificates

Updating certificates in /etc/ssl/certs...1 added, 0 removed; done.Running hooks in /etc/ca-certificates/update.d....done.

To make the leaked certificate useless is to replace the CA in the cluster. This would require a restart of the cluster, though. And it would require to re-issue all the certificates. You will have to recreate service account again.

To invalidate leaked tokens just delete the secret that corresponds to the user's token.Remember of certificate expiration date you have added.

I hope it helps.