Проблема SSL handshake с удаленным сервером apache httpd, работает локально


Я получаю странный вопрос: Я установил / настроил ssl-сертификат / ключ и ca certs etc в apache, и теперь могу получить доступ к нему на последнем браузере chrome/firefox с локальной машины, и они показывают, что сертификат все хорошо (общий зеленый значок замка), а также показывает его с помощью современного набора шифров. Обратите внимание, что я обращаюсь к нему с локальной машины через само имя сервера, а не с localhost и т. д., а не путем изменения файла hosts.. Кроме того, он доступен с другого компьютера в той же сети без каких-либо вопрос..

Но когда я пытаюсь получить доступ к этому с другой, удаленной машины (не в той же сети) или через vpn и т. д., Я получаю ошибку ssl-соединения. Firefox указывает: "Peer сообщает, что произошла внутренняя ошибка. (Код ошибки: ssl_error_internal_error_alert)".

Я использовал команду openssl на удаленной машине для имитации клиента:

*openssl s_client -connect xyz.com:443 -state -nbio 2>&1*

Он показывает:

WARNING: can't open config file: /usr/local/ssl/openssl.cnf
Loading 'screen' into random state - done
CONNECTED(00000170)
turning on non blocking io
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:error in SSLv2/v3 read server hello A
write R BLOCK
SSL3 alert read:fatal:internal error
SSL_connect:error in SSLv2/v3 read server hello A
7020:error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error:.ssls23_clnt.c:762:
- - - 
no peer certificate available
- - - 
No client certificate CA names sent
- - - 
SSL handshake has read 7 bytes and written 307 bytes
- - - 
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
- - - 

Я должен использовать apache httpd, чтобы использовать https, и запросы fwd к tomcat, который использует только http, и использовал ajp-прокси для эта цель.

Я попытался удалить конфигурацию прокси, перезапустил и все еще не повезло - на локальной машине он показывает страницу" it works", а на удаленной машине та же ошибка ssl-соединения. Ничто в журналах apache также не соответствует попыткам с удаленной машины (т. е. они не доходят до этих журналов).

Но, как ни странно, существующая конфигурация действительно работает с удаленной машины в течение 30-40 минут (т. е. в течение некоторого времени) после длительного неработающего периода. а потом то же самое настройки еще раз перемешайте.. не могу понять почему. В течение всего этого периода он всегда остается доступным / прекрасным из локальной машины..

Вот ssl-conf:

SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:SSL_RSA_WITH_RC4_128_SHA:HIGH:MEDIUM:!MD5:!RC4
SSLProxyCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:HIGH:MEDIUM:!MD5:!RC4
SSLHonorCipherOrder on 
SSLProtocol all  -SSLv2 -SSLv3
SSLProxyProtocol all -SSLv2  -SSLv3
SSLSessionCache        "shmcb:c:/Apache24/logs/ssl_scache(512000)"
SSLSessionCacheTimeout  300
SSLUseStapling On
SSLStaplingCache "shmcb:c:/Apache24/logs/ssl_stapling(150000)"
SSLStaplingStandardCacheTimeout 3600
<VirtualHost *:443>
    DocumentRoot "c:/Apache24/htdocs"
    ServerName www.xyz.com
    ServerAlias xyz.com

    ServerAdmin info@xyz.com
    ErrorLog "c:/Apache24/logs/error.log"
    TransferLog "c:/Apache24/logs/access.log"
    SSLEngine on
    SSLCertificateFile "C:/Apache24/xyz/certs/server.crt"
    SSLCertificateKeyFile "C:/Apache24/xyz/certs/private_key_no_pswd.pem"
    SSLCertificateChainFile "C:/Apache24/xyz/certs/gd_bundle-g2-g1.crt"
    <FilesMatch ".(cgi|shtml|phtml|php)$">
        SSLOptions +StdEnvVars
    </FilesMatch>
    <Directory "c:/Apache24/cgi-bin">
        SSLOptions +StdEnvVars
    </Directory>
    CustomLog "c:/Apache24/logs/ssl_request.log" 
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x "%r" %b"
    #ProxyRequests Off
    ProxyPreserveHost On
    SSLProxyEngine on
    SSLProxyVerify none 
    SSLProxyCheckPeerCN off
    SSLProxyCheckPeerName off
    SSLProxyCheckPeerExpire off

    <Proxy *>
        #Order allow,deny
        Allow from all
        Deny from none
        Require all granted

        #Deny from all
        #Allow from 127.0.0.0/255.0.0.0 ::1/128

        # Order deny,allow
        # Allow from localhost
        # Require ip 127.0.0.1
    </Proxy>

    ProxyPass   /  ajp://localhost:8009/
</VirtualHost> 

Вы можете увидеть много вещей, которые были опробованы в конфигурациях virtualHost (было отказано в разрешении и другие проблемы), и пробовали много вещей, пока это не сработало с локальной машины..

Мой env-это: Win-XP sp3 (я знаю его старый), ApacheLounge httpd - VC-10 v-2.4.x (на порту 443), tomcat-1.6 (на 8080)

Пожалуйста, позвольте мне знайте, если я делаю что-то не так, или вам нужен любой другой конфиг, чтобы увидеть.

Спасибо.

1 2

1 ответ:

Это работает в локальной сети, а не за ее пределами, это очень похоже на брандмауэр, защищающий вашу сеть. Другая возможность заключается в том, что одно и то же имя хоста разрешается на разные IP-адреса в вашей локальной и удаленной сети, и таким образом он пытается связаться с разными хостами из локальной и удаленной. И еще одна вещь может заключаться в том, что имя хоста разрешается в адреса IPv4 и IPv6, но ваш сервер использует только IPv4. Если вы тогда делаете только IPv4 в вашей локальной сети, а другая сеть может у IPv6 вы увидите аналогичные эффекты.

Для отладки этой проблемы я бы предложил делать захваты пакетов у вашего локального клиента, у удаленного клиента и сравнивать их. Также проверьте с помощью захвата пакетов, достигают ли данные от удаленного клиента сервера вообще (или если брандмауэр блокирует его).

Edit: из комментария видно, что локальный и удаленный клиент видят разные IP-адреса для одного и того же сервера. Чтобы отладить, почему это так, сначала проверьте, что обе стороны фактически используют одно и то же сервер, потому что часто вы видите, что один использует www.example.com а другой example.com (без www) но есть разные IP-адреса для имен. Если вы уверены, что это не так, проверьте, каким должен быть реальный IP-адрес, а затем более подробно посмотрите на партию, которая имеет неправильное имя. Это неправильное имя может быть вызвано записью в файле hosts (от тестирования?), кэшированными записями (изменения в DNS занимают некоторое время для распространения , Иногда день или больше) или потому, что используется настройка split DNS. Split DNS не является редкостью в компаниях, где у них есть серверы, обращенные к extern и intern, и они хотят, чтобы клиенты intern использовали внутренний IP-адрес, а клиенты extern-внешний IP-адрес.