> Am 03.03.2021 um 11:25 schrieb Stefan Eissing <stefan.eiss...@greenbytes.de>:
>
>
>
>> 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>:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 3/2/21 3:21 PM, ic...@apache.org wrote:
>>>>>>>>> Author: icing
>>>>>>>>> Date: Tue Mar 2 14:21:18 2021
>>>>>>>>> New Revision: 1887085
>>>>>>>>>
>>>>>>>>> URL: http://svn.apache.org/viewvc?rev=1887085&view=rev
>>>>>>>>> Log:
>>>>>>>>> Adding more ap_ssl_* functions and hooks to the core server.
>>>>>>>>>
>>>>>>>>> - ap_ssl_add_cert_files() to enable other modules like mod_md to
>>>>>>>>> provide
>>>>>>>>> certificate and keys for an SSL module like mod_ssl.
>>>>>>>>> - ap_ssl_add_fallback_cert_files() to enable other modules like
>>>>>>>>> mod_md to
>>>>>>>>> provide a fallback certificate in case no 'proper' certificate is
>>>>>>>>> available for an SSL module like mod_ssl.
>>>>>>>>> - ap_ssl_answer_challenge() to enable other modules like mod_md to
>>>>>>>>> provide a certificate as used in the RFC 8555 'tls-alpn-01' challenge
>>>>>>>>> for the ACME protocol for an SSL module like mod_ssl.
>>>>>>>>> - Hooks for 'ssl_add_cert_files', 'ssl_add_fallback_cert_files' and
>>>>>>>>> 'ssl_answer_challenge' where modules like mod_md can provide providers
>>>>>>>>> to the above mentioned functions.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Modified:
>>>>>>>>> httpd/httpd/trunk/CHANGES
>>>>>>>>> httpd/httpd/trunk/include/ap_mmn.h
>>>>>>>>> httpd/httpd/trunk/include/http_protocol.h
>>>>>>>>> httpd/httpd/trunk/modules/md/mod_md.c
>>>>>>>>> httpd/httpd/trunk/modules/ssl/ssl_engine_init.c
>>>>>>>>> httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c
>>>>>>>>> httpd/httpd/trunk/modules/ssl/ssl_private.h
>>>>>>>>> httpd/httpd/trunk/server/protocol.c
>>>>>>>>>
>>>>>>>>
>>>>>>>>> Modified: httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c
>>>>>>>>> URL:
>>>>>>>>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c?rev=1887085&r1=1887084&r2=1887085&view=diff
>>>>>>>>> ==============================================================================
>>>>>>>>> --- httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c (original)
>>>>>>>>> +++ httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c Tue Mar 2
>>>>>>>>> 14:21:18 2021
>>>>>>>>> @@ -2316,11 +2316,29 @@ void ssl_callback_Info(const SSL *ssl, i
>>>>>>>>> #ifdef HAVE_TLSEXT
>>>>>>>>>
>>>>>>>>> static apr_status_t set_challenge_creds(conn_rec *c, const char
>>>>>>>>> *servername,
>>>>>>>>> - SSL *ssl, X509 *cert,
>>>>>>>>> EVP_PKEY *key)
>>>>>>>>> + SSL *ssl, X509 *cert,
>>>>>>>>> EVP_PKEY *key,
>>>>>>>>> + const char *cert_file, const
>>>>>>>>> char *key_file)
>>>>>>>>> {
>>>>>>>>> SSLConnRec *sslcon = myConnConfig(c);
>>>>>>>>>
>>>>>>>>> sslcon->service_unavailable = 1;
>>>>>>>>> + if (cert_file) {
>>>>>>>>> + if (SSL_use_certificate_chain_file(ssl, cert_file) < 1) {
>>>>>>>>
>>>>>>>> As noted by the failure of build #1461 (
>>>>>>>> https://travis-ci.com/github/apache/httpd/jobs/487481449)
>>>>>>>> SSL_use_certificate_chain_file is not available with OpenSSL 1.0.2
>>>>>>>> which is still the OS
>>>>>>>> provided standard version with Ubuntu 16 LTS and RedHat / Centos 7.
>>>>>>>
>>>>>>> Is there a known alternative?
>>>>>>
>>>>>> Will use SSL_use_certificate_file() there which is available in 1.0.2.
>>>>>
>>>>> Two questions:
>>>>>
>>>>> 1. Do SSL_use_certificate_file and SSL_use_certificate_chain_file do the
>>>>> same thing? My understanding of the documentation is that
>>>>> SSL_use_certificate_chain_file loads a certificate chain (and just a
>>>>> chain) from the file while SSL_use_certificate_file loads
>>>>> just a certificate.
>>>>
>>>> In my testing, they both do the same when the file contains only a
>>>> self-signed certificate. Which is the use case with ACME.
>>>>
>>>> But you are correct, as the documentation says
>>>> "SSL_CTX_use_certificate_file() loads the first certificate stored in file
>>>> into ctx.". And "SSL_CTX_use_certificate_chain_file" loads a complete
>>>> chain, starting with the client/server certificate.#
>>>>
>>>> So, ideally, we'd want to call SSL_use_certificate_chain_file(), because
>>>> it is more flexible. The ACME use case can live with the less potent call
>>>> available in 1.0.2.
>>>>
>>>> Maybe we should "#if version >= 1.1" and use the better one then?
>>>>
>>>>>
>>>>> 2. Is it a good idea that consumers of the ssl_answer_challenge hook can
>>>>> only provide certs and keys via files? What if these are
>>>>> not stored in a file? Would it be an option to have the hook return a
>>>>> **void for the cert and a **void for the key in addition
>>>>> that can be NULL or that in the OpenSSL case contain a **X509 and
>>>>> **EVP_PKEY?
>>>>
>>>> I was thinking about that. But imagine a scenario where a server has 2 SSL
>>>> modules loaded. What would the "void*" be for? How could a module given a
>>>> value in it know it's safe to use?
>>>>
>>>> Besides PEM files, the only other portable way I can think of are DER
>>>> bytes.
>>>>
>>>> I opted for files, since those do exists in the mod_md ACME case already
>>>> and so it was easy to do. Not the best design criteria, but not the worst
>>>> either.
>>>>
>>>> - Stefan
>>>
>>> Good that there is Rüdiger!
>>>
>>> Thinking about this: how much work would it be for mod_ssl to accept PEM
>>> bytes? That would make the exchange of certificate independent of the file
>>> system and portable.
>>
>> I guess PEM_read_bio_X509 / PEM_read_bio_RSAPrivateKey could do the job with
>> a BIO created via BIO_new_mem_buf.
>>
>>>
>>> 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 case 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.
>
>> 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...
But I am not strongly opinioned about this. We could have 2 "const char **"
cert+key and when key is NULL, use cert also as PEM for the key.
