[Bug 66526] New: provide a better way to reload TLS certificates/keys/etc.

[bu...@apache.org]

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 66526] provide a better way to reload TLS certificates/keys/etc.

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=66526

--- Comment #1 from Stefan Eissing <st...@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.

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=66526

--- Comment #2 from Christoph Anton Mitterer <ca...@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