https://bz.apache.org/bugzilla/show_bug.cgi?id=66526
Bug ID: 66526
Summary: provide a better way to reload TLS
certificates/keys/etc.
Product: Apache httpd-2
Version: 2.4.54
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P2
Component: All
Assignee: bugs@httpd.apache.org
Reporter: calestyo@scientia.org
Target Milestone: ---
Hey.
Right now it seems that TLS certificates/keys are reloaded either on a graceful
restart or - obviously - a normal restart.
The latter is obviously rather unsuited as it causes some interruption.
But also the former has IMO its cons, namely:
When using automated systems like certbot/ACME one would then configure these
to execute a graceful restart of httpd, whenever certificates/keys where
replaced.
The problem is however, that the graceful restart, reloads *all* configuration
not just certificates.
Now the configuration may be "loadable" but in a state that is not yet intended
for use.
Or it may be just being edited and the graceful reload might fail. Of course,
httpd would continue to run, but the certificates/keys wouldn't be replaced
(and certbot wouldn't try again).
So for that reasons I think it would be quite nice to have a reload command,
that affects just those files - but not the configuration files.
Ideally such a reload command would be designed in such a way, that it could be
extended in the future (to reload other specific kinds of files).
That's also bit of a problem of course, as simply using a signal wouldn't work
then (USR1 is already graceful reload, .. there's USR2, not sure if it's
already used, but even if not... there wouldn't be any others that could be
used).
So some other way would need to be taken... not sure what would be acceptable
for httpd... dbus? Some kind of command socket?
In any case, I, personally, would think it's a bad idea to use fnotify or
periodic re-loads of the certificate files.
Thanks,
Chris.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
Bug ID: 66526
Summary: provide a better way to reload TLS
certificates/keys/etc.
Product: Apache httpd-2
Version: 2.4.54
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P2
Component: All
Assignee: bugs@httpd.apache.org
Reporter: calestyo@scientia.org
Target Milestone: ---
Hey.
Right now it seems that TLS certificates/keys are reloaded either on a graceful
restart or - obviously - a normal restart.
The latter is obviously rather unsuited as it causes some interruption.
But also the former has IMO its cons, namely:
When using automated systems like certbot/ACME one would then configure these
to execute a graceful restart of httpd, whenever certificates/keys where
replaced.
The problem is however, that the graceful restart, reloads *all* configuration
not just certificates.
Now the configuration may be "loadable" but in a state that is not yet intended
for use.
Or it may be just being edited and the graceful reload might fail. Of course,
httpd would continue to run, but the certificates/keys wouldn't be replaced
(and certbot wouldn't try again).
So for that reasons I think it would be quite nice to have a reload command,
that affects just those files - but not the configuration files.
Ideally such a reload command would be designed in such a way, that it could be
extended in the future (to reload other specific kinds of files).
That's also bit of a problem of course, as simply using a signal wouldn't work
then (USR1 is already graceful reload, .. there's USR2, not sure if it's
already used, but even if not... there wouldn't be any others that could be
used).
So some other way would need to be taken... not sure what would be acceptable
for httpd... dbus? Some kind of command socket?
In any case, I, personally, would think it's a bad idea to use fnotify or
periodic re-loads of the certificate files.
Thanks,
Chris.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org