Description
Allow users to configure a custom ECF_SSL certificate directory for uw ecflow server, instead of being limited to the default ecFlow location, $HOME/.ecflowrc/ssl.
Currently the path is hard-coded in src/uwtools/ecflow.py:
_SSL_DIR = Path.home() / ".ecflowrc" / "ssl"
_provision_ssl() always operates on _SSL_DIR: it reuses the three required files (dh2048.pem, server.cert, server.key). If all exist raise UWError if the directory is incomplete, and otherwise generates them there. There is no way to point the server at a different cert store.
This feature would add an optional config key (e.g. ECF_SSL_DIR, or a dedicated ssl: block — naming TBD) that overrides the default. Example:
ECF_HOME: /path/to/run
ECF_SSL_DIR: /shared/certs/ecflow # new: custom SSL cert directory
-When set, _provision_ssl() applies its existing reuse/error/generate logic to that directory (with 600 permissions on generated files).
-When unset, behavior is unchanged (default to $HOME/.ecflowrc/ssl).
-The --insecure path is unaffected.
This supports site-managed, shared, per-experiment, or read-only cert stores where the default home location isn't writable or appropriate.
Acceptance Criteria
-Default-only (current behavior): keep $HOME/.ecflowrc/ssl as the sole location. Rejected because it can't accommodate shared or read-only cert stores, and forces all experiments on a host to share one cert set.
-Symlinking into the default location: users could manually symlink custom certs into $HOME/.ecflowrc/ssl. Rejected as the primary solution because it's manual, error-prone, and doesn't compose well with per-experiment configs, though it may still be relevant to the client-side constraint below.
Additional Context
Follow-up from #868 / PR #923; the default-only behavior was an intentional MVP scope decision.
One constraint to resolve: ecflow_client (including job-side child commands) must locate the same server.crt to connect over SSL, and the client defaults to $HOME/.ecflowrc/ssl. A custom server-side directory only works end-to-end if the client can also find the cert (via ECF_SSL server-name conventions and/or symlinking into the default location). This should be confirmed and documented as part of the work.
Description
Allow users to configure a custom
ECF_SSLcertificate directory foruw ecflow server, instead of being limited to the default ecFlow location,$HOME/.ecflowrc/ssl.Currently the path is hard-coded in
src/uwtools/ecflow.py:_SSL_DIR = Path.home() / ".ecflowrc" / "ssl"_provision_ssl()always operates on_SSL_DIR: it reuses the three required files (dh2048.pem,server.cert,server.key). If all exist raiseUWErrorif the directory is incomplete, and otherwise generates them there. There is no way to point the server at a different cert store.This feature would add an optional config key (e.g.
ECF_SSL_DIR, or a dedicatedssl:block — naming TBD) that overrides the default. Example:-When set,
_provision_ssl()applies its existing reuse/error/generate logic to that directory (with600permissions on generated files).-When unset, behavior is unchanged (default to
$HOME/.ecflowrc/ssl).-The
--insecurepath is unaffected.This supports site-managed, shared, per-experiment, or read-only cert stores where the default home location isn't writable or appropriate.
Acceptance Criteria
-Default-only (current behavior): keep
$HOME/.ecflowrc/sslas the sole location. Rejected because it can't accommodate shared or read-only cert stores, and forces all experiments on a host to share one cert set.-Symlinking into the default location: users could manually symlink custom certs into
$HOME/.ecflowrc/ssl. Rejected as the primary solution because it's manual, error-prone, and doesn't compose well with per-experiment configs, though it may still be relevant to the client-side constraint below.Additional Context
Follow-up from #868 / PR #923; the default-only behavior was an intentional MVP scope decision.
One constraint to resolve:
ecflow_client(including job-side child commands) must locate the sameserver.crtto connect over SSL, and the client defaults to$HOME/.ecflowrc/ssl. A custom server-side directory only works end-to-end if the client can also find the cert (viaECF_SSLserver-name conventions and/or symlinking into the default location). This should be confirmed and documented as part of the work.