> 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
>
> Regards
>
> Rüdiger
