Re: mod_ssl: Add support for OpenSSL providers

On 8/4/26 21:57, Graham Leggett via dev wrote:
> On 04 Aug 2026, at 17:57, Joe Orton <[email protected]> wrote:
>
>> I like the STORE stuff - it's a nice API. Getting rid of SSL*File will
>> mean breaking every single existing mod_ssl configuration (outside of
>> mod_md). I don't see any motivation for that - "there is a new OpenSSL
>> API so you all have to change your configs" is not an argument I want to
>> have with users at any point. So even talking about deprecation of the
>> existing directives seems futile to me.
>
> I'm talking over a decade plus. I am hoping that the new store will 
> convince people to drop their old configs just through less pain, and 
> the older directives go into mod_ssl_compat.
>
>> 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.
>
> The two main directives are for certs, intermediates and keys, in any 
> order, server, proxy. Point at the entire Windows cert store, and it 
> will identify all leaf certs that match ServerName+ServerAlias that 
> have private keys, sort oldest to newest, grab the chains, give them 
> to openssl. End result is most recently issued cert for RSA, ECDSA, 
> etc wins.
>
> https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslcertificateuri
> https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslproxymachinecertificateuri
>
> The above directives replace all of these:
>
> https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslcertificatechainfile
> https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslcertificatefile
> https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslcertificatekeyfile
> https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslproxymachinecertificatechainfile
> https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslproxymachinecertificatefile
> https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslproxymachinecertificatepath
>
> 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
>
> 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.
>
> https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslcarevocationuri
> https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslproxycarevocationuri
>
> They replace these:
>
> https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslcarevocationfile
> https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslcarevocationpath
> https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslproxycarevocationfile
> https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslproxycarevocationpath
>
> Regards,
> Graham
> --
>
Hello,

I am no dev, but I would like to give my feedback as admin of dozens or hundreds of instances in enterprise situation.

If I am interpreting this correctly if it gets applied it would apply to 2.4.69 or 2.4.70 or similar, removing or deprecating current directives from mod_ssl and spawning a new mod_ssl_compat module for compatibility the way is being implemented now.

Since an upgrade change could be caused by wanting to fix a CVE or similar, not just changes in mod_ssl, if the update involves changed behaviour in a module, the changes involved will be much more.

Wouldn't it be less painful for users/admins to spawn a new module (example: mod_ssl_new or whatever) with the new functionality instead of turning most existing functionality to a deprecating named module mod_ssl_compat?

On one hand, if new functionality is changed in mod_ssl, changing the module functionality that will force at least one configuration change in all your instances, being it the name of the module (to change to compat version) or the name of the directives loading the certificate.
So if the user/admin has dozens/hundreds of servers, you will have to change that many instances upon upgrade. Affecting the user/admin right away.

On the other hand, if the current module name stays the same, upon upgrade you will not have to change anything until you decide you are ready for the new module functionality. Thus upgrading won't affect anyone until they decide to use the new "mod_ssl_new" functionality, load the new module and change their directives, or do it where they can when they can.
This way, users/admins wont be affected and those that are ready can migrate to new functionality right away when they want.


Thanks for reading, for you work and patience.


-- 
-Daniel
Find help at #httpd in Libera.chat