Проверил браузером работу https на этих хостах - все в порядке. Zabbix-proxy проверяет больше десятка хостов, на которых есть https, но ложные срабатывания есть только на двух. Причем сами хосты не обновлялись и все было в порядке, пока zabbix-proxy работал на squeeze-lts.
Поискал в гугле и наткнулся на ветку в форуме, где описана аналогичная проблема. Включил DebugLevel=4 в zabbix-proxy и выловил описание проблемы в логе zabbix-proxy:
27111:20150405:124028.523 check_https: curl_easy_perform failed for [example.com:443]: SSL connect error 27109:20150405:124127.938 check_https: curl_easy_perform failed for [example.net:443]: SSL connect error 27111:20150405:124128.978 check_https: curl_easy_perform failed for [example.com:443]: SSL connect error 27108:20150405:124227.737 check_https: curl_easy_perform failed for [example.net:443]: SSL connect error
Пробую натравить wget на один из проблемных хостов:
$ wget --no-check-certificate -O /dev/null https://example.com/ --2015-04-05 14:59:49-- https://example.com/ Resolving example.com (example.com)... 192.168.1.14 Connecting to example.com (example.com)|192.168.1.14|:443... connected. GnuTLS: A TLS warning alert has been received. Unable to establish SSL connection.
Поиск по фразе "GnuTLS: A TLS warning alert has been received." привел меня к двум багрепортам в debian: #738625 и #686837.
Как оказалось на обоих хостах отсутствовала конфигурация ServerName или ServerAlias для example.com и example.net. Поскольку используются *.*.example.com и *.example.net, то проблема оставалась незамеченной, а после обновления сервера - выплыла наружу. После добавления конфигурации для example.com и example.net все пришло в норму.
Комментариев нет:
Отправить комментарий