Error during ssl handshake with remote server returned by - Исправление ошибок и поиск оптимальных решений проблем

Problem

Apache is configured as a reverse proxy. The proxied backend is accessed via HTTPS. Accessing the proxied URL is resulting in an error message: proxy error.

Apache log:

AH00898: Error during SSL Handshake with remote server returned by /url

Browser:

Root cause

The apache configuration is erroneous. Apache cannot establish a connection to the HTTPS backend.

<VirtualHost *:80>
  SSLProxyEngine On
  ProxyPreserveHost On
  ProxyRequests Off
  ProxyPass /url https://server
  ProxyPassReverse /url https://server
</VirtualHost>

Solution

Several Apache configuration parameters define how to connect to a HTTPS backend. Normally the misconfiguration is solved by adjusting three parameters:

ProxyPreserveHost
SSLProxyVerify
SSLProxyCheckPeerName

ProxyPreserveHost

In the above example, the parameter ProxyPreserveHost is set to on, meaning that the host name of the client is send to the backend. As the proxy is accessed by localhost, this name is forwarded to the backend. Setting this value to Off ensures Apache is sending the server name of the target server in the HTTP header. This is important as more and more servers are running in a virtualized environment that needs the host name for selecting the correct server.

SSLProxyVerify

This parameter checks to TLS certificate send by the backend. In case the certificate is invalid, expired, self-signed, etc, Apache is refusing to connect. If you know that the certificate is valid (e.g. internal one) and you cannot make it valid for Apache (import CA), this parameter instructs Apache to accept the certificate.

SSLProxyCheckPeerName

This parameter checks if the CN name matches the FQDN of the server. Be aware of wildcard certificate handling as described in the documentation. “*.example.org will match foo.example.org, but will not match foo.bar.example.org”.

Working proxy configuration

Below example is a configuration that will allow Apache to connect to the backend. Most security checks are disabled, so this should only be used in a short living demo environment.

<VirtualHost *:80>
  SSLProxyEngine On
  ProxyPreserveHost Off
  SSLProxyVerify none
  SSLProxyCheckPeerName off
  ProxyRequests Off
  ProxyPass /url https://server
  ProxyPassReverse /url https://server
</VirtualHost>

Источник

Ошибка во время установления связи SSL с удаленным сервером

Протокол установления связи SSL / TLS

у меня есть Apache2 (прослушивание 443) и веб-приложение, работающее на Tomcat7 (слушаю 8443) на Ubuntu .

Я установил apache2 в качестве обратного прокси-сервера, чтобы получить доступ к веб-приложению через порт 443 вместо 8443. Кроме того, мне нужно иметь SSL-соединение не только между браузером и apache2, но и между apache2 и tomcat7, поэтому я установил SSL как для apache2, так и для tomcat7. . Если я попытаюсь получить доступ к веб-приложению, напрямую связавшись с tomcat7, все будет в порядке. Проблема в том, что когда я пытаюсь получить доступ к веб-приложению Tomcat через apache2 (обратный прокси), в браузере появляется ошибка:

Apache не проверяет подлинность сертификата, который вы установили на tomcat. Это самоподписанный сертификат? Или это делает внутренний центр сертификации?
2 Он самоподписан с помощью этой команды: openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
3 serverfault.com/questions/356678/… Я думаю, это то, что вам нужно: SSLProxyVerify none SSLProxyCheckPeerCN off
9 Лучше установить SSLProxyCACertificateFile на ваш частный сертификат CA, а не просто отключать проверку.
как объясняется в этом блоге, вы можете отключить проверку SSL.

Комментарий МК указал мне правильное направление.

В случае Apache 2.4 и выше существуют другие значения по умолчанию и новая директива.

Я использую Apache 2.4.6, и мне пришлось добавить следующие директивы, чтобы он заработал:

Таким образом, это отключает защиту, но пока трафик является локальным (например, 127.0.0.1:8443), это не должно быть проблемой, верно?
5 Ну, в части шифрование защиты не выключает. Трафик по-прежнему зашифрован. Это просто отключает проверку сертификата, чтобы убедиться, что это доверенный орган. Так что, если вы доверяете серверу, у вас не должно возникнуть проблем. Но да, для местного трафика я думаю, у вас тоже все в порядке.
1 Спасибо, mydoghasworms. Ваши директивы работают в версии сервера: Apache / 2.4.6. Если кому-то нужно знать версию httpd, используйте это: httpd -V

У меня есть 2 сервера на докере, обратный прокси и веб-сервер. Эта ошибка начала появляться на всех моих веб-сайтах внезапно через 1 год. При настройке ранее я создал самоподписанный сертификат на веб-сервере.

Итак, мне пришлось снова сгенерировать сертификат SSL, и он начал работать .

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ssl.key -out ssl.crt

Столкнулся с той же проблемой, что и OP:

Tomcat вернул ответ при доступе напрямую через интерфейс SOAP
Не загружал html файлы
При использовании свойств Apache, упомянутых в предыдущем ответе, веб-страница появлялась, но AngularJS не мог получить HTTP-ответ.

Срок действия сертификата Tomcat SSL истек, в то время как браузер показал его как безопасный — срок действия сертификата Apache еще далек от истечения. Обновление файла Tomcat KeyStore решило проблему.

Источник

How to Resolve error during SSL Handshake with Remote Server?

With advanced technology, a lot of things have developed when it comes to networks as well as coding, In this article, we will be discussing issues faced when you try to perform an SSL handshake with remote or local server. But before we proceed to know the reasons, the solutions or how these issues can be handled in real life scenarios, Let us now understand the basics included in the process.

Apache Server

Apache is a free and open source server software that runs with Apache License 2.0, It is developed and maintained under Apache Software Foundation, Most of the Apache services runs on Linux, However, they have developed so that it can be used on Windows and OS2 and on Unix as well.

How an SSL handshake is carried out? Types?

SSL handshake is initiated when the browser on your device forwards a secure connection request to a Web server. The server sends a public key to your computer, and the remote computer checks the certificate with a known list of certificates. Once the certificate is accepted, the computer generates a key and then encrypts it using the server’s public key.

SSL handshakes are basically two types:

Basic SSL handshake
Client Authenticated SSL handshake

The basic model here lets the client verify the server, and a number of sessions secured by TLS only require this. However, some cipher suites will require the client to also send a certificate and public key for mutual authentication of both parties which as above is the client authenticated SSL handshake. This two-way authentication will, of course, add to the handshake effectively as the security increases when both the parties provide valid authentication steps to confirm the handshake, However, in some cases, the cipher suite will be needed to recommended to complete the process which in turn adds extra security to the session.

A SSL handshake includes multiple stages, each managed according to different set of rules. but the issue here is that rather than a series of separate back and forth connections as to what keys to use, how to encrypt the handshake, how to authenticate the handshake and vice versa, the origin and target parties can agree on a “cipher suite which is an existing kit of agreed-upon components. TLS specifications, however, allows quite a number of cipher suites, and the client and server will almost always have access to one set of agreed upon components.

Let us check some scenarios where the error occur and how it was resolved.

Upgrading servers without understanding the pros and cons are dangerous and can lead to huge confusions, A lot of Linux admins working on Apache version 2.2 encountered the same “ Error SSL handshake failed with server “ due to an upgrade in the server versions. Now it might be meaningless for you to hear that a simple server upgrade is causing this issue.

Replicating the error :

Consider an Apache running on port 443 and a web app working on Tomcat running on port 8443 on Ubuntu.

You can set up Apache as reverse proxy so that you can access the web app running on Tomcat using port 443 instead of 8443. With having SSL connection between both the Browser and Apache and also Apache and Tomcat, SSL is set up on both Apache and Tomcat. The web app works fine while accessed through Tomcat, But if you try accessing the web app running on Tomcat through Apache which is set up as Reverse proxy you will be getting an error as below:

Proxy Error The proxy server could not handle the request GET /web_app.

Reason: Error during SSL Handshake with remote server

This usually happens when either mod_ssl module or the directives are not specified correctly.

Based on the set up, there are 2 suggestions to fix the issue to have the server running fine without errors depending on the nature of the error:

Modifying/Adding directives under the mod_ssl module as below:

Checking if there is an additional ssl.conf file which has replaced or added while copying the *.conf file during the transition of 2.2 to 2.4, This can cause conflicts as both the files will have the same directives and none of them will respond, Removing one of them and restarting httpd will fix the issue.

When the NAM is upgraded to version 4.3 without changing any other features, there will be a compatibility issue with the additional files supporting the server set up, The below mentioned error appears when NAM is upgraded without testing the additional files.

The server encountered an internal error.

The proxy server could not handle the request

Reason: Error during SSL Handshake with remote server.

While checking the device manager error log files under — /opt/novell/devman/jcc/logs/ the following set of error is replicated.

/opt/novell/devman/jcc/logs/jcc-0.log.0:INFO: Executing /opt/novell/ssllib/bin/c_rehash /opt/novell/apache2/cacerts

/opt/novell/devman/jcc/logs/jcc-0.log.0:Cannot run program “/opt/novell/ssllib/bin/c_rehash” (in directory “/”): error=2, No such file or directory

/opt/novell/devman/jcc/logs/jcc-0.log.0:java.io.IOException: Cannot run program “/opt/novell/ssllib/bin/c_rehash” (in directory “/”): error=2, No such file or directory

However, this issue can be resolved by making the changes as below:

create the “/opt/novell/ssllib/bin/” directory
create the following module “c_rehash” and copy it into the “/opt/novell/ssllib/bin/” directory

# print out the hash values

# based on /etc/pki/tls/misc/c_hash part of the openssl-1.0.0

#[ “$#” -eq 1 ] || die “One directory argument required, $# provided”

#[ -d “$1” ] || die “Directory $1 does not exist”

printf “removing all old hash files n”

printf “creating new hash files n”

h=`/opt/novell/openssl/bin/openssl x509 -hash -noout -in $i`

flag the script executable: chmod 755 c_reshash
execute the script
restart the Access Gateway

The above changes in commands will help you fix the issue, However, you should be sure that any aspect is not given a wrong value which will, in turn, throw the same error.

In the previous article, we have seen how small changes in the commands have fixed the issues with SSL handshake to a remote or a local server, But it is quite surprising that a change in date or time will also affect the functionality or the connections causing SSL errors. The best way to check it is by following the below steps.

Go your Windows Start screen, and then choose the current date and time.
Choose “Settings > Change the time and date > Change the Internet Time > Save Settings.
Move the date 2–3 years ahead of the present time by clicking on the right arrow under the “Date” heading. Click “OK” to save the changes. You must select a date much ahead of the actual time to cause a date discrepancy between the computer and the SSL certificate used on the Web server. The large difference in date and time will cause the SSL handshake to fail.
Restart your computer.

Once you have made the changes as suggested above, Follow the steps:

Open a Web browser and visit a website that you know is secure or has https on all its internal links as well, for example, your bank or an online store.
Try to log in to your bank account or add items to your shopping cart in order to initiate an SSL session which can be done as payment gateways on every bank or online stores are secured with https.
Within few seconds an error message will appear on your browser, warning you that the server’s SSL certificate is not yet valid or expired, and due to which the SSL handshake has failed.

This is a rare issue but very important while your target is an SSL handshake with web server be it remote or local server. Normally when the error is triggered you get an Error 525: SSL handshake failed, Error 525 indicates that the SSL handshake between Cloudflare and the origin server failed. This normally occurs when the domain is using a Cloudflare Full SSL mode.

The most common issues that cause Error 525 are:

The origin server does not have a valid SSL certificate.
The server is not working on port 443 or possibly configured on custom ports.
The web server does not support SNI or Server name indication.
The cipher that Cloudflare uses and the cipher suites that the origin server uses are different.

Although there are no definite steps to resolve the issue, Here we have few steps that can be used to troubleshoot the cause:

Apache must be configured to work as per log mod_ssl errors.
Increasing the log level and adding these error logs in Nginx.

Conclusion

Discussed above are some cases where small changes have led to failed handshake attempts, It is always recommended to contact or take advice from a server administrator while you imply any changes on the server, With Date and time causing an error to an invalid SSL certificates, the possibilities are numerous, It is how you go about it or take measures to avoid these issue which matters. Ever faced any issue with SSL handshakes other than the ones listed above, Let us know in comments below.

Источник

Apache reverse proxy AH00898 – Error during SSL Handshake with remote server

Published by Tobias Hofmann on June 24, 2021 June 24, 2021

Problem

Apache is configured as a reverse proxy. The proxied backend is accessed via HTTPS. Accessing the proxied URL is resulting in an error message: proxy error.

Apache log:

Browser:

Root cause

The apache configuration is erroneous. Apache cannot establish a connection to the HTTPS backend.

Solution

Several Apache configuration parameters define how to connect to a HTTPS backend. Normally the misconfiguration is solved by adjusting three parameters:

ProxyPreserveHost
SSLProxyVerify
SSLProxyCheckPeerName

ProxyPreserveHost

SSLProxyVerify

SSLProxyCheckPeerName

Working proxy configuration

Below example is a configuration that will allow Apache to connect to the backend. Most security checks are disabled, so this should only be used in a short living demo environment.

Источник

Description

Allen Zhao

2013-06-26 20:20:10 UTC

We upgrade our apache from 2.2.17 to 2.2.24. We use the same setting. However, we keep getting 502 bad gateway issue.

I tried following settings as well, but no luck.
    SSLProxyCACertificateFile /work/users/infra/proxy/proxyCA.crt
    SSLProxyMachineCertificateFile /work/users/infra/proxy/lp97643.pem
    SSLProxyVerify none
    SSLProxyCheckPeerCN off
    SSLProxyCheckPeerExpire off

I have verified by proxyCA with curl, it works fine.

I struggled with this issue for couple of weeks. I doubt this might be new bug.

Thanks a lot,

The error log:
[Wed Jun 26 19:08:35 2013] [error] (502)Unknown error 502: proxy: pass request body failed to 142.63.42.254:443 
[Wed Jun 26 19:08:35 2013] [error] [client 192.168.156.135] proxy: Error during SSL Handshake with remote server returned by /Offline/, referer: https://abc.xyz.com/Offline/
[Wed Jun 26 19:08:35 2013] [error] proxy: pass request body failed to 142.63.42.254:443 from 192.168.156.135 ()


The config:
NameVirtualHost *:50211
<VirtualHost *:50211>
    ServerAdmin admin@example.com
    DocumentRoot "/work/users/infra/proxy/PR_Offline_https/htdocs"
    <Directory "/work/users/infra/proxy/PR_Offline_https/htdocs">
        Allow from all
    </Directory>
    SSLEngine on
    SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
    SSLProxyEngine on
    SSLCertificateFile      /work/users/infra/proxy/lp97643.crt
    SSLCertificateKeyFile   /work/users/infra/proxy/lp97643.key
    RequestHeader set X-Authenticated-User %{REMOTE_USER}e
    ProxyRequests On
    ProxyVia On
    ProxyPreserveHost On
    ProxyPass /Offline http://142.63.42.254/Offline/
    ProxyPassReverse /Offline http://142.63.42.254/OfflineS/
    BrowserMatch ".*MSIE.*" 
         nokeepalive ssl-unclean-shutdown 
         downgrade-1.0 force-response-1.0
    SetEnv force-proxy-request-1.0 1
    SetEnv proxy-nokeepalive 1
</VirtualHost>

The compile settings:

bin/httpd -V
Server version: Apache/2.2.24 (Unix)
Server built:   May 21 2013 14:49:46
Server's Module Magic Number: 20051115:31
Server loaded:  APR 1.4.6, APR-Util 1.4.1
Compiled using: APR 1.4.6, APR-Util 1.4.1
Architecture:   64-bit
Server MPM:     Prefork
  threaded:     no
    forked:     yes (variable process count)
Server compiled with....
 -D APACHE_MPM_DIR="server/mpm/prefork"
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_SYSVSEM_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D DYNAMIC_MODULE_LIMIT=128
 -D HTTPD_ROOT="/apps/infra/apache/2.2.24"
 -D SUEXEC_BIN="/apps/infra/apache/2.2.24/bin/suexec"
 -D DEFAULT_PIDLOG="logs/httpd.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_LOCKFILE="logs/accept.lock"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="conf/mime.types"
 -D SERVER_CONFIG_FILE="conf/httpd.conf"

Comment 1

Allen Zhao

2013-06-26 20:27:37 UTC

I also built openssl from source version: 1.0.1e

Comment 2

Allen Zhao

2013-06-27 14:13:44 UTC

I rebuilt apache with openssl 1.0.0d. it works.

Any idear?

Thx a lot,

Comment 3

Eric Covener

2013-06-27 14:36:54 UTC

Can you validate a connection to the backend server with openssl s_client between the two builds?

Comment 4

Allen Zhao

2013-09-03 20:07:04 UTC

1.0.0d works fine.

1.0.1e: it doesn't read anything from stdin (e.g. enter a http request)

I got same issue with 2.2.25/1.0.1e.

2.2.25/1.0.0d works fine. This looks OpenSSL related.

bin/openssl s_client -host 172.23.199.200 -port 443
CONNECTED(00000003)

write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 321 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

Comment 5

Allen Zhao

2013-09-03 20:17:15 UTC

Here is part of the output from 1.0.0d:

bin/openssl s_client -host 172.23.199.200 -port 443
CONNECTED(00000003)
depth=1 C = CA, ST = Ontario, L = Toronto, O = TELUS, OU = Application Infrastructure, CN = www.telus.com
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
 0 s:/C=CA/ST=Ontario/L=Toronto/O=TELUS/OU=Application Infrastructure/CN=telusmobility.tmi.telus.com
   i:/C=CA/ST=Ontario/L=Toronto/O=TELUS/OU=Application Infrastructure/CN=www.telus.com
 1 s:/C=CA/ST=Ontario/L=Toronto/O=TELUS/OU=Application Infrastructure/CN=www.telus.com
   i:/C=CA/ST=Ontario/L=Toronto/O=TELUS/OU=Application Infrastructure/CN=www.telus.com
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDIDCCAomgAwIBAgIDEADpMA0GCSqGSIb3DQEBBQUAMH4xCzAJBgNVBAYTAkNB
MRAwDgYDVQQIEwdPbnRhcmlvMRAwDgYDVQQHEwdUb3JvbnRvMQ4wDAYDVQQKEwVU
RUxVUzEjMCEGA1UECxMaQXBwbGljYXRpb24gSW5mcmFzdHJ1Y3R1cmUxFjAUBgNV
BAMTDXd3dy50ZWx1cy5jb20wHhcNMDkwMzAyMTYxNTA4WhcNMTQwMzAxMTYxNTA4
WjCBjDELMAkGA1UEBhMCQ0ExEDAOBgNVBAgTB09udGFyaW8xEDAOBgNVBAcTB1Rv
cm9udG8xDjAMBgNVBAoTBVRFTFVTMSMwIQYDVQQLExpBcHBsaWNhdGlvbiBJbmZy
YXN0cnVjdHVyZTEkMCIGA1UEAxMbdGVsdXNtb2JpbGl0eS50bWkudGVsdXMuY29t
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCUi+ni+nyqZUugOOmkFovxmYi8
N/bARsvInCK6bXzYDhQQJr6+NtX5LytUDhDYHQXQVAL9Lm0wtOcNsrFLjEukvPuc
SI2Fr/4HWajIIA6uebFPIz5AvJh7jVYsDvv8/XcC+VgBh2TeJtSEZ5sDLj6mEF2y
ThAhffEHS3Ye5Ij+5wIDAQABo4GcMIGZMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEB
BAQDAgXgMAsGA1UdDwQEAwIF4DAsBglghkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5l
cmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFI3c2E1SsZBpaTYZOd3y1yUdWZTH
MB8GA1UdIwQYMBaAFFmwVgMX8YForRj3nr1434gfsUwaMA0GCSqGSIb3DQEBBQUA
A4GBABb/lsKiK42488U0w3oJuRJdIl6IRdmZTCp223tFpFihc0Se7jeiJeHKPniq
eNFnuKWbc52wiyLk98q313vp3DV3wfAafcYo77KwiXVPx9PUFcsJvZb9kJ8M6CxG
vLwicZg0gZFHegQRUkyKeYJHTcLbRZOyR5huX3gqklPJYlhm
-----END CERTIFICATE-----
subject=/C=CA/ST=Ontario/L=Toronto/O=TELUS/OU=Application Infrastructure/CN=telusmobility.tmi.telus.com
issuer=/C=CA/ST=Ontario/L=Toronto/O=TELUS/OU=Application Infrastructure/CN=www.telus.com
---
No client certificate CA names sent
---
SSL handshake has read 1824 bytes and written 392 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 1024 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : RC4-MD5
    Session-ID: 7549FF55BA4A41504A7E0C5AC261BC44BEFAA5E9CBEF366D7213C9A0DF2147BD
    Session-ID-ctx:
    Master-Key: 2D0F124D2315E89C48F4DD3573B1985716C56C90C4D6D723CB35701C0F0EA31AF47C84D3B772EC6DCD669A3D008C0771
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1378238532
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
---
GET /

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

Comment 6

Allen Zhao

2013-09-03 20:23:56 UTC

For 1.0.1e, if I add -ssl3, it works:

bin/openssl s_client -host 172.23.199.200 -port 443 -ssl3
CONNECTED(00000003)
depth=1 C = CA, ST = Ontario, L = Toronto, O = TELUS, OU = Application Infrastructure, CN = www.telus.com
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
 0 s:/C=CA/ST=Ontario/L=Toronto/O=TELUS/OU=Application Infrastructure/CN=telusmobility.tmi.telus.com
   i:/C=CA/ST=Ontario/L=Toronto/O=TELUS/OU=Application Infrastructure/CN=www.telus.com
 1 s:/C=CA/ST=Ontario/L=Toronto/O=TELUS/OU=Application Infrastructure/CN=www.telus.com
   i:/C=CA/ST=Ontario/L=Toronto/O=TELUS/OU=Application Infrastructure/CN=www.telus.com
---
Server certificate
-----BEGIN CERTIFICATE-----
...

Comment 7

Allen Zhao

2013-09-05 05:37:55 UTC

This seems caused by TLSV1.2.

I solve the problem by adding following line to httpd.conf.

SSLProxyProtocol +SSLv2 +SSLv3 +TLSv1 +TLSv1.1

Thanks a lot,

Allen

Comment 8

William A. Rowe Jr.

2018-11-07 21:08:22 UTC

Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd.

If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with.

Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.

Источник