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
