Potrzebujesz pomocy w rozwiązywaniu problemów Błąd serwera HTTP - Uścisk SSL nie powiódł się

9

Postępowałem zgodnie z tym przewodnikiem: http://hints.macworld.com/article.php?story=20041129143420344

Oto moja definicja wirtualnego hosta

<VirtualHost *:443>
    SSLEngine on
    SSLProxyEngine On
    RequestHeader set Front-End-Https "On"
    CacheDisable *
    SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
    DocumentRoot "/Users/me/projects/myproject/public"
    ServerName ssl.mydomain.com
    ServerAlias *.ssl.mydomain.com
    SSLCertificateKeyFile "/private/etc/apache2/certs/webserver.nopass.key"
    SSLCertificateFile "/private/etc/apache2/certs/newcert.pem"
    SSLCACertificateFile "/private/etc/apache2/certs/demoCA/cacert.pem"
    SSLCARevocationPath "/private/etc/apache2/certs/demoCA/crl"
    ErrorLog "/Users/me/Desktop/ssl.log"

    ProxyPass / https://localhost:3002/
    ProxyPassReverse / https://localhost:3002
    ProxyPreserveHost on    
</VirtualHost>

Kiedy próbuję połączyć się z przeglądarką sevre viov, pojawia się błąd:

[Thu Feb 02 16:50:40 2012] [error] (502)Unknown error: 502: proxy: pass request body failed to 127.0.0.1:3002 (localhost)
[Thu Feb 02 16:50:40 2012] [error] [client 96.11.81.39] proxy: Error during SSL Handshake with remote server returned by /session/new
[Thu Feb 02 16:50:40 2012] [error] proxy: pass request body failed to 127.0.0.1:3002 (localhost) from 96.11.81.39 ()

jak to debugować / naprawić?

apache-2.2 ssl https virtualhost NullVoxPopuli
źródło

Odpowiedzi:

12

Aby dodać do odpowiedzi vbartoni, wydaje się, że od Apache 2.4 i nowszych istnieją różne ustawienia domyślne i nowa dyrektywa.

Korzystam z Apache 2.4.6 i musiałem dodać następujące dyrektywy, aby działało:

SSLProxyEngine on
SSLProxyVerify none 
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
mydoghasworms
źródło
1
To działa - tylko przy tych wszystkich dyrektywach nie będzie narzekać.
Michael Böckling,
@ MichaelBöckling Dziękuję, że mnie podtrzymałeś. Chcę szczególnie podkreślić, że dokumentacja stwierdza, że SSLProxyCheckPeerNamezastępuje, SSLProxyCheckPeerCNale nie będzie działać, chyba że podasz wszystkie dyrektywy.
podwójny
3

Nie przejmuj się HTTPS między front-endem a serwerem back-end, włączenie protokołu SSL dla localhostpołączenia nie ma sensu .

Aby to wyjaśnić, użyj ProxyPass / http://localhost:3002/zamiastProxyPass / https://localhost:3002/

Ewentualnie, jeśli naprawdę chcesz połączyć swój zwrotny serwer proxy z serwerem zaplecza również za pomocą protokołu SSL (co jest szczególnie przydatne, gdy na tym serwerze nie ma odwrotnego serwera proxy Apache Httpd) https://backend-server-address, skorzystaj z SSLProxy*dyrektyw, aby skonfigurować Certyfikaty CA, jak udokumentowano we wstępie do mod_proxydokumentacji . W szczególności należy skonfigurować SSLProxyCACertificateFilei upewnić się, że certyfikat serwera zaplecza jest wydawany na poprawną nazwę hosta widoczną w Apache Httpd (tj. localhostW twoim przypadku).

Jeśli nie łączysz się z serwerem zaplecza za pomocą protokołu SSL, może nie wykryć, że faktycznie używasz protokołu SSL, i zostać skonfigurowanym tak, aby zmusić cię do przejścia na protokół SSL (stąd nieskończone przekierowania). Możesz przyjrzeć się mechanizmom podobnym do tego, co robi Jetty z tą forwardedopcją (aby móc powiedzieć back-endowi, że stoi za serwerem proxy). Szyny mogą X-Forwarded-Protodomyślnie być w stanie interpretować . W takim przypadku dodaj to do konfiguracji Apache (na wirtualnym hoście SSL):

RequestHeader set X-Forwarded-Proto 'https'

Wydaje się, że poruszono tutaj podobną kwestię .

Bruno
źródło
SSLProxy jest wspomniany tylko raz na tym łączu. Brak przykładów, jak go używać. Zmieniłem nagłówek żądania, aby ustawić X-Forwarded-Proto „https” ... ale wciąż nie działa / Otrzymuję ten sam błąd. Przejście do localhost: 3002 również daje ten sam błąd
NullVoxPopuli
Istnieją ważne powody, aby połączyć się z https za pomocą localhost: przykładowy socket.io w back-endie HTTPS. Przejdzie przez błędy z mieszaną zawartością.
Florestan06,
3

Miałem podobny problem (te same dzienniki błędów), z tym wyjątkiem, że serwer proxy przekierowywał ruch https na inny host.
Ponieważ byłem leniwy, a hosty znajdują się w mojej izolowanej sieci, te dyrektywy rozwiązały problem:

SSLProxyVerify none
SSLProxyCheckPeerCN wyłączony

Vbartoni
źródło
1

Jeśli serwer zaplecza korzysta z nieaktualnego samopodpisanego certyfikatu, potrzebna jest jeszcze jedna opcja (jeśli nie ma dostępu do serwera zaplecza):

SSLProxyCheckPeerExpire off

Milan Kerslager
źródło