You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by ic...@apache.org on 2021/03/02 14:21:19 UTC

svn commit: r1887085 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_protocol.h modules/md/mod_md.c modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c modules/ssl/ssl_private.h server/protocol.c

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/CHANGES
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1887085&r1=1887084&r2=1887085&view=diff
==============================================================================
--- httpd/httpd/trunk/CHANGES [utf-8] (original)
+++ httpd/httpd/trunk/CHANGES [utf-8] Tue Mar  2 14:21:18 2021
@@ -23,6 +23,17 @@ Changes with Apache 2.5.1
        server/connection/request.
      - Hooks for 'ssl_conn_is_ssl' and 'ssl_var_lookup' where modules
        providing SSL can install their own value supplying functions.
+     - 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.
      [Stefan Eissing]
 
   *) mod_http2: new option 'H2OutputBuffering on/off' which controls the 

Modified: httpd/httpd/trunk/include/ap_mmn.h
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/include/ap_mmn.h?rev=1887085&r1=1887084&r2=1887085&view=diff
==============================================================================
--- httpd/httpd/trunk/include/ap_mmn.h (original)
+++ httpd/httpd/trunk/include/ap_mmn.h Tue Mar  2 14:21:18 2021
@@ -665,6 +665,7 @@
  * 20200705.4 (2.5.1-dev)  Add ap_get_status_line_ex()
  * 20201214.0 (2.5.1-dev)  Axe struct core_net_rec
  * 20201214.1 (2.5.1-dev)  Add ap_ssl_conn_is_ssl()/ap_ssl_var_lookup() and hooks
+ * 20201214.2 (2.5.1-dev)  Add ap_ssl_add_cert_files, ap_ssl_add_fallback_cert_files
  */
 
 #define MODULE_MAGIC_COOKIE 0x41503235UL /* "AP25" */
@@ -672,7 +673,7 @@
 #ifndef MODULE_MAGIC_NUMBER_MAJOR
 #define MODULE_MAGIC_NUMBER_MAJOR 20201214
 #endif
-#define MODULE_MAGIC_NUMBER_MINOR 1             /* 0...n */
+#define MODULE_MAGIC_NUMBER_MINOR 2             /* 0...n */
 
 /**
  * Determine if the server's current MODULE_MAGIC_NUMBER is at least a

Modified: httpd/httpd/trunk/include/http_protocol.h
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/include/http_protocol.h?rev=1887085&r1=1887084&r2=1887085&view=diff
==============================================================================
--- httpd/httpd/trunk/include/http_protocol.h (original)
+++ httpd/httpd/trunk/include/http_protocol.h Tue Mar  2 14:21:18 2021
@@ -1108,6 +1108,91 @@ AP_DECLARE(const char *) ap_ssl_var_look
                                            conn_rec *c, request_rec *r,
                                            const char *name);                                           
 
+/**
+ * Register to provide certificate/key files for servers. Certificate files are
+ * exepcted to contain the certificate chain, beginning with the server's certificate,
+ * excluding the trust anchor, in PEM format. 
+ * They must be accompanied by a private key file, also in PEM format.
+ *  
+ * @param s the server certificates are collected for
+ * @param p the pool to use for allocations
+ * @param cert_file and array of const char* with the path to the certificate chain
+ * @param key_file and array of const char* with the path to the private key file
+ * @return OK if files were added, DECLINED if not, or other for error.
+ */
+
+AP_DECLARE_HOOK(int, ssl_add_cert_files, (server_rec *s, apr_pool_t *p,
+                                          apr_array_header_t *cert_files,
+                                          apr_array_header_t *key_files))
+
+/**
+ * Collect certificate/key files from all providers registered. This includes
+ * providers registered at the global 'ssl_add_cert_files', as well as those
+ * installed in the OPTIONAL 'ssl_add_cert_files' hook as may be provided by 
+ * ssl modules.
+ *  
+ * @param s the server certificates are collected for
+ * @param p the pool to use for allocations
+ * @param cert_file and array of const char* with the path to the certificate chain
+ * @param key_file and array of const char* with the path to the private key file
+ */
+AP_DECLARE(apr_status_t) ap_ssl_add_cert_files(server_rec *s, apr_pool_t *p,
+                                               apr_array_header_t *cert_files,
+                                               apr_array_header_t *key_files);         
+
+
+/** 
+ * Register to provide 'fallback' certificates in case no 'real' certificates
+ * have been configured/added by other providers. Modules using these certificates
+ * are encouraged to answer requests to this server with a 503 response code.
+ * 
+ * @param s the server certificates are collected for
+ * @param p the pool to use for allocations
+ * @param cert_file and array of const char* with the path to the certificate chain
+ * @param key_file and array of const char* with the path to the private key file
+ * @return OK if files were added, DECLINED if not, or other for error.
+ */
+AP_DECLARE_HOOK(int, ssl_add_fallback_cert_files, (server_rec *s, apr_pool_t *p,
+                                                   apr_array_header_t *cert_files,
+                                                   apr_array_header_t *key_files))
+
+/**
+ * Collect 'fallback' certificate/key files from all registered providers, either
+ * in the global 'ssl_add_fallback_cert_files' hook or the optional one of similar
+ * name as provided by mod_ssl and sorts.
+ * Certificates obtained this way are commonly self signed, temporary crutches.
+ * To be used to the time it takes to retrieve a 'read', trusted certificate. 
+ * A module using fallbacks is encouraged to answer all requests with a 503.
+ * 
+ * @param s the server certificates are collected for
+ * @param p the pool to use for allocations
+ * @param cert_file and array of const char* with the path to the certificate chain
+ * @param key_file and array of const char* with the path to the private key file
+ */
+AP_DECLARE(apr_status_t) ap_ssl_add_fallback_cert_files(server_rec *s, apr_pool_t *p,
+                                                        apr_array_header_t *cert_files,
+                                                        apr_array_header_t *key_files);         
+
+
+/** 
+ * On TLS connections that do not relate to a configured virtual host,
+ * allow modules to provide a certificate and key to
+ * be used on the connection. 
+ */
+AP_DECLARE_HOOK(int, ssl_answer_challenge, (conn_rec *c, const char *server_name, 
+                                            const char **pcert_file, const char **pkey_file))
+
+/**
+ * Returns != 0 iff the connection is a challenge to the server, for example
+ * as defined in RFC 8555 for the 'tls-alpn-01' domain verification, and needs
+ * a specific certificate as answer in the handshake.
+ * ALPN protocol negotiation via the hooks 'protocol_propose' and 'protocol_switch'
+ * need to have run before this call is made.
+ */
+AP_DECLARE(int) ap_ssl_answer_challenge(conn_rec *c, const char *server_name, 
+                                        const char **pcert_file, const char **pkey_file);
+
+
 #ifdef __cplusplus
 }
 #endif

Modified: httpd/httpd/trunk/modules/md/mod_md.c
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/md/mod_md.c?rev=1887085&r1=1887084&r2=1887085&view=diff
==============================================================================
--- httpd/httpd/trunk/modules/md/mod_md.c (original)
+++ httpd/httpd/trunk/modules/md/mod_md.c Tue Mar  2 14:21:18 2021
@@ -1237,7 +1237,7 @@ static int md_answer_challenge(conn_rec
                                X509 **pcert, EVP_PKEY **pkey)
 {
     if (md_is_challenge(c, servername, pcert, pkey)) {
-        return APR_SUCCESS;
+        return OK;
     }
     return DECLINED;
 }

Modified: httpd/httpd/trunk/modules/ssl/ssl_engine_init.c
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_init.c?rev=1887085&r1=1887084&r2=1887085&view=diff
==============================================================================
--- httpd/httpd/trunk/modules/ssl/ssl_engine_init.c (original)
+++ httpd/httpd/trunk/modules/ssl/ssl_engine_init.c Tue Mar  2 14:21:18 2021
@@ -198,13 +198,18 @@ static void ssl_add_version_components(a
 */
 
 int ssl_is_challenge(conn_rec *c, const char *servername, 
-                     X509 **pcert, EVP_PKEY **pkey)
+                     X509 **pcert, EVP_PKEY **pkey,
+                     const char **pcert_file, const char **pkey_file)
 {
-    if (APR_SUCCESS == ssl_run_answer_challenge(c, servername, pcert, pkey)) {
-        return 1;
-    }
     *pcert = NULL;
     *pkey = NULL;
+    *pcert_file = *pkey_file = NULL;
+    if (ap_ssl_answer_challenge(c, servername, pcert_file, pkey_file)) {
+        return 1;
+    }
+    else if (OK == ssl_run_answer_challenge(c, servername, pcert, pkey)) {
+        return 1;
+    }
     return 0;
 }
 
@@ -1973,10 +1978,12 @@ static apr_status_t ssl_init_server_ctx(
     /* Allow others to provide certificate files */
     pks = sc->server->pks;
     n = pks->cert_files->nelts;
+    ap_ssl_add_cert_files(s, p, pks->cert_files, pks->key_files);
     ssl_run_add_cert_files(s, p, pks->cert_files, pks->key_files);
 
     if (apr_is_empty_array(pks->cert_files)) {
         /* does someone propose a certiciate to fall back on here? */
+        ap_ssl_add_fallback_cert_files(s, p, pks->cert_files, pks->key_files);
         ssl_run_add_fallback_cert_files(s, p, pks->cert_files, pks->key_files);
         if (n < pks->cert_files->nelts) {
             pks->service_unavailable = 1;

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) {
+            ap_log_cerror(APLOG_MARK, APLOG_WARNING, 0, c, APLOGNO()
+                          "Failed to configure challenge certificate %s",
+                          servername);
+            return APR_EGENERAL;
+        }
+        if (key_file == NULL) key_file = cert_file;
+        if (SSL_use_PrivateKey_file(ssl, key_file, SSL_FILETYPE_PEM) < 1) {
+            ap_log_cerror(APLOG_MARK, APLOG_WARNING, 0, c, APLOGNO()
+                          "Failed to configure challenge private key %s",
+                          servername);
+            return APR_EGENERAL;
+        }
+        goto check;
+    }
+    
     if ((SSL_use_certificate(ssl, cert) < 1)) {
         ap_log_cerror(APLOG_MARK, APLOG_WARNING, 0, c, APLOGNO(10086)
                       "Failed to configure challenge certificate %s",
@@ -2336,6 +2354,7 @@ static apr_status_t set_challenge_creds(
         return APR_EGENERAL;
     }
     
+check:
     if (SSL_check_private_key(ssl) < 1) {
         ap_log_cerror(APLOG_MARK, APLOG_WARNING, 0, c, APLOGNO(10088)
                       "Challenge certificate and private key %s "
@@ -2353,6 +2372,7 @@ static apr_status_t init_vhost(conn_rec
 {
     X509 *cert;
     EVP_PKEY *key;
+    const char *cert_file, *key_file;
     
     if (c) {
         SSLConnRec *sslcon = myConnConfig(c);
@@ -2376,11 +2396,12 @@ static apr_status_t init_vhost(conn_rec
                 sslcon->vhost_found = +1;
                 return APR_SUCCESS;
             }
-            else if (ssl_is_challenge(c, servername, &cert, &key)) {
+            else if (ssl_is_challenge(c, servername, &cert, &key, &cert_file, &key_file)) {
                 /* With ACMEv1 we can have challenge connections to a unknown domains
                  * that need to be answered with a special certificate and will
                  * otherwise not answer any requests. */
-                if (set_challenge_creds(c, servername, ssl, cert, key) != APR_SUCCESS) {
+                if (set_challenge_creds(c, servername, ssl, cert, key, 
+                                        cert_file, key_file) != APR_SUCCESS) {
                     return APR_EGENERAL;
                 }
                 SSL_set_verify(ssl, SSL_VERIFY_NONE, ssl_callback_SSLVerify);
@@ -2771,9 +2792,11 @@ int ssl_callback_alpn_select(SSL *ssl,
             const char *servername = SSL_get_servername(ssl, TLSEXT_NAMETYPE_host_name);
             X509 *cert;
             EVP_PKEY *key;
-            
-            if (ssl_is_challenge(c, servername, &cert, &key)) {
-                if (set_challenge_creds(c, servername, ssl, cert, key) != APR_SUCCESS) {
+            const char *cert_file, *key_file;
+
+            if (ssl_is_challenge(c, servername, &cert, &key, &cert_file, &key_file)) {
+                if (set_challenge_creds(c, servername, ssl, cert, key, 
+                                        cert_file, key_file) != APR_SUCCESS) {
                     return SSL_TLSEXT_ERR_ALERT_FATAL;
                 }
                 SSL_set_verify(ssl, SSL_VERIFY_NONE, ssl_callback_SSLVerify);

Modified: httpd/httpd/trunk/modules/ssl/ssl_private.h
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_private.h?rev=1887085&r1=1887084&r2=1887085&view=diff
==============================================================================
--- httpd/httpd/trunk/modules/ssl/ssl_private.h (original)
+++ httpd/httpd/trunk/modules/ssl/ssl_private.h Tue Mar  2 14:21:18 2021
@@ -1169,7 +1169,8 @@ extern int ssl_running_on_valgrind;
 #endif
 
 int ssl_is_challenge(conn_rec *c, const char *servername, 
-                     X509 **pcert, EVP_PKEY **pkey);
+                     X509 **pcert, EVP_PKEY **pkey,
+                    const char **pcert_file, const char **pkey_file);
 
 /* Set the renegotation state for connection. */
 void modssl_set_reneg_state(SSLConnRec *sslconn, modssl_reneg_state state);

Modified: httpd/httpd/trunk/server/protocol.c
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/server/protocol.c?rev=1887085&r1=1887084&r2=1887085&view=diff
==============================================================================
--- httpd/httpd/trunk/server/protocol.c (original)
+++ httpd/httpd/trunk/server/protocol.c Tue Mar  2 14:21:18 2021
@@ -72,6 +72,9 @@ APR_HOOK_STRUCT(
     APR_HOOK_LINK(protocol_get)
     APR_HOOK_LINK(ssl_conn_is_ssl)
     APR_HOOK_LINK(ssl_var_lookup)
+    APR_HOOK_LINK(ssl_add_cert_files) 
+    APR_HOOK_LINK(ssl_add_fallback_cert_files) 
+    APR_HOOK_LINK(ssl_answer_challenge) 
 )
 
 AP_DECLARE_DATA ap_filter_rec_t *ap_old_write_func = NULL;
@@ -2697,6 +2700,27 @@ AP_DECLARE(void) ap_setup_ssl_optional_f
     APR_REGISTER_OPTIONAL_FN(ssl_var_lookup);
 }
 
+AP_DECLARE(apr_status_t) ap_ssl_add_cert_files(server_rec *s, apr_pool_t *p,
+                                               apr_array_header_t *cert_files,
+                                               apr_array_header_t *key_files)
+{
+    int rv = ap_run_ssl_add_cert_files(s, p, cert_files, key_files);
+    return (rv == OK || rv == DECLINED)? APR_SUCCESS : APR_EGENERAL;
+}         
+
+AP_DECLARE(apr_status_t) ap_ssl_add_fallback_cert_files(server_rec *s, apr_pool_t *p,
+                                                        apr_array_header_t *cert_files,
+                                                        apr_array_header_t *key_files)
+{
+    int rv = ap_run_ssl_add_fallback_cert_files(s, p, cert_files, key_files);
+    return (rv == OK || rv == DECLINED)? APR_SUCCESS : APR_EGENERAL;
+}         
+
+AP_DECLARE(int) ap_ssl_answer_challenge(conn_rec *c, const char *server_name, 
+                                        const char **pcert_file, const char **pkey_file)
+{
+    return (ap_run_ssl_answer_challenge(c, server_name, pcert_file, pkey_file) == OK);
+}
 
 AP_IMPLEMENT_HOOK_VOID(pre_read_request,
                        (request_rec *r, conn_rec *c),
@@ -2728,3 +2752,15 @@ AP_IMPLEMENT_HOOK_RUN_FIRST(int, ssl_con
 AP_IMPLEMENT_HOOK_RUN_FIRST(const char *,ssl_var_lookup,
         (apr_pool_t *p, server_rec *s, conn_rec *c, request_rec *r, const char *name),
         (p, s, c, r, name), NULL)
+AP_IMPLEMENT_HOOK_RUN_ALL(int, ssl_add_cert_files, 
+        (server_rec *s, apr_pool_t *p, 
+         apr_array_header_t *cert_files, apr_array_header_t *key_files),
+        (s, p, cert_files, key_files), OK, DECLINED)
+AP_IMPLEMENT_HOOK_RUN_ALL(int, ssl_add_fallback_cert_files, 
+        (server_rec *s, apr_pool_t *p,
+         apr_array_header_t *cert_files, apr_array_header_t *key_files),
+        (s, p, cert_files, key_files), OK, DECLINED)
+AP_IMPLEMENT_HOOK_RUN_FIRST(int, ssl_answer_challenge, 
+        (conn_rec *c, const char *server_name, const char **pcert_file, const char **pkey_file),
+        (c, server_name, pcert_file, pkey_file), DECLINED)
+



Re: svn commit: r1887085 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_protocol.h modules/md/mod_md.c modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c modules/ssl/ssl_private.h server/protocol.c

Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Mar 3, 2021 at 11:17 AM Stefan Eissing
<st...@greenbytes.de> wrote:
>
> > Am 03.03.2021 um 11:14 schrieb Yann Ylavic <yl...@gmail.com>:
> >
> > Possibly apr_array_header_t could do it too:
> >  AP_DECLARE(int) ap_ssl_answer_challenge(conn_rec *c, const char
> > *server_name, const apr_array_header_t **pcertificate_key_pem);
> > ?
>
> as in apr_array_make(p, len, sizeof(char))?

IIIC, ap_ssl_answer_challenge() would populate pcertificate_key_pem,
so would be something like:

* caller:
    apr_array_header_t *pems = NULL;
    ap_ssl_answer_challenge(c, server_name, &pems);
    for (int i = 0; i < pems->nelts; ++i) {
        const char *pem = APR_ARRAY_IDX(pems, i, const char*);
        /* play with pem */
    }

* ap_ssl_answer_challenge(apr_array_header_t **ppems):
    apr_array_header_t *pems = *ppems =
        apr_array_make(p, 10, sizeof(const char*));
    foreach pem from ssl structure {
        APR_ARRAY_PUSH(pems, const char *) = pem;
    }

or so..

Re: svn commit: r1887085 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_protocol.h modules/md/mod_md.c modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c modules/ssl/ssl_private.h server/protocol.c

Posted by Stefan Eissing <st...@greenbytes.de>.

> Am 03.03.2021 um 11:14 schrieb Yann Ylavic <yl...@gmail.com>:
> 
> On Wed, Mar 3, 2021 at 11:02 AM Stefan Eissing
> <st...@greenbytes.de> wrote:
>> 
>> Good that there is Rüdiger!
> 
> +1
> 
>> 
>> 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);
> 
> Possibly apr_array_header_t could do it too:
>  AP_DECLARE(int) ap_ssl_answer_challenge(conn_rec *c, const char
> *server_name, const apr_array_header_t **pcertificate_key_pem);
> ?

as in apr_array_make(p, len, sizeof(char))?

Re: svn commit: r1887085 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_protocol.h modules/md/mod_md.c modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c modules/ssl/ssl_private.h server/protocol.c

Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Mar 3, 2021 at 11:02 AM Stefan Eissing
<st...@greenbytes.de> wrote:
>
> Good that there is Rüdiger!

+1

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

Possibly apr_array_header_t could do it too:
  AP_DECLARE(int) ap_ssl_answer_challenge(conn_rec *c, const char
*server_name, const apr_array_header_t **pcertificate_key_pem);
?

Re: svn commit: r1887085 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_protocol.h modules/md/mod_md.c modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c modules/ssl/ssl_private.h server/protocol.c

Posted by Stefan Eissing <st...@greenbytes.de>.

> Am 03.03.2021 um 11:25 schrieb Stefan Eissing <st...@greenbytes.de>:
> 
> 
> 
>> Am 03.03.2021 um 11:17 schrieb Ruediger Pluem <rp...@apache.org>:
>> 
>> 
>> 
>> On 3/3/21 11:01 AM, Stefan Eissing wrote:
>>> 
>>> 
>>>> Am 03.03.2021 um 10:44 schrieb Stefan Eissing <st...@greenbytes.de>:
>>>> 
>>>> 
>>>> 
>>>>> Am 03.03.2021 um 10:31 schrieb Ruediger Pluem <rp...@apache.org>:
>>>>> 
>>>>> 
>>>>> 
>>>>> On 3/3/21 9:54 AM, Stefan Eissing wrote:
>>>>>>> Am 03.03.2021 um 09:35 schrieb Stefan Eissing <st...@greenbytes.de>:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> Am 02.03.2021 um 20:54 schrieb Ruediger Pluem <rp...@apache.org>:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 3/2/21 3:21 PM, icing@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.


Re: svn commit: r1887085 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_protocol.h modules/md/mod_md.c modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c modules/ssl/ssl_private.h server/protocol.c

Posted by Ruediger Pluem <rp...@apache.org>.

On 3/3/21 1:05 PM, Stefan Eissing wrote:
> 
> 
>> Am 03.03.2021 um 11:36 schrieb Ruediger Pluem <rp...@apache.org>:
>>
>>
>>
>> On 3/3/21 11:25 AM, Stefan Eissing wrote:
>>>
>>>
>>>> Am 03.03.2021 um 11:17 schrieb Ruediger Pluem <rp...@apache.org>:
>>>>
>>>>
>>>>
>>>> On 3/3/21 11:01 AM, Stefan Eissing wrote:
>>>>>
>>>>>
>>>>>> Am 03.03.2021 um 10:44 schrieb Stefan Eissing <st...@greenbytes.de>:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Am 03.03.2021 um 10:31 schrieb Ruediger Pluem <rp...@apache.org>:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 3/3/21 9:54 AM, Stefan Eissing wrote:
>>>>>>>>> Am 03.03.2021 um 09:35 schrieb Stefan Eissing <st...@greenbytes.de>:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Am 02.03.2021 um 20:54 schrieb Ruediger Pluem <rp...@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?

Sounds sensible and for those who have them separate an apr_pstrcat will do.

Regards

Rüdiger

Re: svn commit: r1887085 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_protocol.h modules/md/mod_md.c modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c modules/ssl/ssl_private.h server/protocol.c

Posted by Stefan Eissing <st...@greenbytes.de>.

> Am 03.03.2021 um 13:05 schrieb Stefan Eissing <st...@greenbytes.de>:
> 
> 
> 
>> Am 03.03.2021 um 11:36 schrieb Ruediger Pluem <rp...@apache.org>:
>> 
>> 
>> 
>> On 3/3/21 11:25 AM, Stefan Eissing wrote:
>>> 
>>> 
>>>> Am 03.03.2021 um 11:17 schrieb Ruediger Pluem <rp...@apache.org>:
>>>> 
>>>> 
>>>> 
>>>> On 3/3/21 11:01 AM, Stefan Eissing wrote:
>>>>> 
>>>>> 
>>>>>> Am 03.03.2021 um 10:44 schrieb Stefan Eissing <st...@greenbytes.de>:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> Am 03.03.2021 um 10:31 schrieb Ruediger Pluem <rp...@apache.org>:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On 3/3/21 9:54 AM, Stefan Eissing wrote:
>>>>>>>>> Am 03.03.2021 um 09:35 schrieb Stefan Eissing <st...@greenbytes.de>:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> Am 02.03.2021 um 20:54 schrieb Ruediger Pluem <rp...@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?

FTR: checked in the changes to ap_ssl_answer_challenge() to use PEM strings instead of file names.
Changing the other function from file names to PEM would have a big impact von the mod_ssl server
initialisation and I was not feeling strong enough for that.

I tested the change with a locally modified mod_md for correctness. Which means my mistakes have not been found, yet.

If all these ap_ssl_* are acceptable, I will bring over a new mod_md to trunk and - no one will be surprised by this - propose this for backporting to 2.4.x.

If you want the next release to not include such nonsense, I'd like to hold back. Juggling too many repositories and branches is no fun.

Let me know what you think!

Cheers, Stefan





Re: svn commit: r1887085 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_protocol.h modules/md/mod_md.c modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c modules/ssl/ssl_private.h server/protocol.c

Posted by Stefan Eissing <st...@greenbytes.de>.

> Am 03.03.2021 um 11:36 schrieb Ruediger Pluem <rp...@apache.org>:
> 
> 
> 
> On 3/3/21 11:25 AM, Stefan Eissing wrote:
>> 
>> 
>>> Am 03.03.2021 um 11:17 schrieb Ruediger Pluem <rp...@apache.org>:
>>> 
>>> 
>>> 
>>> On 3/3/21 11:01 AM, Stefan Eissing wrote:
>>>> 
>>>> 
>>>>> Am 03.03.2021 um 10:44 schrieb Stefan Eissing <st...@greenbytes.de>:
>>>>> 
>>>>> 
>>>>> 
>>>>>> Am 03.03.2021 um 10:31 schrieb Ruediger Pluem <rp...@apache.org>:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 3/3/21 9:54 AM, Stefan Eissing wrote:
>>>>>>>> Am 03.03.2021 um 09:35 schrieb Stefan Eissing <st...@greenbytes.de>:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> Am 02.03.2021 um 20:54 schrieb Ruediger Pluem <rp...@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



Re: svn commit: r1887085 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_protocol.h modules/md/mod_md.c modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c modules/ssl/ssl_private.h server/protocol.c

Posted by Ruediger Pluem <rp...@apache.org>.

On 3/3/21 11:25 AM, Stefan Eissing wrote:
> 
> 
>> Am 03.03.2021 um 11:17 schrieb Ruediger Pluem <rp...@apache.org>:
>>
>>
>>
>> On 3/3/21 11:01 AM, Stefan Eissing wrote:
>>>
>>>
>>>> Am 03.03.2021 um 10:44 schrieb Stefan Eissing <st...@greenbytes.de>:
>>>>
>>>>
>>>>
>>>>> Am 03.03.2021 um 10:31 schrieb Ruediger Pluem <rp...@apache.org>:
>>>>>
>>>>>
>>>>>
>>>>> On 3/3/21 9:54 AM, Stefan Eissing wrote:
>>>>>>> Am 03.03.2021 um 09:35 schrieb Stefan Eissing <st...@greenbytes.de>:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Am 02.03.2021 um 20:54 schrieb Ruediger Pluem <rp...@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

Re: svn commit: r1887085 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_protocol.h modules/md/mod_md.c modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c modules/ssl/ssl_private.h server/protocol.c

Posted by Stefan Eissing <st...@greenbytes.de>.

> Am 03.03.2021 um 11:17 schrieb Ruediger Pluem <rp...@apache.org>:
> 
> 
> 
> On 3/3/21 11:01 AM, Stefan Eissing wrote:
>> 
>> 
>>> Am 03.03.2021 um 10:44 schrieb Stefan Eissing <st...@greenbytes.de>:
>>> 
>>> 
>>> 
>>>> Am 03.03.2021 um 10:31 schrieb Ruediger Pluem <rp...@apache.org>:
>>>> 
>>>> 
>>>> 
>>>> On 3/3/21 9:54 AM, Stefan Eissing wrote:
>>>>>> Am 03.03.2021 um 09:35 schrieb Stefan Eissing <st...@greenbytes.de>:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> Am 02.03.2021 um 20:54 schrieb Ruediger Pluem <rp...@apache.org>:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On 3/2/21 3:21 PM, icing@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


Re: svn commit: r1887085 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_protocol.h modules/md/mod_md.c modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c modules/ssl/ssl_private.h server/protocol.c

Posted by Ruediger Pluem <rp...@apache.org>.

On 3/3/21 11:01 AM, Stefan Eissing wrote:
> 
> 
>> Am 03.03.2021 um 10:44 schrieb Stefan Eissing <st...@greenbytes.de>:
>>
>>
>>
>>> Am 03.03.2021 um 10:31 schrieb Ruediger Pluem <rp...@apache.org>:
>>>
>>>
>>>
>>> On 3/3/21 9:54 AM, Stefan Eissing wrote:
>>>>> Am 03.03.2021 um 09:35 schrieb Stefan Eissing <st...@greenbytes.de>:
>>>>>
>>>>>
>>>>>
>>>>>> Am 02.03.2021 um 20:54 schrieb Ruediger Pluem <rp...@apache.org>:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 3/2/21 3:21 PM, icing@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?

2. As there is only one ap_bytes ** above, do you want to merge the PEM encoded certificate and key in one string?

Regards

Rüdiger

Re: svn commit: r1887085 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_protocol.h modules/md/mod_md.c modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c modules/ssl/ssl_private.h server/protocol.c

Posted by Stefan Eissing <st...@greenbytes.de>.

> Am 03.03.2021 um 10:44 schrieb Stefan Eissing <st...@greenbytes.de>:
> 
> 
> 
>> Am 03.03.2021 um 10:31 schrieb Ruediger Pluem <rp...@apache.org>:
>> 
>> 
>> 
>> On 3/3/21 9:54 AM, Stefan Eissing wrote:
>>>> Am 03.03.2021 um 09:35 schrieb Stefan Eissing <st...@greenbytes.de>:
>>>> 
>>>> 
>>>> 
>>>>> Am 02.03.2021 um 20:54 schrieb Ruediger Pluem <rp...@apache.org>:
>>>>> 
>>>>> 
>>>>> 
>>>>> On 3/2/21 3:21 PM, icing@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);



Re: svn commit: r1887085 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_protocol.h modules/md/mod_md.c modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c modules/ssl/ssl_private.h server/protocol.c

Posted by Ruediger Pluem <rp...@apache.org>.

On 3/3/21 10:44 AM, Stefan Eissing wrote:
> 
> 
>> Am 03.03.2021 um 10:31 schrieb Ruediger Pluem <rp...@apache.org>:
>>
>>
>>
>> On 3/3/21 9:54 AM, Stefan Eissing wrote:
>>>> Am 03.03.2021 um 09:35 schrieb Stefan Eissing <st...@greenbytes.de>:
>>>>
>>>>
>>>>
>>>>> Am 02.03.2021 um 20:54 schrieb Ruediger Pluem <rp...@apache.org>:
>>>>>
>>>>>
>>>>>
>>>>> On 3/2/21 3:21 PM, icing@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?

Sounds like an option.

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

I see the issue you point out with regards to the **void pointers. How about two additional **char that allow the the hook to
return pointers to a PEM encoded string? Of course that would not solve cases where the key is stored in a special device that
does not expose it but only allow it to be used for encryption / decryption.

Regards

Rüdiger


Re: svn commit: r1887085 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_protocol.h modules/md/mod_md.c modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c modules/ssl/ssl_private.h server/protocol.c

Posted by Stefan Eissing <st...@greenbytes.de>.

> Am 03.03.2021 um 10:31 schrieb Ruediger Pluem <rp...@apache.org>:
> 
> 
> 
> On 3/3/21 9:54 AM, Stefan Eissing wrote:
>>> Am 03.03.2021 um 09:35 schrieb Stefan Eissing <st...@greenbytes.de>:
>>> 
>>> 
>>> 
>>>> Am 02.03.2021 um 20:54 schrieb Ruediger Pluem <rp...@apache.org>:
>>>> 
>>>> 
>>>> 
>>>> On 3/2/21 3:21 PM, icing@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


Re: svn commit: r1887085 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_protocol.h modules/md/mod_md.c modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c modules/ssl/ssl_private.h server/protocol.c

Posted by Ruediger Pluem <rp...@apache.org>.

On 3/3/21 9:54 AM, Stefan Eissing wrote:
>> Am 03.03.2021 um 09:35 schrieb Stefan Eissing <st...@greenbytes.de>:
>>
>>
>>
>>> Am 02.03.2021 um 20:54 schrieb Ruediger Pluem <rp...@apache.org>:
>>>
>>>
>>>
>>> On 3/2/21 3:21 PM, icing@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.

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?

Regards

Rüdiger



Re: svn commit: r1887085 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_protocol.h modules/md/mod_md.c modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c modules/ssl/ssl_private.h server/protocol.c

Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 03.03.2021 um 09:35 schrieb Stefan Eissing <st...@greenbytes.de>:
> 
> 
> 
>> Am 02.03.2021 um 20:54 schrieb Ruediger Pluem <rp...@apache.org>:
>> 
>> 
>> 
>> On 3/2/21 3:21 PM, icing@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.

> 
>> Regards
>> 
>> Rüdiger


Re: svn commit: r1887085 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_protocol.h modules/md/mod_md.c modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c modules/ssl/ssl_private.h server/protocol.c

Posted by Stefan Eissing <st...@greenbytes.de>.

> Am 02.03.2021 um 20:54 schrieb Ruediger Pluem <rp...@apache.org>:
> 
> 
> 
> On 3/2/21 3:21 PM, icing@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?

> Regards
> 
> Rüdiger


Re: svn commit: r1887085 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_protocol.h modules/md/mod_md.c modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c modules/ssl/ssl_private.h server/protocol.c

Posted by Ruediger Pluem <rp...@apache.org>.

On 3/2/21 3:21 PM, icing@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.

Regards

Rüdiger