Precisa de ajuda para solucionar o erro do servidor da web Https - Falha no handshake SSL


9

Segui este guia: http://hints.macworld.com/article.php?story=20041129143420344

Aqui está a minha definição de host virtual

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

E quando tento conectar-me ao navegador sevre viov, recebo este erro:

[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 ()

como faço para depurar / corrigir isso?

Respostas:


12

Para adicionar à resposta do vbartoni, parece que a partir do Apache 2.4 e posterior, existem diferentes padrões e uma nova diretiva.

Estou executando o Apache 2.4.6 e tive que adicionar as seguintes diretrizes para fazê-lo funcionar:

SSLProxyEngine on
SSLProxyVerify none 
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off

1
Isso faz o trabalho - somente com todas essas diretivas não vai reclamar.
Michael Böckling 25/08/14

@ MichaelBöckling Obrigado por me sustentar. Quero ressaltar especificamente que a documentação afirma que SSLProxyCheckPeerNamesubstitui, SSLProxyCheckPeerCNmas não funcionará, a menos que você especifique todas as diretivas.
dualed

3

Não se preocupe com o HTTPS entre o servidor front-end e o servidor back-end; há pouco sentido em ativar o SSL para uma localhostconexão.

Para esclarecer, use em ProxyPass / http://localhost:3002/vez deProxyPass / https://localhost:3002/


Como alternativa, se você realmente deseja conectar seu proxy reverso ao servidor de back-end usando SSL também (principalmente útil quando esse servidor não estiver onde o proxy reverso do Apache Httpd está), além de https://backend-server-addressusar as SSLProxy*diretivas para configurar o Certificados da CA, conforme documentado na introdução à mod_proxydocumentação . Em particular, você precisaria configurar SSLProxyCACertificateFilee garantir que o certificado do servidor de back-end seja emitido com o nome de host correto, como visto pelo Apache Httpd (isto é, localhostno seu caso).


Se você não estiver se conectando ao servidor back-end usando SSL, poderá não conseguir detectar se você está realmente usando SSL e estar configurado para forçá-lo a ir para SSL (daí os redirecionamentos infinitos). Você pode querer olhar para mecanismos semelhantes ao que o Jetty faz com sua forwardedopção (para poder dizer ao back-end que está atrás de um proxy). Os trilhos podem interpretar o X-Forwarded-Protopor padrão. Nesse caso, adicione isso à sua configuração do Apache (no host virtual SSL):

RequestHeader set X-Forwarded-Proto 'https'

Parece haver uma questão semelhante discutida aqui , por exemplo.


O SSLProxy é mencionado apenas uma vez nesse link. Não há exemplos de como usá-lo. Alterei o cabeçalho da solicitação para definir X-Forwarded-Proto 'https' ... mas ainda não funciona / recebo o mesmo erro. Indo para localhost: 3002 também dá o mesmo erro
NullVoxPopuli

Há motivos válidos para conectar-se a https com localhost: exemplo socket.io em um back-end HTTPS. Será através de erros com conteúdo misto.
Florestan06

3

Eu tive um problema semelhante (os mesmos logs de erro), exceto que o proxy estava encaminhando o tráfego https para outro host.
Como eu era preguiçoso e os hosts estavam em minha própria rede isolada, essas diretivas resolveram o problema:

SSLProxyVerify none
SSLProxyCheckPeerCN off


1

Se o servidor back-end usar certificado autoassinado desatualizado, será necessária mais uma opção (se não houver acesso ao servidor back-end):

SSLProxyCheckPeerExpire off

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.