Re: mod_ssl: Add support for OpenSSL providers

[Daniel]

On 8/4/26 21:57, Graham Leggett via dev wrote:

On 04 Aug 2026, at 17:57, Joe Orton  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 
 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 

Re: mod_ssl: Add support for OpenSSL providers

[Graham Leggett via dev]

On 05 Aug 2026, at 07:53, Joe Orton  wrote:

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

I think it serves the goal excellently. Clean separation between old behaviour 
and new, vast improvement in the lives of end users by doing useful work for 
them that up till now they have to do for themselves for no reason, isn't going 
to break existing users.

> The CADN thing... who cares about using that with a STORE?

Windows users.

Why would a windows user, or someone who is picking up their certs from a cloud 
based HSM, etc etc, want to go through some manual process of exporting certs 
out of their preferred store to be saved as a file somewhere local to a server 
somewhere.

The whole idea to be nice to people and encourage the deployment of secure 
services starts with removing the pointless make-work. OpenSSL's store 
mechanism does an excellent job of that and we must use it.

>> CRLs are done here, but to be honest they could be folded into 
>> 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".

Not a bad idea to be fair.

I think "SSLStoreURI / SSLTrustURI" and "SSLProxyStoreURI / SSLProxyTrustURI". 
The URIs refer to certs, keys, crls, etc so "Certificate" is a misnomer.

Regards,
Graham
--

Re: mod_ssl: Add support for OpenSSL providers

[Joe Orton]

On Tue, Aug 04, 2026 at 08:57:01PM +0100, Graham Leggett via dev wrote:
> On 04 Aug 2026, at 17:57, Joe Orton  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 
>  
> 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

Re: mod_ssl: Add support for OpenSSL providers

[Graham Leggett via dev]

On 04 Aug 2026, at 17:57, Joe Orton  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 
 
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
--

Re: mod_ssl: Add support for OpenSSL providers

[Joe Orton]

On Tue, Aug 04, 2026 at 02:40:50PM +0100, Graham Leggett via dev wrote:
> On 04 Aug 2026, at 07:49, Joe Orton  wrote:
> 
> >> https://github.com/apache/httpd/pull/698
> > 
> > It's a lot of new directives, which is... challenging. Do we really want 
> > to support 3xN for every cert config command variant forever?
> 
> No, I expect to deprecate the File and Path directives and only have 
> URI. This is dependent on how long we want to support openssl clones 
> that have chosen not to be backwards compatible with OpenSSL.

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.

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.

> I want us to have a ./configure --without-deprecated flag or 
> equivalent to start making deprecated behaviour go away across the 
> server, particularly in the OpenSSL4+ world.

> As already explained, there is no behaviour compatibilty at all 
> between the File directives and URI directives, one is a file 
> containing PEM encoded certs and maybe keys, in a fixed (but 
> inconsistent) order as per 1990s openssl, the other is a URI that 
> points at a formal certificate/key store. While URIs accept a file 
> without a scheme as a special case, that is only possible on unix 
> platforms and not windows, which has no possibility of backwards 
> compatibility at all.
> 
> There needs to be a clear and obvious distinction between two wildly 
> different behaviours, otherwise end users will suffer. End users not 
> suffering is the point (particularly windows users, they've suffered 
> enough).

Understood all the above, that makes sense to me.

Regards, Joe

Re: mod_ssl: Add support for OpenSSL providers

[Graham Leggett via dev]

On 04 Aug 2026, at 07:49, Joe Orton  wrote:

>> https://github.com/apache/httpd/pull/698
> 
> It's a lot of new directives, which is... challenging. Do we really want 
> to support 3xN for every cert config command variant forever?

No, I expect to deprecate the File and Path directives and only have URI. This 
is dependent on how long we want to support openssl clones that have chosen not 
to be backwards compatible with OpenSSL.

I want us to have a ./configure --without-deprecated flag or equivalent to 
start making deprecated behaviour go away across the server, particularly in 
the OpenSSL4+ world.

As already explained, there is no behaviour compatibilty at all between the 
File directives and URI directives, one is a file containing PEM encoded certs 
and maybe keys, in a fixed (but inconsistent) order as per 1990s openssl, the 
other is a URI that points at a formal certificate/key store. While URIs accept 
a file without a scheme as a special case, that is only possible on unix 
platforms and not windows, which has no possibility of backwards compatibility 
at all.

There needs to be a clear and obvious distinction between two wildly different 
behaviours, otherwise end users will suffer. End users not suffering is the 
point (particularly windows users, they've suffered enough).

> Similarly, 
> with a *lot* of new directives I would expect to see a lot of new test 
> cases, where are they?

The very first and top priority is absolutely zero regressions with the 
existing test suites. The rest of the tests will follow once nothing broke.

Making sure that the URIs and Files played nicely together took significant 
effort, play nice is the first goal.

> SSLCADNRequestURI doesn't seem to be registered.

Fixed in r1936863.

> At least some of the merging seems to be missing, I can't see ->crl_uri 
> is merged and I haven't checked the rest thoroughly.

Fixed in r1936867.

> All the num_ fields in modssl_ctx_uri should be unsigned

Fixed in r1936868.

> I don't get the error handling in ssl_cmd_check_uri() - does that really 
> work? OSSL_STORE_open_ex() returns NULL on error AFAICT and so can you 
> reach the error path for unrecognized URIs? It looks like it's not, 
> "SSLCertficateURI foo://bar" only fails at runtime which is I assume not 
> intentional.

OSSL_STORE_open_ex() returns NULL on error, then we look at 
ERR_peek_last_error() for OSSL_STORE_R_UNREGISTERED_SCHEME. That will fail if 
foo: isn't recognised.

The URIs are properly opened and enumerated at startup, all leaf certs are 
matched to the servername/aliases, certs and keys are matched up with one 
another, all intermediate paths created, and if this doesn't result in at least 
one valid certificate the server won't start as expected with a detailed 
message. "SSLCertficateURI foo://bar" fails in ssl_cmd_check_uri, and if it 
gets past that on startup, not at runtime, which is intentional.

Regards,
Graham
--

Re: mod_ssl: Add support for OpenSSL providers

[Joe Orton]

On Wed, Jul 29, 2026 at 10:45:22PM +0100, Graham Leggett via dev wrote:
> Hi all,
> 
> OpenSSL3+ added support for full certificate and key stores, based on their 
> provider mechanism.
> 
> What this means in plain english is that you can point OpenSSL at a PEM file, 
> a PKCS12 file, a pcks11: URI, the whole Windows certificate store, whatever 
> is going, and it will just work.
> 
> OpenSSL addresses each of these stores using a URI.
> 
> I have added support for this to mod_ssl here:
> 
> https://github.com/apache/httpd/pull/698

It's a lot of new directives, which is... challenging. Do we really want 
to support 3xN for every cert config command variant forever? Similarly, 
with a *lot* of new directives I would expect to see a lot of new test 
cases, where are they?

SSLCADNRequestURI doesn't seem to be registered.

At least some of the merging seems to be missing, I can't see ->crl_uri 
is merged and I haven't checked the rest thoroughly.

All the num_ fields in modssl_ctx_uri should be unsigned

I don't get the error handling in ssl_cmd_check_uri() - does that really 
work? OSSL_STORE_open_ex() returns NULL on error AFAICT and so can you 
reach the error path for unrecognized URIs? It looks like it's not, 
"SSLCertficateURI foo://bar" only fails at runtime which is I assume not 
intentional.