gRPC строго проверяет TLS-сертификаты. Если цепочка доверия, hostname, SAN или клиентские сертификаты настроены неверно, соединение не установится даже при работающем сервере.
Когда это становится проблемой
Сервис доступен по сети, но клиент получает ошибку certificate verify failed, unknown authority, hostname mismatch или handshake failure. Из-за этого ломаются межсервисные вызовы и очереди задач.
Что проверяю в первую очередь
- Цепочку сертификатов: leaf, intermediate, root CA
- SAN и совпадение имени, по которому подключается клиент
- Trust store клиента и наличие нужного CA
- Настройки mTLS: клиентский сертификат, key usage, срок действия
- Прокси, ingress или балансировщик, который может подменять TLS
Как исправляю
Я проверяю сертификат отдельно от кода, затем смотрю конфигурацию клиента и сервера. Это позволяет понять, проблема в криптографии, имени, доверии или прокси.
- Перевыпускаю сертификат с правильным SAN
- Добавляю нужный CA в trust store клиента
- Исправляю mTLS-настройки и клиентский сертификат
- Проверяю gRPC через grpcurl или тестовый клиент
Что важно не сломать
Нельзя выключать проверку сертификата в production. Это убирает защиту канала и делает систему уязвимой.
Что будет после исправления
- gRPC-клиент успешно подключается к серверу
- TLS или mTLS работает без отключения проверок
- Сертификаты имеют понятный срок и цепочку
- Появляется инструкция для ротации сертификатов
Что подготовить перед обращением
- Текст ошибки клиента
- Адрес gRPC-сервиса
- Сертификаты без приватных ключей для диагностики
- Конфиг клиента и сервера
Вопросы и ответы
Можно ли исправить без полной переделки?
Да, чаще всего достаточно исправить SAN, CA или trust store. Переписывать сервис не нужно.
Сколько времени занимает диагностика?
Если есть доступ к сертификатам и конфигам, причина обычно находится быстро.
Нужна похожая задача?
Напишите в Telegram @rabotator_support и коротко опишите проблему. Я посмотрю симптомы, предложу понятный план работ и скажу, какие доступы нужны для безопасного исправления.