> Am 03.03.2021 um 13:05 schrieb Stefan Eissing <stefan.eiss...@greenbytes.de>:
>
>
>
>> Am 03.03.2021 um 11:36 schrieb Ruediger Pluem <rpl...@apache.org>:
>>
>>
>>
>> On 3/3/21 11:25 AM, Stefan Eissing wrote:
>>>
>>>
>>>> Am 03.03.2021 um 11:17 schrieb Ruediger Pluem <rpl...@apache.org>:
>>>>
>>>>
>>>>
>>>> On 3/3/21 11:01 AM, Stefan Eissing wrote:
>>>>>
>>>>>
>>>>>> Am 03.03.2021 um 10:44 schrieb Stefan Eissing
>>>>>> <stefan.eiss...@greenbytes.de>:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Am 03.03.2021 um 10:31 schrieb Ruediger Pluem <rpl...@apache.org>:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 3/3/21 9:54 AM, Stefan Eissing wrote:
>>>>>>>>> Am 03.03.2021 um 09:35 schrieb Stefan Eissing
>>>>>>>>> <stefan.eiss...@greenbytes.de>:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Am 02.03.2021 um 20:54 schrieb Ruediger Pluem <rpl...@apache.org>:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>
>>>>> typedef struct ap_bytes ap_bytes;
>>>>> struct {
>>>>> const char *data;
>>>>> apr_size_t len;
>>>>> } ap_bytes;
>>>>>
>>>>> AP_DECLARE(int) ap_ssl_answer_challenge(conn_rec *c, const char
>>>>> *server_name, const ap_bytes **pcertificate_key_pem);
>>>>
>>>> Crossing posts :-). Quick questions:
>>>>
>>>> 1. What is the need for the len field above? I think PEM encoded data
>>>> could be nul terminated. Or do you want to leave an option
>>>> for DER data?
>>>
>>> I have been in too much contact with languages that do not NUL-terminate
>>> strings, it seems. We could just make it a "const char **" then.
>>>
>>> I do not like to define something generic parameters where the additionals
>>> use cases are unclear and may never happen. So, no DER foreseen by me. I
>>> think for the amount of data that is passed with keys/certificates, a PEM
>>> encoding is the most portable and should work fine.
>>
>> PEM seems to be a good choice and having a clear interface as well. Hence +1
>> to PEM only.
>>
>>>
>>>> 2. As there is only one ap_bytes ** above, do you want to merge the PEM
>>>> encoded certificate and key in one string?
>>>
>>> That was the thought. When I started with mod_md, I kept them separate
>>> because everyone else seem to be doing it. But I do not really see any
>>> benefit in that, really. But then, I am ignorant of a lot of things, I
>>> found in life...
>>
>> I think having them together is fine, the only question is if this makes it
>> harder to use for others if they keep them separate.
>>
>> Regards
>>
>> Rüdiger
>
> I am currently considering changing 'add_cert_files' and
> 'add_fallback_cert_files' as well to providing PEM strings. This, I found
> out, impacts ssl_init_server_certs() quite somewhat. But maybe to the better.
>
> There is this thing "mctx->cert_chain" that, when configured, changes the
> loading of chain from file to loading just a single cert from a file. I
> understand the history, but I think this should never influence how "added"
> certificates are loaded. They should always contain their chain.
>
> Which means we should have a "ssl_ctx_use_certificate(ssl_ctx, const char
> *cert_pem, const char *key_pem)" and a corresponding one for SSL*. These
> would read the PEM in a mem BIO and
> - on the 1st cert use SSL_CTX_use_certificate(ctx, x);
> - SSL_CTX_clear_chain_certs(ctx)
> - and on subsequent certs SSL_CTX_add0_chain_cert(ctx, x)
>
> Yikes, down the rabbit hole...
>
> Did I get this right?
FTR: checked in the changes to ap_ssl_answer_challenge() to use PEM strings
instead of file names.
Changing the other function from file names to PEM would have a big impact von
the mod_ssl server
initialisation and I was not feeling strong enough for that.
I tested the change with a locally modified mod_md for correctness. Which means
my mistakes have not been found, yet.
If all these ap_ssl_* are acceptable, I will bring over a new mod_md to trunk
and - no one will be surprised by this - propose this for backporting to 2.4.x.
If you want the next release to not include such nonsense, I'd like to hold
back. Juggling too many repositories and branches is no fun.
Let me know what you think!
Cheers, Stefan
