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