Проблемы с сервисом OCSP 12 и 13 июня 2021 года

#1

Добрый день,

Мы, на нашем сервисе https://sigex.kz, в последние два дня периодически наблюдали проблемы с получением ответов от сервиса OCSP НУЦ РК (http://ocsp.pki.gov.kz/).

В частности сервис OCSP НУЦ РК не отвечал в следующие промежутки времени:

  • 12.06.2021 22:52-22:55
  • 12.06.2021 23:20-23:42
  • 13.06.2021 00:33-00:43
  • 13.06.2021 01:05-01:14
  • 13.06.2021 02:55-02:57
  • 13.06.2021 03:07-03:18
  • 13.06.2021 03:43-03:46
  • 13.06.2021 03:51-03:53
  • 13.06.2021 06:23-06:26
  • 13.06.2021 16:39-16:50
  • 13.06.2021 18:35-18:54
  • 13.06.2021 18:57-19:05

В результате недоступности сервиса OCSP в указанные промежутки времени наши пользователи не могли выполнять аутентификацию и подписывать документы ЭЦП.

Новостей о проведении плановых работ в указанные промежутки времени мы на сайте НУЦ РК (https://pki.gov.kz) не обнаружили.

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

#2

Здравствуйте, 12.06.2021 проводились работы на стороне НУЦ РК в результате OCSP мог быть недоступен в течении 3-5 секунд но в промежутке с 22:00 до 22:30.

Касательно того, что сервис не отвечал 13.06.2021 мы можем выполнить точную проверку если Вы предоставите ваш статический (белый) IP адрес, с которого происходит подключение к ocsp.pki.gov.kz.

#3

Добрый день,

Наш сервис отправляет запросы с адреса 185.116.194.207.

Мы регистрировали идентичное поведение OCSP сервиса 12 и 13 числа - соединение устанавливалось, но никаких данных (даже заголовков HTTP ответа) от OCSP сервиса не приходило.

#4

Анализ логов по вашему IP показал, что иногда бывают ошибки:
“POST / HTTP/1.1” 499 0 “-” “Go-http-client/1.1”

Во всех остальных 99% случаев отдаётся успешный ответ 200.

Для примера прикладываю вырезку из логов по запросам с 18:00 до 18:59.
207

#5

Согласен, чаще всего сервис OCSP отвечает корректно.

Но каждый некорректный ответ - это проблема проверки подписи пользователя. Именно поэтому я и интересуюсь чем были вызваны всплески некорректных ответов и как в будующем этого избежать.

В приведенном Вами журнале записей явно меньше, чем зарегистрировано у нас. Присутствует ли у Вас информация о том, по какой причине сервис OCSP вернул ошибку?

#6

Привожу нашу статистику:

  • 12 число, запросы к сервису OCSP
    12%20-%20requests

  • 12 число, проблемы
    12%20-%20errors

  • 13 число, запросы к сервису OCSP
    13%20-%20requests

  • 13 число, проблемы
    13%20-%20errors

#7

В данном случае этого исключительно Ваша статистика, как вы писали выше “никаких данных (даже заголовков HTTP ответа)” - может означать, что проблема могла быть также и на сетевом уровне, как у Хостер-провайдера, так и стыке между операторами связи.

А сегодня у Вас были аналогичные проблемы ?

#8

В данном случае этого исключительно Ваша статистика, как вы писали выше “никаких данных (даже заголовков HTTP ответа)” - может означать, что проблема могла быть также и на сетевом уровне, как у Хостер-провайдера, так и стыке между операторами связи.

Думаю что если бы проблема была на сетевом уровне, то устанавливать соединение бы не удавалось. Хотя всякое бывает, да, приведенная мной статистика - это ситуация с точки зрения исключительно нашего сервера.

А сегодня у Вас были аналогичные проблемы ?

Нет, сегодня проблем не наблюдалось.

#9

Меня немного смущают данные из приведенного журнала - первая запись в 13:18, потом уже в 18:50. Но мы точно получили от OCSP сервиса множество квитанций в этот промежуток времени.

И аналогично пробел с 18:59 по 21:18.

12%20-%2012-24

Могу разве что предположить что это журнал с одного из узлов OCSP сервиса, перед несколькими узлами может стоять балансировщик. В этом случае наши запросы могли не достигать узлов OCSP сервиса, если балансировщик не мог связаться с узлами. Мою гипотезу можно проверить изучив журналы балансировщика.

#10

Кстати в приведенном журнале странный код статуса HTTP на предпоследней строке: 499. Так и должно быть?

#11

Я специально указал в логе пример на 499 ошибку, это означает что клиент т.е. ваш сервер закрыл соединение до того как получил ответ.
Это наводит на мысль, что у вас возможно установлен слишком короткий time_out на время ответа от нашего сервиса, как вариант 1-2 секунды либо ещё это больше указывает на сетевые проблемы.

#12

Я специально указал в логе пример на 499 ошибку, это означает что клиент т.е. ваш сервер закрыл соединение до того как получил ответ.
Это наводит на мысль, что у вас возможно установлен слишком короткий time_out на время ответа от нашего сервиса, как вариант 1-2 секунды либо ещё это больше указывает на сетевые проблемы.

У нас установлен таймаут в 2 секунды, Вы рекомендуете ждать дольше?

#13

Конечно 2 секунды это мало, Выши ведь сервера не находятся на одной площадке с нашими + подключение идёт через разных операторов связи, Вы можете сами запустить traceroute и проверить через сколько точек происходит подключение.

#14

у нас таймаут 30 секунд. ничего не работает, сам ваш форму через раз выдает ошибку 500

#15

Форум кидает 500 ошибку, из-за межсетевого-экрана от РГП “ГТС”, по этой проблеме уже с ними отрабатываем.

Как понять, что у вас ни чего не работает? Скорее всего, Вы не правильно подключаетесь к сервису OCSP.

#16

да, 2 года я подклчался правильно, а сегодня начал подключаться неправильно.

#17

если в ответ на команду telnet ocsp.pki.gov.kz 80 я получаю ответ “Подключение к ocsp.pki.gov.kz…Не удалось открыть подключение к этому узлу, на порт 80: Сбой подключения”

Это правильное подключение или неправильное?

#18

Давай-те проверим, напишите белый IP с которого пытаетесь подключиться.

#19

Хорошо, мы увеличим таймаут. В том случае, если будут возникать новые проблемы, напишу.

Между прочим, Вас интересуют сторонние метрики доступности сервисов НУЦ? Мы могли бы публиковать данные в каком-нибудь виде, если так же будут поступать другие системы, то Вы сможете получать достаточно объективное представление.

#20

Метрики не так интересны, а вот от стороннего мониторинга доступности были бы не против :slight_smile: