Bug 62232 - AH01962: Unable to create a new SSL connection from the SSL context for proxy connections when using SSLRequire
Summary: AH01962: Unable to create a new SSL connection from the SSL context for proxy...
Status: RESOLVED FIXED
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_ssl (show other bugs)
Version: 2.4.32
Hardware: PC Linux
: P2 major (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: FixedInTrunk
Depends on:
Blocks:
 
Reported: 2018-03-29 15:47 UTC by mark
Modified: 2018-06-18 22:20 UTC (History)
0 users



Attachments
tcpdump trace of comms with backend server (894 bytes, text/plain)
2018-03-30 21:04 UTC, mark
Details
directly coincident error log messages on apache associated with packets (6.26 KB, text/plain)
2018-03-30 21:05 UTC, mark
Details

Note You need to log in before you can comment on or make changes to this bug.
Description mark 2018-03-29 15:47:00 UTC
We are seeing the following messages for proxy connections to backend servers after upgrading from apache 2.4.29 to apache 2.4.32 (the one not formally announced).

[Thu Mar 29 17:38:52.213263 2018] [ssl:error] [pid 35774:tid 139793802262272] [remote 10.198.2.44:11472] AH01962: Unable to create a new SSL connection from the SSL context
[Thu Mar 29 17:38:52.213299 2018] [ssl:error] [pid 35774:tid 139793802262272] SSL Library Error: error:140BA0C3:SSL routines:SSL_new:null ssl ctx

Here's the SSL-specific config..

    193021: <VirtualHost 10.216.21.20:13595>
    193037:   SSLEngine on
    193038:   SSLProtocol ALL -SSLv2 -SSLv3
    193040:   SSLHonorCipherOrder on
    193044:   SSLCipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256:OLD_TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256:TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH-RC4:RSA-RC4!MD5
    193045:   SSLCompression off
    193047:   SSLCertificateKeyFile /somepath/ssl/ssl.key
    193048:   SSLCertificateFile /somepath/ssl/ssl.cert
    193049:   SSLCACertificateFile /somepath/ssl/ssl.ca
    193050:   SSLProxyCheckPeerName off
    193053:   <FilesMatch "\.(cgi|shtml|pl|phtml|php3?)$">
    193054:     SSLOptions +StdEnvVars
        :   </FilesMatch>
    193247:   SSLProxyProtocol TLSv1 -SSLv2 -SSLv3
    193251:   SSLVerifyClient require
    193252:   SSLVerifyDepth 2
    193253:   SSLCACertificateFile /somepath/ssl/ssl.ca
    193254:   <Location "/">
    193255:     SSLRequire ((%{SSL_CLIENT_I_DN_OU} eq "AAA") and (%{SSL_CLIENT_S_DN_O} eq "BBB")) or ((%{SSL_CLIENT_I_DN_OU} eq "CCC") and (%{SSL_CLIENT_S_DN_O} eq "DDD"))
        :   </Location>
        : </VirtualHost>

I suspect some of the SSLProxy changes between .29 and .32 are contributing but can't decide what  exactly.
Comment 1 Yann Ylavic 2018-03-29 17:43:14 UTC
How are proxies declared with regard to this VirtualHost, globally?
Could you please share a sample of that config too (ProxyPass, RewriteRule, ...)?
Comment 2 mark 2018-03-30 17:53:32 UTC
mod_proxy:

    192930: <VirtualHost 10.216.21.20:13595>
    193100:   <Proxy balancer://balancer1>
    193101:     BalancerMember https://server45.example.com:11472 route=int2-s2-0
    193102:     BalancerMember https://server46.example.com:11472 route=int2-s2-1
    193103:     ProxySet stickysession=JSESSIONID|jsessionid
    193104:     ProxySet scolonpathdelim=On
    193105:     ProxySet lbmethod=byrequests
    193106:     ProxySet forcerecovery=On
        :   </Proxy>
    193122:   ProxyPass /EcmsDmWebService balancer://balancer1/EcmsDmWebService
    193123:   ProxyPassReverse /EcmsDmWebService balancer://balancer1/EcmsDmWebService
    193124:   <Location /EcmsDmWebService>
    193125:     ProxyPassReverseCookiePath /EcmsDmWebService /EcmsDmWebService
        :   </Location>
    193130:   ProxyPass /EcmsDmRestful balancer://balancer1/EcmsDmRestful
    193131:   ProxyPassReverse /EcmsDmRestful balancer://balancer1/EcmsDmRestful
    193132:   <Location /EcmsDmRestful>
    193133:     ProxyPassReverseCookiePath /EcmsDmRestful /EcmsDmRestful
        :   </Location>
    193138:   ProxyPass /EcmsDmBootControlService balancer://balancer1/EcmsDmBootControlService
    193139:   ProxyPassReverse /EcmsDmBootControlService balancer://balancer1/EcmsDmBootControlService
    193140:   <Location /EcmsDmBootControlService>
    193141:     ProxyPassReverseCookiePath /EcmsDmBootControlService /EcmsDmBootControlService
        :   </Location>
    193146:   ProxyPass /ebstoolbox balancer://balancer1/ebstoolbox
    193147:   ProxyPassReverse /ebstoolbox balancer://balancer1/ebstoolbox
    193148:   <Location /ebstoolbox>
    193149:     ProxyPassReverseCookiePath /ebstoolbox /ebstoolbox
        :   </Location>
        : </VirtualHost>
Comment 3 mark 2018-03-30 17:57:01 UTC
The error messages make me think there's some new certificate enforcement behaviour kicking associated with CheckPeerName or CheckPeerCN for the proxy connection to the backend.
Comment 4 mark 2018-03-30 21:04:57 UTC
Created attachment 35828 [details]
tcpdump trace of comms with backend server
Comment 5 mark 2018-03-30 21:05:46 UTC
Created attachment 35829 [details]
directly coincident error log messages on apache associated with packets
Comment 6 mark 2018-03-30 21:08:29 UTC
I can see from the tcpdump trace, that no actual data is being sent to the backend server. The TCP connection is opened and then shut down shortly afterward. So whatever is triggering the closure is NOT related to the backend server. 

This reinforces the impression that somehow the TLS context is null when it gets passed down to the OpenSSL libraries and the issue lies in understanding how it gets a null TLS context.  

How is the TLS context for the Apache side of the proxy connection derived? I always assume it was taken by default from the server side?
Comment 7 mark 2018-03-31 12:56:42 UTC
For now, I will focus on reproducing in a lab environment and get back to you when I can fiddle with it more readily.
Comment 8 Rainer Jung 2018-03-31 17:12:57 UTC
Thanks for the info and yes, a simpler reproduction scenario would help a lot.

Likely the breakage is due to the new feature "mod_proxy, mod_ssl: Handle SSLProxy* directives in <Proxy> sections, allowing per backend TLS configuration." 

Proxy SSL contexts were always managed separately from the frontend ssl contexts, but with that change their management got a major refactoring.

Since we successfully ran the test suire, it didn't break the proxy plus ssl setup in general and we need to find out, what might be special in your setup.
Comment 9 mark 2018-03-31 19:37:41 UTC
I've now reproduced this effect in a lab environment and I can demonstrate that removing the SSLRequire line produces success, so it's the presence of the SSLRequire line that triggers the bug, possibly  in conjunction with other elmements that have remained. I will peer at the code for elucidation but I am not hopeful.


Any theories why SSLRequire could trigger a null ctx?

I will fiddle variations of that line to see if they exact form of SSLRequire matters.
Comment 10 mark 2018-03-31 19:48:51 UTC
No matter how simple I make the SSLRequire expression, the bug remains. However, if I use the Require expr syntax instead, the bug disappears and the proxy connection is made, no matter how complicated the expression.
Comment 11 Rainer Jung 2018-03-31 20:19:40 UTC
Hi Mark,

does it make a difference whether you put the SSLRequire into the <Location> section or directly into the VirtualHost without Location?
Comment 12 mark 2018-03-31 20:27:49 UTC
"SSLRequire not allowed in <VirtualHost> context"

I am guessing that the SSLRequire expression is being evaluated inappropriately in the proxy connection setup.
Comment 13 Rainer Jung 2018-03-31 20:53:59 UTC
Yes, sorry. I can though reproduce your symptoms.
Comment 14 Rainer Jung 2018-03-31 21:40:02 UTC
Pretty simple reproduction scenario. I used OpenSSL 1.0.2n:

Loaded modules:

LoadModule mpm_event_module modules/mod_mpm_event.so
LoadModule authn_core_module modules/mod_authn_core.so
LoadModule authz_core_module modules/mod_authz_core.so
LoadModule socache_shmcb_module modules/mod_socache_shmcb.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule slotmem_shm_module modules/mod_slotmem_shm.so
LoadModule ssl_module modules/mod_ssl.so
LoadModule unixd_module modules/mod_unixd.so

httpd.conf default (except for LogLevel trace8) and includes:

Define APACHE_BASE /path/to/my/apache/instance

# Taken from the default conf/extra/httpd-ssl.conf
SSLCipherSuite HIGH:MEDIUM:!MD5:!RC4:!3DES
SSLProxyCipherSuite HIGH:MEDIUM:!MD5:!RC4:!3DES
SSLHonorCipherOrder on
SSLProtocol all -SSLv3
SSLProxyProtocol all -SSLv3
SSLPassPhraseDialog  builtin
SSLSessionCache        "shmcb:${APACHE_BASE}/logs/ssl_scache(512000)"
SSLSessionCacheTimeout  300

Listen *:9543
<VirtualHost *:9543>
    SSLEngine on
    SSLCertificateFile "${APACHE_BASE}/conf/server.crt"
    SSLCertificateKeyFile "${APACHE_BASE}/conf/server.key"
    SSLCACertificateFile "${APACHE_BASE}/conf/ca-bundle.crt"
    SSLProxyEngine On
    SSLProxyVerify none
    SSLProxyCheckPeerName off
    <Location "/">
        SSLOptions StdEnvVars
    </Location>
    ProxyPass /test https://localhost:9544
</VirtualHost>

Listen *:9544
<VirtualHost *:9544>
    SSLEngine on
    SSLCertificateFile "${APACHE_BASE}/conf/server.crt"
    SSLCertificateKeyFile "${APACHE_BASE}/conf/server.key"
    SSLCACertificateFile "${APACHE_BASE}/conf/ca-bundle.crt"
</VirtualHost>

And to strenghten Mark's last comment: as soon as I add any mod_ssl directive (which is allowed in directory context) to the Location section, I see the same error messages as Mark. I have chosen above SSLOptions , because it is simpler then SSLRequire and also allowed in the VirtualHost directly. If I put the SSLOptions instead into the VirtualHost or a <Proxy> section, the problem vanishes.

So we have a problem with per directory ssl config creation and merging, maybe only for proxy.

For the sake of completeness here again the error log lines (return code is 502 Bad Gateway):

[Sat Mar 31 23:35:07.771391 2018] [proxy:debug] [pid 6276:tid 6] mod_proxy.c(1239): [client 127.0.0.1:45669] AH01143: Running scheme https handler (attempt 0)
[Sat Mar 31 23:35:07.771436 2018] [proxy_http:trace1] [pid 6276:tid 6] mod_proxy_http.c(1904): [client 127.0.0.1:45669] HTTP: serving URL https://localhost:9544/
[Sat Mar 31 23:35:07.771472 2018] [proxy:debug] [pid 6276:tid 6] proxy_util.c(2162): AH00942: HTTPS: has acquired connection for (localhost)
[Sat Mar 31 23:35:07.771519 2018] [proxy:debug] [pid 6276:tid 6] proxy_util.c(2215): [client 127.0.0.1:45669] AH00944: connecting https://localhost:9544/ to localhost:9544
[Sat Mar 31 23:35:07.772590 2018] [proxy:debug] [pid 6276:tid 6] proxy_util.c(2424): [client 127.0.0.1:45669] AH00947: connected / to localhost:9544
[Sat Mar 31 23:35:07.772759 2018] [proxy:trace2] [pid 6276:tid 6] proxy_util.c(2859): HTTPS: fam 2 socket created to connect to localhost
[Sat Mar 31 23:35:07.773036 2018] [proxy:debug] [pid 6276:tid 6] proxy_util.c(2893): AH02824: HTTPS: connection established with 127.0.0.1:9544 (localhost)
[Sat Mar 31 23:35:07.773559 2018] [proxy:debug] [pid 6276:tid 6] proxy_util.c(3061): AH00962: HTTPS: connection complete to 127.0.0.1:9544 (localhost)
[Sat Mar 31 23:35:07.773603 2018] [ssl:info] [pid 6276:tid 6] [remote 127.0.0.1:9544] AH01964: Connection to child 0 established (server 195.227.30.235:9543)
[Sat Mar 31 23:35:07.773694 2018] [ssl:trace2] [pid 6276:tid 6] ssl_engine_rand.c(126): Proxy: Seeding PRNG with 136 bytes of entropy
[Sat Mar 31 23:35:07.773729 2018] [ssl:error] [pid 6276:tid 6] [remote 127.0.0.1:9544] AH01962: Unable to create a new SSL connection from the SSL context
[Sat Mar 31 23:35:07.773764 2018] [ssl:info] [pid 6277:tid 27] [client 127.0.0.1:45670] AH01964: Connection to child 152 established (server 195.227.30.235:9544)
[Sat Mar 31 23:35:07.773904 2018] [ssl:error] [pid 6276:tid 6] SSL Library Error: error:140BA0C3:SSL routines:SSL_new:null ssl ctx

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[Sat Mar 31 23:35:07.774067 2018] [proxy:error] [pid 6276:tid 6] (130)Software caused connection abort: [client 127.0.0.1:45669] AH01084: pass request body failed to 127.0.0.1:9544 (localhost)


Without the SSL config in Location it looks like this:

[Sat Mar 31 23:34:47.244356 2018] [proxy:debug] [pid 6260:tid 11] mod_proxy.c(1239): [client 127.0.0.1:45665] AH01143: Running scheme https handler (attempt 0)
[Sat Mar 31 23:34:47.244400 2018] [proxy_http:trace1] [pid 6260:tid 11] mod_proxy_http.c(1904): [client 127.0.0.1:45665] HTTP: serving URL https://localhost:9544/
[Sat Mar 31 23:34:47.244491 2018] [proxy:debug] [pid 6260:tid 11] proxy_util.c(2162): AH00942: HTTPS: has acquired connection for (localhost)
[Sat Mar 31 23:34:47.244546 2018] [proxy:debug] [pid 6260:tid 11] proxy_util.c(2215): [client 127.0.0.1:45665] AH00944: connecting https://localhost:9544/ to localhost:9544
[Sat Mar 31 23:34:47.245610 2018] [proxy:debug] [pid 6260:tid 11] proxy_util.c(2424): [client 127.0.0.1:45665] AH00947: connected / to localhost:9544
[Sat Mar 31 23:34:47.245777 2018] [proxy:trace2] [pid 6260:tid 11] proxy_util.c(2859): HTTPS: fam 2 socket created to connect to localhost
[Sat Mar 31 23:34:47.246066 2018] [proxy:debug] [pid 6260:tid 11] proxy_util.c(2893): AH02824: HTTPS: connection established with 127.0.0.1:9544 (localhost)
[Sat Mar 31 23:34:47.246612 2018] [proxy:debug] [pid 6260:tid 11] proxy_util.c(3061): AH00962: HTTPS: connection complete to 127.0.0.1:9544 (localhost)
[Sat Mar 31 23:34:47.246698 2018] [ssl:info] [pid 6260:tid 11] [remote 127.0.0.1:9544] AH01964: Connection to child 0 established (server 195.227.30.235:9543)
[Sat Mar 31 23:34:47.246727 2018] [ssl:info] [pid 6261:tid 27] [client 127.0.0.1:45666] AH01964: Connection to child 152 established (server 195.227.30.235:9544)
[Sat Mar 31 23:34:47.246801 2018] [ssl:trace2] [pid 6260:tid 11] ssl_engine_rand.c(126): Proxy: Seeding PRNG with 136 bytes of entropy
[Sat Mar 31 23:34:47.247137 2018] [ssl:trace4] [pid 6260:tid 11] ssl_engine_io.c(1658): [remote 127.0.0.1:9544] coalesce: have 0 bytes, adding 200 more
[Sat Mar 31 23:34:47.247181 2018] [ssl:trace4] [pid 6260:tid 11] ssl_engine_io.c(1718): [remote 127.0.0.1:9544] coalesce: passing on 200 bytes
[Sat Mar 31 23:34:47.247216 2018] [ssl:trace3] [pid 6260:tid 11] ssl_engine_io.c(1230): [remote 127.0.0.1:9544] SNI extension for SSL Proxy request set to 'localhost'
[Sat Mar 31 23:34:47.247212 2018] [ssl:trace2] [pid 6261:tid 27] ssl_engine_rand.c(126): Server: Seeding PRNG with 136 bytes of entropy
[Sat Mar 31 23:34:47.247282 2018] [ssl:trace3] [pid 6260:tid 11] ssl_engine_kernel.c(2016): [remote 127.0.0.1:9544] OpenSSL: Handshake: start
...
Comment 15 Rainer Jung 2018-04-01 00:36:18 UTC
Partial problem analysis, all happening in the child:

First during startup:

- initialises proxy->ssl_ctx in ssl_init_proxy_ctx()
- ssl_init_ConfigureServer sets proxy_post_config=1


and then during request handling

- calling ssl_init_connection_ctx without perdir
- a new perdir ssl config is merged on top of the config set up during startup, the result now has ssl_ctx == NULL

I thought about adding ssl_ctx to the fields to merge in the perdir merging (using the one from add if set and otherwise the one from base). But that could be wrong, because the perdir merging also merges pkp settings which in the end result can be a mixture of base and add settings, so the ssl_ctx seems to need a fresh creation for the end result. On the other hand it seems that no SSLProxy settings are allowed in non-<Proxy> perdir.

So the following minimal patch works for my reproduction case, but I wonder whether that is really correct, ie. whether the ssl_ctx really has the right config:

--- modules/ssl/ssl_engine_config.c 2018-02-16 12:16:46.700863000 +0100
+++ modules/ssl/ssl_engine_config.c 2018-04-01 02:35:36.251855000 +0200
@@ -465,6 +465,7 @@
     cfgMergeString(pkp->cert_file);
     cfgMergeString(pkp->cert_path);
     cfgMergeString(pkp->ca_cert_file);
+    cfgMerge(ssl_ctx, NULL);
 }

 void *ssl_config_perdir_merge(apr_pool_t *p, void *basev, void *addv)
Comment 16 mark 2018-04-01 17:26:12 UTC
That proposed change also resolves this bug for me in the lab environment. We'll roll it out to the large scale enviroments and confirm it corrects this case at least. Thanks!
Comment 17 Yann Ylavic 2018-04-03 17:13:58 UTC
Thanks Mark for the traces/tests, and Rainer for the patch and analyses.

A NULL proxy->ssl_ctx may come from any dir context with no SSLProxy* directive (adding one like "SSLProxyEnable on" should possibly work around the issue). Since ssl_proxy_section_post_config() isn't called, the merge/init parts are missing for the SSL proxy configuration...

So indeed merging ssl_ctx is the right thing to do in this case, though I would do it in the mod_ssl only ssl_config_perdir_merge() function.
If it's done in modssl_ctx_cfg_merge_proxy(), which is also called indirectly from ssl_proxy_section_post_config(), merging ssl_ctx before ssl_init_proxy_ctx() may prevent it from being created according to the appropriate <Proxy > section.

How about the below patch instead?

Index: modules/ssl/ssl_engine_config.c
===================================================================
--- modules/ssl/ssl_engine_config.c	(revision 1828248)
+++ modules/ssl/ssl_engine_config.c	(working copy)
@@ -499,13 +499,21 @@ void *ssl_config_perdir_merge(apr_pool_t *p, void
     cfgMergeInt(nRenegBufferSize);
 
     mrg->proxy_post_config = add->proxy_post_config;
-    if (!add->proxy_post_config) {
+    if (!mrg->proxy_post_config) {
         cfgMergeBool(proxy_enabled);
         modssl_ctx_init_proxy(mrg, p);
         modssl_ctx_cfg_merge_proxy(p, base->proxy, add->proxy, mrg->proxy);
+
+        /* Since ssl_proxy_section_post_config() hook won't be called if there
+         * is no SSLProxy* in this dir config, the ssl_ctx may still be NULL
+         * here at runtime. Merging it is either a no-op (NULL => NULL) because
+         * we are still before post config, or we really want to reuse the one
+         * from the upper/server context (outside of <Proxy> sections).
+         */
+        cfgMerge(proxy->ssl_ctx, NULL);
     }
     else {
-        /* post_config hook has already merged and initialized the
+        /* The post_config hook has already merged and initialized the
          * proxy context, use it.
          */
         mrg->proxy_enabled = add->proxy_enabled;
--
Comment 18 mark 2018-04-04 12:00:25 UTC
I don't see the word SSLProxyEnable anywhere on this page:

https://httpd.apache.org/docs/2.4/mod/mod_ssl.html


should i see it here?

Maybe you're thinking of SSLProxyEngine?

https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslproxyengine

Is this a new requirement (SSLProxyEngine)?
Comment 19 mark 2018-04-04 12:03:41 UTC
I mean is it new to require it in the VirtualHost context? We do already include it in the server config context.
Comment 20 Yann Ylavic 2018-04-04 12:43:30 UTC
> I don't see the word SSLProxyEnable anywhere on this page:
Yes my bad, I meant SSLProxyEngine.

> Is this a new requirement (SSLProxyEngine)?
> I mean is it new to require it in the VirtualHost context? We do already
> include it in the server config context.
What I meant is that the bug would not trigger if some SSLProxy* directive (for instance SSLProxyEngine) is in each context (<FilesMatch>, <Location> in your case) where another SSL* directive (for instance SSLRequire) is used.
But this is obviously not a new requirement, clearly a bug in the new merge process which I tried (badly) to explain...
Comment 21 mark 2018-04-04 18:50:34 UTC
Thanks, I think understand. You believe this 2nd patch is more suitable than Rainer's because it's covers more cases correctly?

We have a limited time where we can run tests in the non-production large-scale environments before promotion to the large-scale production environments and I've already made one late change and I want Rainer's patch to get more of a shakedown before substituting this one in. 

While I can test this 2nd patch in my lab environment, I will have to wait to try this in the non-production large scale environments.
Comment 22 Yann Ylavic 2018-04-04 21:24:07 UTC
The issue with Rainer's patch (possibly) is that a <Proxy> section with its own SSLProxy* settings might finally reuse the SSL_CTX from the upper VirtualHost (which kind of defeats the changes from 2.4.30+).
That's because the place where is mergeg the ssl_ctx in his patch is also called before the <Proxy> merge itself (which roughly will do nothing if the ssl_ctx is already set).

But, in your case, you don't seem to use SSLProxy* directives in <Proxy> sections, so it shouldn't matter.
Moreover, I didn't tested my patch seriously enough (just a proposal) to confirm it effectively resolves your issue in the first place, nor that it works as expected with regard to Rainer's one.
Put another way, I wouldn't recommend using my patch in production without the same kind of testing you did for Rainer's...
Comment 23 Yann Ylavic 2018-04-04 22:38:08 UTC
I could verify my assertions with a configuration like this:

Listen 8443
<VirtualHost *:8443>
    ServerName localhost:8443

    SSLEngine on
    SSLProtocol -all +TLSv1.2
    ...
</VirtualHost>

Listen 8880
<VirtualHost *:8880>
    ServerName localhost:8880

    <Location "/">
        SSLOptions StdEnvVars
    </Location>

    SSLProxyEngine on
    SSLProxyVerify none
    SSLProxyCheckPeerName off
    SSLProxyProtocol TLSv1
    <Proxy "https://localhost:8443">
        SSLProxyProtocol TLSv1.2
    </Proxy>
    ProxyPass / https://localhost:8443/
    ...
</VirtualHost>

Now I test a request on http://localhost:8080/, which should be forwarded to https://localhost:8443/ using TLSv1.2.

With no patch (vanilla 2.4.33), I get the "SSL Library Error: error:140BA0C3:SSL routines:SSL_new:null ssl ctx" because of the <Location> section. This issue is resolved by both Rainer's and my patch.

With Rainer's patch, the forwarding happens using TLSv1.0 (which fails).
With my patch it works as expected (using TLSv1.2). 

So I don't think it makes a difference to use either patch for your current production case, but for next 2.4 we probably will go with my patch.
Comment 24 Yann Ylavic 2018-04-04 23:37:16 UTC
trunk commit r1828390.
Comment 25 Graham Leggett 2018-06-18 22:20:14 UTC
Backported to v2.4.34.

http://svn.apache.org/viewvc?view=revision&revision=1828735