Problem
A connection handler builds its SSLContext once, when it is initialized or when its own configuration changes (LDAPConnectionHandler#configureSSL, called from initializeConnectionHandler and applyConfigurationChange). The key managers in that context hold the key store as it was read at that moment. A file based key manager provider reads the file each time it is asked for key managers, but nothing asks again.
So when the key store file is replaced with a renewed certificate, the server keeps presenting the old one until it is restarted, or until some property of the connection handler is changed.
Measured with openidentityplatform/opendj:latest (5.1.2): after cp of a new config/keystore, LDAPS keeps serving the old certificate; a no-op-in-effect dsconfig set-connection-handler-prop --handler-name "LDAPS Connection Handler" --set max-blocked-write-time-limit:2m1s makes it serve the new one at once.
Short-lived certificates renewed by an agent (cert-manager on Kubernetes, certbot, Vault agent) replace the file on a schedule, so every renewal needs a restart or a scripted config change with admin credentials.
Expected
A file based key manager provider (and, for the same reason, a file based trust manager provider) notices that its file has changed and new TLS handshakes use the new content, without a restart and without a configuration change. A file that cannot be loaded (a renewal caught half written, a wrong PIN) must not break TLS: the provider keeps the last good content and logs the error.
Notes
Needed for #1087 (the Docker image copies a renewed Kubernetes Secret into config/, and has no way to make the running server use it). Related to the Helm chart proposal, discussion #1079.
Problem
A connection handler builds its
SSLContextonce, when it is initialized or when its own configuration changes (LDAPConnectionHandler#configureSSL, called frominitializeConnectionHandlerandapplyConfigurationChange). The key managers in that context hold the key store as it was read at that moment. A file based key manager provider reads the file each time it is asked for key managers, but nothing asks again.So when the key store file is replaced with a renewed certificate, the server keeps presenting the old one until it is restarted, or until some property of the connection handler is changed.
Measured with
openidentityplatform/opendj:latest(5.1.2): aftercpof a newconfig/keystore, LDAPS keeps serving the old certificate; a no-op-in-effectdsconfig set-connection-handler-prop --handler-name "LDAPS Connection Handler" --set max-blocked-write-time-limit:2m1smakes it serve the new one at once.Short-lived certificates renewed by an agent (cert-manager on Kubernetes, certbot, Vault agent) replace the file on a schedule, so every renewal needs a restart or a scripted config change with admin credentials.
Expected
A file based key manager provider (and, for the same reason, a file based trust manager provider) notices that its file has changed and new TLS handshakes use the new content, without a restart and without a configuration change. A file that cannot be loaded (a renewal caught half written, a wrong PIN) must not break TLS: the provider keeps the last good content and logs the error.
Notes
Needed for #1087 (the Docker image copies a renewed Kubernetes Secret into
config/, and has no way to make the running server use it). Related to the Helm chart proposal, discussion #1079.