Обновлённый сертификат VPN: некоторые клиенты всё ещё отвергают его

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

Одно обновление, два поведения

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

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

Обновление заменяет объект, а не только дату

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

openssl x509 -in server.pem -noout -subject -issuer -dates -fingerprint -sha256
openssl x509 -in server.pem -noout -pubkey | openssl sha256

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

Прочитайте, что закрепляет клиент

Одни клиенты держат отпечаток в своём профиле и сравнивают его при каждом подключении. Другие хранят его в хранилище доверия платформы, а третьи полагаются только на CA. Исправление в каждом случае разное, поэтому сначала определите механизм.

grep -n 'peer-fingerprint' /etc/openvpn/client/*.conf
openssl s_client -connect gw.lab.example.net:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -fingerprint -sha256

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

Сравните сертификат, который отдаёт каждый backend

Прерывистые результаты обычно означают больше одной конечной точки, и обновление, применённое на одном узле, оставляет остальные показывать старый объект. Сравнивайте каждый backend по адресу, а не по общему имени.

for h in 10.30.0.11 10.30.0.12; do echo "$h"; openssl s_client -connect $h:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -subject -dates -fingerprint -sha256; done

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

Меняйте доверие управляемым путём

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

Затем проверьте по каждому клиенту: подключитесь, подтвердите принятую им идентичность и зафиксируйте версию сертификата, которой он теперь доверяет. Однажды отклонённое предупреждение имеет обыкновение возвращаться при следующем обновлении.