Apache 2.4 als Reverseproxy - Weiterleitung auf Zielserver funktioniert nicht

Da es hier um Apache geht, und nur in diesem Bereich Apache aufgeführt ist, habe ich es hier gepostet und nicht unter Windows Server.

Auf Grund der Administration des Betriebssystems ist der Apache unter Windows installiert. Denn in der Umgebung wird hauptsächlich Windows eingesetzt, wofür KnowHow da ist. Daher das Betriebssystem nicht unter Linux.

Ja, der Client zum Test sitzt im Internet.

Und im DNS beim Provider ist owa.domäne.tld eingetragen und verweist somit auf die öffentliche IP.

Von wem die 404 zurück kommt ist derzeit noch nicht genau bekannt.

Hier die vhost:
<VirtualHost "öffentliche IP-Adresse":443>

ServerName owa.domäne.tld
ServerAlias autodiscover.domäne.tld
ServerAdmin admin@domäne.tld

LogLevel debug
ErrorLog logs/errorvhosts443.log
CustomLog logs/accessvhosts443.log combined

Header always set X-Frame-Options SAMEORIGIN
Header set Server Apache
Header unset X-AspNet-Version
Header unset X-OWA-Version
Header unset X-Powered-By
RequestHeader unset Expect early

SetEnvIf User-Agent ".*MSIE.*" value BrowserMSIE
Header unset WWW-Authenticate
Header add WWW-Authenticate "Basic realm=owa.domäne.tld"

ProxyRequests Off
ProxyPreserveHost On

SSLProxyEngine On

ProxyPass /owa https://owa.domäne.tld/owa
ProxyPassReverse /owa https://owa.domäne.tld/owa
ProxyPass /iisadmpwd https://owa.domäne.tld/iisadmpwd
ProxyPassReverse /iisadmpwd https://owa.domäne.tld/iisadmpwd
ProxyPass /ecp https://owa.domäne.tld/ecp
ProxyPassReverse /ecp https://owa.domäne.tld/ecp
ProxyPass /ECP https://owa.domäne.tld/ECP
ProxyPassReverse /ECP https://owa.domäne.tld/ECP
ProxyPass /Ecp https://owa.domäne.tld/Ecp
ProxyPassReverse /Ecp https://owa.domäne.tld/Ecp
ProxyPass /ews https://owa.domäne.tld/ews
ProxyPassReverse /ews https://owa.domäne.tld/ews
ProxyPass /EWS https://owa.domäne.tld/EWS
ProxyPassReverse /EWS https://owa.domäne.tld/EWS
ProxyPass /Ews https://owa.domäne.tld/Ews
ProxyPassReverse /Ews https://owa.domäne.tld/Ews
ProxyPass /exchange https://owa.domäne.tld/exchange
ProxyPassReverse /exchange https://owa.domäne.tld/exchange
ProxyPass /Exchange https://owa.domäne.tld/Exchange
ProxyPassReverse /Exchange https://owa.domäne.tld/Exchange
ProxyPass /exchweb https://owa.domäne.tld/exchweb
ProxyPassReverse /exchweb https://owa.domäne.tld/exchweb
ProxyPass /public https://owa.domäne.tld/public
ProxyPassReverse /public https://owa.domäne.tld/public
ProxyPass /oab https://owa.domäne.tld/oab
ProxyPassReverse /oab https://owa.domäne.tld/oab
ProxyPass /OAB https://owa.domäne.tld/OAB
ProxyPassReverse /OAB https://owa.domäne.tld/OAB
ProxyPass /Microsoft-Server-ActiveSync https://owa.domäne.tld/Microsoft-Server-ActiveSync connectiontimeout=600
ProxyPassReverse /Microsoft-Server-ActiveSync https://owa.domäne.tld/Microsoft-Server-ActiveSync
ProxyPass /autodiscover https://owa.domäne.tld/autodiscover
ProxyPassReverse /autodiscover https://owa.domäne.tld/autodiscover
ProxyPass /Autodiscover https://owa.domäne.tld/Autodiscover
ProxyPassReverse /Autodiscover https://owa.domäne.tld/Autodiscover
ProxyPass /AutoDiscover https://owa.domäne.tld/AutoDiscover
ProxyPassReverse /AutoDiscover https://owa.domäne.tld/AutoDiscover

AddDefaultCharset ISO-8859-1

<Directory />
Order deny,allow
Deny from all
</Directory>

<Proxy *>
SetEnv proxy-nokeepalive 1
SetEnv force-proxy-request-1.0 1
Order deny,allow
Allow from all
</Proxy>

SSLEngine on
SSLCertificateFile "D:/Apache24/conf/ssl/server.crt"
SSLCertificateKeyFile "D:/Apache24/conf/ssl/server.key"

</VirtualHost>


Bisher ist noch das Apache selbst signierte Zertifikat eingebunden (für Tests), bis das SAN-Zertifikat gekauft und eingebunden wird.
Die Firewall lässt lediglich 443 in die DMZ zum Proxy.
Der IIS lässt auch 443 zu. Mit der internen URL funktioniert der owa Aufruf.

Nein, das ist nicht der intern verwendete FQDN, sondern separat für extern der FQDN. Die URLs sind so im Exchange eingetragen.

Nein, der Client nutzt nicht die selbe Firewall, sondern kommt frei über einen anderen Router / Anschluss ins Internet.

Auch wenn ich den FQDN des Exchanges eingebe, wird im Webbrowser die selbe 404 Meldung angezeigt.
Das gleiche mit der IP des Exchanges.

Ping (ICMP) vom Exchange zum Apache und umgekehrt sind möglich.

Auch wenn ich die IP des Exchanges eingebe (im Proxypass und ProxypassReverse des Apache) anstatt den FQDN, funktioniert die Weiterleitung nicht.
Das Windowssystem kann die den FQDN zur IP auflösen und umgekehrt.
Muss ich die Namensauflösung ggf. auch noch separat in einer Apache Konfig.-Datei einstellen?

Ja, es ist ein NAT mit Portmapping eingerichtet.

Wenn ich im Webbrowser auf dem Reverseproxy den FQDN/owa eingebe oder die IP/owa vom Exchange, dann wird die OWA-Site per https problemlos angezeigt.

Muss auch zum Test zwingend das selbstsignierte Exchangezertifikat exportiert und in den Apache ReverseProxy eingebunden werden, damit die Weiterleitung (ReverseProxy -> Exchange und zurück) funktioniert?

Ja, es sind folgende Module aktiviert:
LoadModule access_compat_module modules/mod_access_compat.so
LoadModule actions_module modules/mod_actions.so
LoadModule alias_module modules/mod_alias.so
LoadModule allowmethods_module modules/mod_allowmethods.so
LoadModule asis_module modules/mod_asis.so
LoadModule auth_basic_module modules/mod_auth_basic.so
LoadModule auth_digest_module modules/mod_auth_digest.so
LoadModule authn_core_module modules/mod_authn_core.so
LoadModule authn_file_module modules/mod_authn_file.so
LoadModule authnz_ldap_module modules/mod_authnz_ldap.so
LoadModule authz_core_module modules/mod_authz_core.so
LoadModule authz_groupfile_module modules/mod_authz_groupfile.so
LoadModule authz_host_module modules/mod_authz_host.so
LoadModule authz_user_module modules/mod_authz_user.so
LoadModule autoindex_module modules/mod_autoindex.so
LoadModule cgi_module modules/mod_cgi.so
LoadModule dir_module modules/mod_dir.so
LoadModule env_module modules/mod_env.so
LoadModule headers_module modules/mod_headers.so
LoadModule include_module modules/mod_include.so
LoadModule info_module modules/mod_info.so
LoadModule isapi_module modules/mod_isapi.so
LoadModule ldap_module modules/mod_ldap.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule mime_module modules/mod_mime.so
LoadModule negotiation_module modules/mod_negotiation.so
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule socache_shmcb_module modules/mod_socache_shmcb.so
LoadModule ssl_module modules/mod_ssl.so
LoadModule status_module modules/mod_status.so
LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
LoadModule deflate_module modules/mod_deflate.so
LoadFile bin/libxml2.dll
LoadModule xml2enc_module modules/mod_xml2enc.so
LoadModule proxy_html_module modules/mod_proxy_html.so

Im error-logfile steht folgendes:
AH00558: httpd.exe: Could not reliably determine the server's fully qualified domain name, using "fe80::....". Set the 'ServerName' directive globally to suppress this message
[Wed Feb 17 00:06:13.844991 2016] [auth_digest:notice] [pid 2844:tid 464] AH01757: generating secret for digest authentication ...
[Wed Feb 17 00:06:13.954361 2016] [ssl:warn] [pid 2844:tid 464] AH01909: localhost:443:0 server certificate does NOT include an ID which matches the server name
[Wed Feb 17 00:06:14.391867 2016] [mpm_winnt:notice] [pid 2844:tid 464] AH00354: Child: Starting 64 worker threads.
[Wed Feb 17 00:06:15.407493 2016] [mpm_winnt:notice] [pid 2500:tid 464] AH00364: Child: All worker threads have exited.


Im logfile des vhosts sind keine weiteren Fehler ersichtlich, sondern lediglich Infomeldungen.

Wie ist für die Zertifikatsübernahme genau vorzugehen?
Denn der Reverseproxy soll normalerweise ein öffentliche SAN-Zertifikat bekommen.
Wie kann parallel das Exchangezertifikat eingebunden werden?

Die Meldung erscheint, da der Apache derzeit noch die standardmäßigen selbstsignierten Zertifikate verwendet. Und in diesen ist nicht der server name genannt.

Nein, in den logfiles sind keine weiteren Hinweise zu sehen, welche Websites versucht werden aufzurufen.

Das Netzwerkdesign sieht wie folgt aus:
WWW <-> DMZ (Firewall) <-> Reverseproxy <-> LAN (Firewall) <-> LAN: Exchange.


Auch wenn in der Konfig. der FQDN des Exchange drin steht, funktioniert es nicht. Error 404 erscheint.
Den Apache habe ich nach jeder Konfig. Änderung neugestartet.

Leider zeigen die Access-Logs keine weiteren Hinweise an.

Es gibt nur einen vHost - den für Port 443.
Und diesem würde an das SAN-Zertifikat, welches ich kaufen werde, zuweisen.
Ich gehe davon aus, dass wenn dann der vHost das öffentliche SAN-Zertifikat verwendet, auch der Exchange die Zertifikatskette bis zur öffentlichen CA auslösen kann und er somit dem Apache vHost vertraut.

Da öffentliche CAs zunehmen wohl keine Zertifikate mehr für interne Servernamen ausstellen, hatte ich ursprünglich die externe URL owa.domäne.tld/owa in ProxyPass und ProxyReverse eingetragen, denn nur dieser Namen wird später auch im SAN-Zertifikat enthalten sein.

Der Apache soll den Weg zum Exchange entweder per DNS-Auflösung aus der Hosts-Datei oder der internen DNS-Server finden.
Die Weiterleitung des Reverseproxy funktioniert jedoch auch mit IP oder internem FQDN des Exchange nicht.
Greift der Apache auf die DNS.Namensauflösung des Windows Servers zu oder verwendet dieser eine eigene?

Muss die externe URL im Exchange auch zwingend die IP des Exchange beinhalten, so den selben Wert wie im Reverseproxy bei ProxyPass und ProxyPass Reverse eintragen ist?

Nien, der vHost ist nicht aktiviert, da ich diese Einträge/Dateien bisher auf Apache für Windows im Gegensatz Apache zu Linux nicht gefunden habe. Wo ist dies bei Apache für Windows zu tun?

Ja, SSL-Offloading wäre sinnvoll.

Nein, dies werde ich nun testen, wie es sich mit einer Weiterleitung auf einen anderen Host verhalt.