TLS libpq: verify-full проверяет не только цепочку, но и имя сервера
Фотография конкретного исполнения не приложена.
Для подключения к нужной базе важно подтвердить личность сервера. Наличие шифрования само по себе не означает, что клиент проверил ожидаемое имя узла. В libpq режимы TLS имеют разные условия проверки, которые должны соответствовать требованию приложения.
Verify-ca проверяет цепочку сертификата до доверенного корня, а verify-full дополнительно сопоставляет имя подключения с сертификатом. Сведения о SAN, имени и адресном способе подключения оценивают по правилам конкретной библиотеки. Правильная цепочка другого допустимого сервера не является подтверждением нужного назначения.
Документация 18 описывает совместимое поведение require при наличии корневого CA-файла, но не рекомендует полагаться на него как на явную политику проверки. Для предсказуемого результата выбирают требуемый режим непосредственно. Клиентский сертификат решает другую сторону идентификации и не отменяет проверку сервера.
В приёмке используют нужный сервер, неверное имя, недоверенную цепочку и контролируемый просроченный сертификат. Проверяют реальный результат приложения, а не только другого клиента с иной конфигурацией. Успешный TLS-сеанс подтверждает выбранный уровень защиты канала; права роли на таблицы и правильность выбранной базы остаются отдельными условиями.
Основание — Official PostgreSQL major18 documentation snapshot; stable18.6 observed separately from19RC1, разделы Server certificate verification; require compatibility; client certificates. Сохранён текст публичной справочной публикации; конкретная реализация может поддерживать только часть возможностей. Использована документация ветки PostgreSQL 18; страницы обновляются внутри major-ветки. Версии действующих сервера и libpq, конфигурация и резервные копии не проверялись. Подключения, SQL-команды и восстановление не выполнялись.
