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