> Am 09.07.2019 um 13:28 schrieb Joe Orton <[email protected]>:
>
> On Tue, Jul 09, 2019 at 11:57:00AM +0200, Stefan Eissing wrote:
>> mod_md v2.0.x has landed in 2.4.x. This offers the ACMEv2 (RFC 8555) support
>> and offers various monitoring possibilities for admins to see what is going
>> on. But...it really needs votes for a mod_ssl related backport:
>>
>> mod_ssl: offer new hooks for modules like mod_md and remove use of mod_md's
>> optional functions.
>>
>> Without this, the new TLS challenge will not work and people still need to
>> rely on port 80. I heard from one user whose ISP is blocking incoming port
>> 80 (everything can be reasoned with "security" nowadays). So, for some, this
>> is really vital.
>>
>> I'd appreciate if some would find the time for a vote.
>
> Sorry, should have looked when you asked before...
I am even more sorry that the person originally requesting this change never
replied back.
This all makes me very sad.
> The new hooks should be in mod_ssl_openssl.h and use OpenSSL types
> properly for type-safety rather than void *, that's exactly the kind of
> thing this header was added for. Or else it should marshall everything
> through DER, not sure if that is feasible, probably less efficient.
>
> Not sure why 'struct apr_array_header_t' was used but I committed the
> trivial fix for that.
>
> The API is a bit less documented that I'd like though I know mod_ssl is
> worse than awful here, e.g. a few places not clear what the return value
> means, I have to guess/look at the implementation, this is ignored:
>
> + ssl_run_add_cert_files(s, p, pks->cert_files, pks->key_files);
>
> but this one is not:
>
> if (ssl_run_get_stapling_status(&rspder, &rspderlen, conn, s, x) ==
> APR_SUCCESS) {
>
> and when passing apr_array_header_t make clear it's an array of (const
> char *) because again otherwise you have to guess/read the code.
*shrugs*
