On Tue, Feb 13, 2024 at 10:36:44AM +0100, Peter Boy wrote:
Hi folks,
We have a serious issue with the current Apache httpd package, which is an indispensable service for a server these days.
The issue is basically the default configuration as provided by the package:
- if you create just one server in den .conf directory, it results in a non-functional https configuration
- the configuration uses items, that are deprecated since version 2.4
- the default layout of the default configuration is currently not suitable
I wrote a bug report about it: https://bugzilla.redhat.com/show_bug.cgi?id=2258121
Hi Peter,
This is definitely an interesting & complex topic. Sorry nobody has replied on your bug, I did read it but... it's a big area and haven't had time to think it through properly.
Do you have a concrete proposal on exactly what you'd like to do differently? I'm guessing you do but it's not really laid out in the bug. Going through some of my thoughts:
1. The default ssl.conf & vhost definition is difficult/awkward, I definitely agree here. I suppose there are several parts to this -
a) All the stuff outside the vhost in ssl.conf should be a hard-coded default or unnecessary - some coding probably required, e.g. I already made SSLRandom a no-op upstream since it doesn't make sense with modern OpenSSL.
b) Can & should we retain a default :443 vhost with generated certs? I *think* yes, but am quite open to persuasion on this.
2. Including mod_ssl as part of httpd I definitely don't agree with and is technically not necessary; it may be better to argue that we should "Recommends: mod_ssl". We will never make https:// "work" out of the box without active user intervention, at least since ACME CAs require a subscriber agreement contract.
3. In thinking about how we do SSL vhost config, I think it's important to consider all use cases - mod_md-managed, certbot-driven configs, or "traditional CA" users. (Particularly for ACME with DNS validation it's easier to get going with certbot than mod_md.)
4. Backwards compatibility is important and hopefully everybody agrees that we shouldn't break the upgrade path (beyond maybe removing or moving ssl.conf itself).
5. Not sure about anybody else, but I'm still not a fan of the Debian style split -enabled/-available config directories which has always seemed over-engineered to me. I'm open to being convinced we should have a new config directory in /etc/httpd which is included by default if necessary.
So, thoughts?
Regards, Joe