If docker-server.sh finds certificates mounted in '/etc/x509/certs', we make the assumption that the user wants us to manage their certificates for them. This means that we are 'safe' to put our keystore config in configDropins/overrides. This will prevent the issue reported in 427, as the generated keystore/config will override the config from the example server.xml, so there will no longer be a mismatch between keystore and keystore password.
The openssl commands will overwrite an existing keystore in the default location, so creating the keystore will always suceed, even if an existing keystore is in the container image.
If the user has run configure.sh in their dockerfile, then there will be an existing keystore.xml snippet in configDropins/defaults. This will cause a warning at server startup due to multiple definitions of the keystore config. The override will win the conflict, so it would be safe to leave the defaults keystore.xml in place, but it is probably better to try and remove it.
Again, this should be safe, as it is highly unlikely that a user would have written to this specific file location and name.
A potentially 'fail' scenario would be if a user has added a keystore + config into their container image, and also mounted certificates in /etc/x509/certs. We would then overwrite their keystore, and override their keystore config.
This is an unlikely scenario as it is not best practice to put a keystore into a container image, and in addition, the user would then be unlikely to mount certificates into /etc/x509/certs.
idlewis
commented
8 months ago
First stab at addressing #427
If docker-server.sh finds certificates mounted in '/etc/x509/certs', we make the assumption that the user wants us to manage their certificates for them. This means that we are 'safe' to put our keystore config in configDropins/overrides. This will prevent the issue reported in 427, as the generated keystore/config will override the config from the example server.xml, so there will no longer be a mismatch between keystore and keystore password.
The openssl commands will overwrite an existing keystore in the default location, so creating the keystore will always suceed, even if an existing keystore is in the container image.
If the user has run configure.sh in their dockerfile, then there will be an existing keystore.xml snippet in configDropins/defaults. This will cause a warning at server startup due to multiple definitions of the keystore config. The override will win the conflict, so it would be safe to leave the defaults keystore.xml in place, but it is probably better to try and remove it. Again, this should be safe, as it is highly unlikely that a user would have written to this specific file location and name.
A potentially 'fail' scenario would be if a user has added a keystore + config into their container image, and also mounted certificates in /etc/x509/certs. We would then overwrite their keystore, and override their keystore config. This is an unlikely scenario as it is not best practice to put a keystore into a container image, and in addition, the user would then be unlikely to mount certificates into /etc/x509/certs.