#Признаки неисправности и область применимости
Клиент не может подключиться по TLS к управляемой базе данных Yandex Cloud: соединение отклоняется, не проходит проверку сертификата или завершается ошибкой handshake. Параметры зависят от СУБД: PostgreSQL, MySQL и другие кластеры используют разные протоколы и настройки драйверов.
#Почему это происходит
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Не доверяют корневому сертификатуКлиентский контейнер/ОС не знает используемый корневой центр. | certificate verify failed или unable to get issuer certificate | Установите официальный доверенный корень. |
| Неверный адрес и режим TLSКлиент подключается по IP/псевдониму либо не проверяет имя. | hostname mismatch или sslmode=require вместо verify-full | Используйте официальный FQDN узла и проверку имени. |
| Сетевой путь или доступНеправильные группы безопасности и доступность хостов не являются ошибкой TLS. | Connection timed out до начала TLS | Проверьте сеть и порт отдельно. |
#Пошаговая диагностика и устранение
- Выясните СУБД и точный код ошибкиВ консоли выберите управляемую БД и запишите тип сервиса, кластер, FQDN и порт. В логе клиента найдите, где ошибка: DNS, TCP, сертификат, пароль либо разрешение БД. Не включайте отладку, публикующую полный URI подключения с паролем.
- Проверьте доступность сети до TLSПроверка сертификата не пройдёт, если TCP-соединение не установлено. С машины приложения проверьте доступность порта назначенного хоста и правила групп безопасности. Для публичного хоста PostgreSQL используется TLS, а внутренние маршруты зависят от сети и настроек кластера.
- Подставьте реальный FQDN и порт из карточки кластера; 6432 приведён как пример PostgreSQLLinux · Терминал (Bash)КомандаПодставьте реальный FQDN и порт из карточки кластера; 6432 приведён как пример PostgreSQL. Требуется утилита nc; успех подтверждает только TCP, не аутентификацию.
nc -vz -w 5 DB_HOST 6432
- Получите официальный сертификат CAДля Managed PostgreSQL документация предоставляет RootCA.pem по HTTPS в официальном хранилище Yandex Cloud. Скачайте его в закрытый каталог клиента и проверьте происхождение. Не принимайте сертификат из письма неизвестного отправителя и не ставьте sslmode=disable.
- Linux/macOS, в предварительно выбранном рабочем каталоге; без администратораLinux · Терминал (Bash)КомандаLinux/macOS, в предварительно выбранном рабочем каталоге; без администратора.
-fзавершает команду с ошибкой при HTTP 4xx/5xx,-oсохраняет файл. Для другой СУБД сверяйте её документацию.curl -fSLo RootCA.pem https://storage.yandexcloud.net/cloud-certs/RootCA.pem
- Настройте доверие в библиотеке клиентаДля PostgreSQL в настройках приложения укажите корректные параметры
sslmode=verify-fullи путь к CA черезsslrootcert. Для Java используйте настройку хранилища доверенных сертификатов; не импортируйте только случайный промежуточный сертификат как единственный якорь доверия.
- Сверьте имя хостаСтрока подключения должна использовать FQDN из параметров кластера, а не случайный IP. Проверка
verify-fullсравнивает имя сервера с сертификатом. Не обходите несовпадение отключением проверки; исправьте адрес и доверенный корень.
- Проверьте срок и ротацию сертификатаЕсли ошибка появилась после обслуживания облака, проверьте новости о цепочке TLS. Документация предупреждает о смене промежуточных сертификатов при сохранении корневого доверия. При закреплении отдельного сертификата удалите ненужное закрепление в тестовой среде.
- Проверьте учётные данные отдельноПосле успешного TLS-рукопожатия может появиться ошибка пароля или отсутствия прав на БД — она не исправляется CA. Проверьте логин, название базы и разрешение доступа в самом кластере, не меняя TLS-параметры.
- Подтвердите соединение через приложениеВыполните безопасный запрос чтения в тестовой БД, проверьте сведения о шифрованном соединении средствами выбранного драйвера. Убедитесь, что у всех экземпляров приложения одинаковый корневой сертификат; при неуспехе восстановите прежнюю конфигурацию клиента.
#Как проверить, что проблема исправлена
Запрос из приложения проходит с проверкой сертификата и имени узла, шифрование активно, учётная запись авторизуется; после повторного подключения и смены хоста внутри кластера клиент сохраняет работоспособность.
#Если проблема осталась
Если TCP недоступен, разбирайтесь с сетью, а не с CA. Если TLS проверка проходит, но вход запрещён, проверьте права пользователя. Не используйте sslmode=disable, sslmode=require как постоянную замену полной проверки имени там, где нужна строгая аутентификация узла.