Mailing List Archive

[Bug 66526] provide a better way to reload TLS certificates/keys/etc.
https://bz.apache.org/bugzilla/show_bug.cgi?id=66526

--- Comment #1 from Stefan Eissing <stefan@eissing.org> ---
I'm afraid this would open a can of worms and make configuration handling more
error prone. Additionally, I see impacts of this on server performance, too.

In ACME support for Apache httpd (mod_md), we do not trigger automatic graceful
restarts for the reasons you mentioned. Instead, we recommend regular reloads
at times the server admin deems appropriate.

The immediate need for a certificate change reload, in my experience, only
happens when you take additional domains into a server. But then you'd need new
`VirtualHost` definitions anyway.

For domains with existing certificates, ACME renewals are done days before the
certs expire, so a reload can be quite delayed until a problem with the service
occurs.

Are there additional scenarios where this feature is necessary?

--
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 66526] provide a better way to reload TLS certificates/keys/etc. [ In reply to ]
https://bz.apache.org/bugzilla/show_bug.cgi?id=66526

--- Comment #2 from Christoph Anton Mitterer <calestyo@scientia.org> ---
Hey.

Would it really open so much?
I'd have expected that there are only rather few (use-)cases where one wants to
independently reload parts of the configuration:

- Apache's main configuration (and all that it includes)... which is anyway
already supported by the graceful restart.

- TLS cert/key data

- TLS CRL data (not sure what it actually does there right now... in principle
it would only make sense if it is already (automatically) reloaded every now
and then (either via fnotify or periodically), as e.g. CRLs will get constantly
updated.

- external files like user/group files for mod_authn_file and friends (not sure
if these are read once at startup or every time a decision needs to be made).



Why do you think it would impact the performance? It would only happen when a
TLS cert/key reload is manually triggered, and there it should probably faster
(and perhaps even be less intrusive) than the general graceful restart.


> The immediate need for a certificate change reload

Well that's not the problem here IMO.
The problem is that it will happen quite often[0] and typically automatically
(via cronjob or systemd timer) AND - and this is the point - that then (when
doing it via the graceful restart or via the restart) undesired configuration
changes may get accidentally active.

Consider that I'm just about to edit apache config... I add some new portions
that are exported e.g. via <Directory>... I save the config, but haven't added
any access control yet (which doesn't matter as I do not restart the server
yet)... but, by coincidence, certbot comes in the way and reloads/restarts.

If there was a mechanism to only reload the certs/keys, such scenarios could be
prevented.


[0] What does e.g. LetsEncrypt use? 90 days? And doesn't it try to renew 30
days ahead of expiration? Thus in effect, every 60 days.

--
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