Re: mod_ssl: Add support for OpenSSL providers

"Graham Leggett via dev" <[email protected]>
Newsgroups gmane.comp.apache.devel
Message-ID <[email protected]>
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
--
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.