Hi @yonigo , thanks for using forum for this questions!
Here are answers to your questions
=> 1. What will happen to the db once the root certificate expires?
Upon the expiration of the root certificate, any new connections or services that rely on this certificate for trust validation will fail. This can result in database connection errors, as clients and services will no longer trust the certificate provided by the database server.
Existing connections might continue to work until they are restarted or until a reauthentication is required. Certificates should be updated to newer ones before expiration.
=> 2. Is the operator programmed to handle this situation, or will I need to manually intervene?
You need to customize it. The operator could generate certificates and use self-signed certificates. However, self-signed certificates are not suitable for proper production usage because it’s impossible to customize such certificates. You need to use the proper one. You can use cert-manager.io which provides Kubernetes resources for easy certificate issuing/renewal/monitoring and management.
=> 3. Is there a simple way to extend the expiration time of the root certificate (lets say for 10 years)?
You can do it, by obtaining a Certificate from a Trusted Certificate Authority
For production environments, it’s advisable to use certificates issued by a trusted CA. These certificates are inherently trusted by most clients and browsers and don’t require the extra step of manually trusting a self-signed certificate.
Thanks for the quick response.
Could you please provide a bit more clarification? If I still want to use the self-signed certificate that is automatically created by the operator using the cert-manager, is there a way to extend its expiration beyond the default one year?
Eventually ive solved this by creating my own certificates using cert-manager CRs (the resources names are identical to the ones the operator creates, this way the operator won’t bother to create its own):