Re: mod_ssl: Add support for OpenSSL providers

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