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