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 --
