-
Notifications
You must be signed in to change notification settings - Fork 687
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider shorter X.509 certificate lifetimes #4299
Comments
This issue is stale because it has been open for 60 days with no activity. If no comment has been made and the |
This issue will be closed because it has been stale for 15 days with no activity. If you still have any question about this issue, feel free to reopen it or create a new one. |
You're welcome @TomShawn and I'm happy to discuss further |
I think there are three separate things in this issue:
I think the two different scenarios here are:
|
Change Request
The certificate-based authentication docs suggest minting 1,000-year TLS certificates for authentication. 1,000 years is a very long validity period. Have you considered 90 days or less?
Short-lived certificates are much safer, especially for client authentication (where client certs and keys are more likely to moved around and more easily exfiltrated). If nothing else, it'd be great for the docs to point to resources on best practices for certificate management in production. For configuring automated renewal, it'd also be helpful to know when certificate files are read by TiDB. Does TiDB need to be restarted? Sent a HUP signal? Or, are certificates files read on every new connection?
A more gourmet option is for TiDB to build in support for being an ACME client (the protocol used by Let's Encrypt).
My company (Smallstep Labs) has created an open-source X.509 CA that makes minting and renewing certificates easy. Here's a tutorial for automating x.509 certificate lifecycle management.
The text was updated successfully, but these errors were encountered: