Альтернативные имена субъекта: как идентифицируется сервер VPN

Ваш клиент отклоняет сертификат, цепочка которого проверяется безупречно, а ошибка сообщает, что имя не совпадает. Это сообщение не о том, кто подписал сертификат. Оно о расширении альтернативных имён субъекта, которое несёт идентичности, разрешённые сертификату, и о том, появляется ли настроенная вами идентичность там в правильной форме. Доверие отвечает, кто подписал, а проверка имени — какому узлу он принадлежит.

Что клиент действительно сравнивает

Клиент превращает вашу конфигурацию в эталонную идентичность: имя узла, адрес или идентификатор, специфичный для протокола. Затем он ищет эту идентичность в сертификате, применяя правила сопоставления используемого протокола. Учитываются только записи одного типа, поэтому запись DNS не может удовлетворить адрес, и сравнение происходит независимо от того, смотрит ли кто-нибудь на сертификат.

Когда эталонной идентичности нет в этом расширении, проверка не проходит, даже если старое общее имя совпадает. Сертификат может быть законно выдан компании и всё равно быть неподходящим для vpn.example.com, если имя никогда не включалось. Неудача — это несовпадение имени, хотя сертификат подлинный.

DNS-имена и IP-адреса — отдельные записи

Профиль, указывающий на 203.0.113.10, тогда как сертификат перечисляет только vpn.example.com, отклоняется, потому что пакеты приходят, но идентичность не совпадает. DNS-имена и буквальные адреса хранятся как разные типы записей, и одно никогда не заменяет другое. Поэтому сервис может быть доступен по адресу и всё же непригоден через профиль, использующий этот адрес.

Подстановочные знаки тоже подчиняются своим правилам: знак покрывает одну метку, а не каждое имя под доменом. Сравнение DNS не зависит от регистра, а другие типы идентификаторов зависят, поэтому значение, выглядящее на экране одинаково, может не пройти строгое сравнение. Проверяйте правила сопоставления для используемого типа идентичности, а не сравнивайте строки на глаз. Добавление имени в расширение — решение при выпуске, а не то, что может обеспечить настройка клиента.

Изучите сертификат, который соединение действительно использовало

Читайте материал, который представляет активная конечная точка, а не файл, скопированный со страницы администрирования. Балансировщик нагрузки или запасной экземпляр может представить нечто иное, чем сертификат, загруженный месяцы назад, и эта разница не видна в консоли.

openssl s_client -connect vpn.example.com:443 -showcerts </dev/null | openssl x509 -noout -text

Блок альтернативных имён субъекта, цепочка издателя и срок действия относятся к одному чтению, потому что несовпадение имени и истечение срока дают разные ошибки. Сравните каждое имя из этого блока с идентичностью, настроенной в профиле, посимвольно и отметьте, к какому типу оно относится. Повтор команды для адресной формы конечной точки показывает, покрывает ли сертификат обе идентичности или только одну. Дружественное отображение субъекта в консоли управления не является результатом проверки и ничего не говорит о том, какие имена содержит расширение.

Общее имя — не современный источник истины

Браузеры и большинство библиотек TLS теперь игнорируют общее имя при сопоставлении имени узла и обращаются к расширению. Некоторые клиенты VPN по-прежнему сначала сравнивают общее имя или возвращаются к нему, когда расширение отсутствует, и поэтому один сертификат может пройти в браузере и не пройти в клиенте. Та же проверка имени может пройти на одной платформе и не пройти на другой, даже если сертификат совсем не меняется.

Выясните, какое поле читает ваш клиент, прежде чем решать, что сертификат неверен. Два клиента на одной конечной точке могут расходиться, и это расхождение — информация о клиенте, а не о сертификате.

Исправляйте выпуск или профиль, а не проверку

Если профиль построен вокруг псевдонима, либо перенаправьте его на документированное имя узла, либо перевыпустите сертификат для псевдонима и разверните его в запланированное окно. Заглушить предупреждение — не третий вариант, потому что проверка — единственный шаг, привязывающий подписанный сертификат к этому конкретному узлу. Её удаление означает, что любой сертификат того же органа может занять место сервера, к которому вы хотели подключиться.

Продление должно сохранять предполагаемые имена и назначение, а не просто сдвигать дату истечения вперёд. Продление, теряющее имя, — это новый сбой, запланированный на следующую перезагрузку, и обычно он приходит без предупреждения, потому что старый сертификат был ещё действителен, когда вносилось изменение.

Запишите ожидаемую идентичность, представленные имена и цепочку, которая их подписала. Эта запись превращает следующее продление в сравнение, а не в расследование. Определение расширения есть в RFC 5280, если нужно проверить конкретный выпуск.