On Tue, Aug 04, 2026 at 02:40:50PM +0100, Graham Leggett via dev wrote: > On 04 Aug 2026, at 07:49, Joe Orton <[email protected]> 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
