On 3/3/21 1:05 PM, Stefan Eissing wrote:
>
>
>> 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?
Sounds sensible and for those who have them separate an apr_pstrcat will do.
Regards
Rüdiger
