Я создал API (работающий на сервере nginx, дайте мне знать, есть ли какие-либо детали, которые вы считаете актуальными) для клиента, и они получили эту ошибку при попытке вызвать мою службу:
Notice: SSL certificate problem: self signed certificate in certificate chain
in /usr/local/zend/apache2/htdocs/PefcSCS/components/ \
com_pefcscs/views/simplesearchs/tmpl/default.php on line 9
Я не могу воспроизвести эту ошибку, и у меня нет самозаверяющего сертификата. В журналах я вижу:
$ sudo tail -n 100 /var/log/nginx/error.log
2014/05/04 07:17:09 [crit] 24027#0: *844 SSL_do_handshake() failed
(SSL: error:05066066:Diffie-Hellman routines:COMPUTE_KEY:invalid
public key error:1408B005:SSL routines:SSL3_GET_CLIENT_KEY_EXCHANGE:DH lib)
while SSL handshaking, client: xx.169.xx.141, server: 0.x.0.x:443
Что говорит: invalid public key error. Означает ли это, что они предоставили недействительный открытый ключ? Может ли кто-нибудь объяснить смысл ошибки и как решить эту проблему? Спасибо.
РЕДАКТИРОВАТЬ: P.S. Я только предполагаю, что эти два момента связаны, это может быть совпадением, и я предполагаю связь между неудачным обменом открытым ключом и странной ошибкой моих клиентов, утверждающей, что у нас есть самоподписанный сертификат.
Вероятно, еще нет ответа, но больше, чем я могу прочитать в комментариях:
Этот код ошибки (и строка) о Диффи-Хеллман открытый ключ. Если вы не используете статический DH, что было бы очень необычно - я даже не видел, чтобы публичный CA выдавал сертификат DH - это должен быть эфемерный ключ DH клиента для набора шифров DHE. То, что он недействителен, предполагает что-то довольно странное в клиентском стеке SSL, «атаку» (или, по крайней мере, повреждение) сеанса, или сбивание параметров DH на вашем сервере - всего этого не должно происходить. Если клиент заявляет «самоподписанный сертификат», а вы его не используете, это другая проблема, которая не должна быть связана, но, возможно, связана с какой-то странной ошибкой.
Клиент, похоже, представляет собой что-то в PHP, с которым я не знаком, но я предполагаю, что он, вероятно, использует openssl для создания клиентских SSL-соединений (в данном случае для вас) (так же, как nginx AFAIK использует openssl на стороне сервера) . Если вы настроили свой сервер для предоставления полной цепочки сертификатов, включая корень, а клиент openssl не имеет этого корня в используемом им хранилище доверенных сертификатов (что может быть настраиваемым), он может ошибочно сообщить о `` самозаверяющем сертификате '', а не о более точном "ненадежный корень".
Если я прав, это openssl, можете ли (вы спросите) люди-клиенты попробовать подключиться к вам с помощью командной строки openssl s_client, с тем же хранилищем доверенных сертификатов, которое используется их программой, и тем же списком шифров (возможно, по умолчанию) - и посмотрите, возникает ли какая-либо ошибка, и если да, то информацию об ошибке (гораздо более подробную) выдает s_client? Другими словами, команда будет выглядеть примерно так:
openssl s_client -connect $yourhost:$yourport -CAfile $file_if_any -CApath $dir_if_any -cipher $string_if_any
(Если он все же подключается, просто нажмите Ctrl-D, чтобы выйти, ничего не отправляя.) Если s_client говорит что-то вроде verify error: ... self-signed, они должны исправить используемое хранилище доверенных сертификатов, чтобы включить корневой сертификат используемой вами цепочки. (Это может означать изменение использования другого хранилища доверенных сертификатов, если они не могут или не хотят изменять тот, который используют в настоящее время.)
А пока что (если что) настроено на вашем сервере для ssl_dhparam ? Попробуйте openssl dhparam -check -noout в этом файле на всякий случай, хотя что-то не так должно было произойти на более раннем этапе рукопожатия.
Когда другие (клиентские) соединения завершаются успешно, можете ли вы проверить, согласовывают ли они DHE или нет? Помните, что сертификат RSA, наиболее распространенный на сегодняшний день, может поддерживать простые шифры RSA DHE-RSA и ECDHE-RSA. Некоторые клиенты могут отображать выбранный шифр, в частности, большинство браузеров, если ваш сервер принимает запросы https браузера. Сам я не использую nginx, но http://osdir.com/ml/nginx/2010-07/msg00033.html указывает, что он может регистрировать это. s_client всегда сообщает вам шифр и многое другое.
Если проблема все еще возникает, можете ли вы, они или кто-то другой получить сетевой захват - с помощью wirehark / tshark, tcpdump или аналогичного - неудачного соединения? Это подтвердит набор шифров и другие используемые параметры и покажет обмен DHE до сбоя, что должно, по крайней мере, сузить проблему. Самый простой способ просмотра (IMO) - отобразить в wirehark (даже если вы захватили что-то еще), развернуть ServerHello и получить CipherSuite, а также развернуть ServerKeyExchange и ClientKeyExchange и получить все подробности.