Comments 14
exchange.nagios.org/directory/Plugins/Network-Protocols/HTTP/check_ssl_certificate/details
Спасибо, пожалуйста.
:)
Спасибо, пожалуйста.
:)
Приведённый код при протухшем серте выплюнет исключение в GetResponse, до получения request.ServicePoint.Certificate дело не дойдёт.
Логику проверки сертификата лучше вынести в ServicePointManager.CertificateValidationCallback, где можно задать свои правила обработки. Например, игнорировать проблемы с истечением срока сертификата пару недель, как раз за это время владелец сервиса всё починит.
Логику проверки сертификата лучше вынести в ServicePointManager.CertificateValidationCallback, где можно задать свои правила обработки. Например, игнорировать проблемы с истечением срока сертификата пару недель, как раз за это время владелец сервиса всё починит.
Это из серии «спрятать голову в песок, но не слишком глубоко». Представьте, что все заинтересованные прочитают ваш комментарий и последуют этому совету. Тогда просто у всех все сломается на пару недель позже.
Приведённый код при протухшем серте выплюнет исключение в GetResponse, до получения request.ServicePoint.Certificate дело не дойдёт.
В этом случае все уже достаточно плохо, вы об этом узнаете и без явной проверки даты.
Перед этим кодом специально написано «примерно». Нужно еще учесть, что, например, Azure Storage возвращает HTTP 400 (Bad Request), если запросить URL, в котором не указан путь к конкретному элементу данных. В этом случае тоже будет исключение, его нужно обрабатывать. Но даже если и будет HTTP 400, сертификат загрузится с сервера и его можно будет проверить.
Что хотел сказать автор?
Что у сертификатов есть срок действия и для https его (ого!) можно увидеть прямо в браузере?
Или что «большие папы» тоже косячат?
Или что все сервисы, от которых зависит ваша система, нужно поставить но мониторинг?
Что у сертификатов есть срок действия и для https его (ого!) можно увидеть прямо в браузере?
Или что «большие папы» тоже косячат?
Или что все сервисы, от которых зависит ваша система, нужно поставить но мониторинг?
Вы так спрашиваете, как будто последнее утверждение всем очевидно. Обратите внимание, что истечения срока действия сертификатов Azure Storage в феврале можно было ожидать заранее, но тем не менее никто из пользователей ничего не заметил до момента, когда стало слишком поздно.
Я так спрашиваю, потому, что мне не понятен посыл статьи.
Немного расширю свою точку зрения: пользователи Azure Storage и не должны были замечать, что сертификаты скоро закончатся.
Объясню на личном примере: я работал тех. руководителем в организации, которая (в том числе) подключала десятками поставщиков услуг к своей системе. Т.к. у поставщиков услуг шлюзы, мягко говоря, работали не всегда так, как задумано (даже не по протоколам, разработанными этими поставщиками услуг — вроде и сходство есть, а вроде и не работает), то руководитель отдела интеграции от меня получил очень короткое, но ёмкое указание «предусмотреть ЛЮБУЮ нештатную ситуацию».
Там и реверс инженеринг протоколов был. Там и сертификаты проверялись хитрым образом (кстати, большинство сертификатов были самоподписные) и система могла продолжить работу даже с невалидным сертификатом (при соблюдении некоторых других условий) и выдать предупреждение на саппорт. И ДНСу мы не доверяли, сохраняя ИПшники и выбирая подходящий вариант. И другой веселухи было много (кстати говоря, не всегда эти ухищрения помогали — один раз партнёр так хитро поменял роутинг, что вместо продакшн шлюза все наши запросы уходили на тест. после этого было желание начать статические маршруты прописывать). Но это всё делалось только из-за того, что партнёры подключались на «взаимовыгодных условиях».
С другой стороны у нас был дата-центр, где хостился продакшн. И никогда я не давал задачу саппорту изощряться также, как интеграции (естественно, минимальный мониторинг состояния ДЦ был, например, загруженность канала). Тут принцип прост: мы платим деньги и хотим получить качественную услугу. Если что-то не работает по вине ДЦ (даже если мы теоретически могли предупредить эту проблему), то это вина ДЦ и он нёс за это ответственность (в т.ч. финансовую).
Я понимаю, что сравнивать по SLA несколько стоек в ДЦ и хостинг на Azure не совсем корректно, но какие-то уровни разграничения ответственности должны быть. Лично я бы после такой ерунды просто ушёл бы с Azure.
Немного расширю свою точку зрения: пользователи Azure Storage и не должны были замечать, что сертификаты скоро закончатся.
Объясню на личном примере: я работал тех. руководителем в организации, которая (в том числе) подключала десятками поставщиков услуг к своей системе. Т.к. у поставщиков услуг шлюзы, мягко говоря, работали не всегда так, как задумано (даже не по протоколам, разработанными этими поставщиками услуг — вроде и сходство есть, а вроде и не работает), то руководитель отдела интеграции от меня получил очень короткое, но ёмкое указание «предусмотреть ЛЮБУЮ нештатную ситуацию».
Там и реверс инженеринг протоколов был. Там и сертификаты проверялись хитрым образом (кстати, большинство сертификатов были самоподписные) и система могла продолжить работу даже с невалидным сертификатом (при соблюдении некоторых других условий) и выдать предупреждение на саппорт. И ДНСу мы не доверяли, сохраняя ИПшники и выбирая подходящий вариант. И другой веселухи было много (кстати говоря, не всегда эти ухищрения помогали — один раз партнёр так хитро поменял роутинг, что вместо продакшн шлюза все наши запросы уходили на тест. после этого было желание начать статические маршруты прописывать). Но это всё делалось только из-за того, что партнёры подключались на «взаимовыгодных условиях».
С другой стороны у нас был дата-центр, где хостился продакшн. И никогда я не давал задачу саппорту изощряться также, как интеграции (естественно, минимальный мониторинг состояния ДЦ был, например, загруженность канала). Тут принцип прост: мы платим деньги и хотим получить качественную услугу. Если что-то не работает по вине ДЦ (даже если мы теоретически могли предупредить эту проблему), то это вина ДЦ и он нёс за это ответственность (в т.ч. финансовую).
Я понимаю, что сравнивать по SLA несколько стоек в ДЦ и хостинг на Azure не совсем корректно, но какие-то уровни разграничения ответственности должны быть. Лично я бы после такой ерунды просто ушёл бы с Azure.
Посыл статьи предельно простой: есть такой риск, заранее принять меры очень легко и вы сами выбираете — принять меры заранее или надеяться на поставщика сервиса. Это не непредвиденная ситуация, потому что все нужные данные постоянно на виду.
Я вот тут написал абстрактно-развёрнутый комментарий, насколько мы не надеялись на поставщиков :)
UFO just landed and posted this here
У нас в нагиосе есть проверка для наших SSL-сервисов на срок протухания сертификата. За месяц до протухания выдаёт warning, потом CRITICAL.
Легко гуглится по nagios plugin certificate expiration или подобным.
Легко гуглится по nagios plugin certificate expiration или подобным.
Можно начать с заданий попроще — например с доменных имен.
Infox.ru — достаточно крупный сетевой игрок СМИ, срок регистрации домена истек 2013.05.01, регистратор не сменил делегирование домена, и вот аккурат через месяц 2013.06.01 домен будет выключен и удалён (поправка на ветер — 2013.06.04, выходные всё же).
Хотя можно только догадываться, ведь делегирование закончившегося домена должно было сняться автоматически. Либо это VIP-клиент и ему просто так его не снимают (ага, можно вспомнить тот же Хабр или Ulmart), либо на домен наложены судебные санкции (но гуглится мало, только иск о защите деловой репутации, как раз завтра заседание).
Интересен другой факт — владельцы доменов частенько узнают об окончании регистрации домена только тогда, когда он будет выключен (читай заменен на заставку регистратора). И уже носятся сломя голову — как продлить домен и пнуть cctld dns сервера.
Infox.ru — достаточно крупный сетевой игрок СМИ, срок регистрации домена истек 2013.05.01, регистратор не сменил делегирование домена, и вот аккурат через месяц 2013.06.01 домен будет выключен и удалён (поправка на ветер — 2013.06.04, выходные всё же).
Хотя можно только догадываться, ведь делегирование закончившегося домена должно было сняться автоматически. Либо это VIP-клиент и ему просто так его не снимают (ага, можно вспомнить тот же Хабр или Ulmart), либо на домен наложены судебные санкции (но гуглится мало, только иск о защите деловой репутации, как раз завтра заседание).
Интересен другой факт — владельцы доменов частенько узнают об окончании регистрации домена только тогда, когда он будет выключен (читай заменен на заставку регистратора). И уже носятся сломя голову — как продлить домен и пнуть cctld dns сервера.
Sign up to leave a comment.
Облака, ответственность и неожиданные ситуации с SSL-сертификатами