On Tue, Aug 04, 2026 at 08:57:01PM +0100, Graham Leggett via dev wrote: > On 04 Aug 2026, at 17:57, Joe Orton <[email protected]> wrote: > > It looks like end goal here is to allow users to slurp everything or > > anything out of a STORE URI ... CRLs, CA, leaf certs... great - so why > > not have just a single new directive (one for each of proxy/server I > > assume) to pass in a URI and do exactly that? That can happily live > > alongside SSL*File/Path and we could argue about deprecating those in > > 2.6 separately/later. > > Minimising directives, which in turn minimises the ways things go wrong, is > the primary goal.
I really think that increasing the LoC in mod_ssl by 10% with 7 new directives is not serving *that* goal well at all. > CA certs are done by these. The group of trusted certs, server, proxy, with > the group of trusted certs to be advertised if different. > > https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslcacertificateuri > https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslcadnrequesturi > https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslproxycacertificateuri The CADN thing... who cares about using that with a STORE? It's an extremely niche feature, I think I've probably only seen a handful of users of that. Why does it matter if they have to drop a PEM file in for that? Just drop the URI variant. > They replace all of these: > > https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslcacertificatefile > https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslcacertificatepath > https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslcadnrequestfile > https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslcadnrequestpath > https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslproxycacertificatefile > https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslproxycacertificatepath > > CRLs are done here, but to be honest they could be folded into > sslcacertificateuri > <https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslcacertificateuri> > above and have trusted certs and CRLs covered by the same directive. +1 I would also be very happy to junk the awkward/ugly "SSLProxyMachine" prefix here in a new directive for something more meaningful like "SSLProxyClient". Regards, Joe
