> 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.
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);
