User is allowed to specify path to TLS certificates, but if loading the certificate fails, the api is still started with insecure configuration. Furthermore, #1187 adds more configuration options to allow users customize the TLS configuration (min version, ciphers, curve preferences) and it keeps the existing behavior. That's bad because the user explicitly configured those options, so the expected behavior should be that we fail if we fail to load it. This will be breaking change for deployments with bad configuration as they'll fail to start after upgrade. To allow quick setting of testing environments which do not require an extra effort of setting TLS, we can add an option to run insecure, but that should not be the default and users will have to explicitly opt-out.
User is allowed to specify path to TLS certificates, but if loading the certificate fails, the api is still started with insecure configuration. Furthermore, #1187 adds more configuration options to allow users customize the TLS configuration (min version, ciphers, curve preferences) and it keeps the existing behavior. That's bad because the user explicitly configured those options, so the expected behavior should be that we fail if we fail to load it. This will be breaking change for deployments with bad configuration as they'll fail to start after upgrade. To allow quick setting of testing environments which do not require an extra effort of setting TLS, we can add an option to run insecure, but that should not be the default and users will have to explicitly opt-out.