Обновление сертификата VPN без изменения его идентичности

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

Три условия определяют форму обновления

Три условия таковы: что-то закрепляет лист или нет, меняется ли цепочка и кто ещё проверяет имя. Отвечайте со стороны клиента, а не из удобства CA, потому что именно клиент отказывает в три часа ночи.

Начните с проверки имеющегося сертификата. openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName выводит субъект, издателя, окно действия и имена, для которых сертификат действительно действителен. Последнее поле важнее всего и чаще всего подразумевается: запрос на обновление, в котором пропущен SAN, на который полагается клиент, даёт сертификат, технически действительный, но функционально неверный. Скопируйте список SAN из старого сертификата в запрос, а не набирайте его заново по памяти.

Условие первое: закрепляет ли что-то лист

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

Выясните, в каком вы случае, прежде чем что-либо заказывать. Закрепление, которое никто не задокументировал, остаётся закреплением, когда ломается.

Условие второе: сравните закрепления и цепочку

Отпечатки делают закрепление проверяемым: openssl x509 -noout -fingerprint -sha256 -in server.crt на старом и новом сертификате и openssl x509 -noout -pubkey для сравнения открытых ключей. Если конфигурация клиента, мобильный профиль или хранилище доверия устройства содержит любое из значений, у вас есть закрепление. Мобильные профили VPN — частое укрытие, потому что профиль распространяется один раз и больше никогда не проверяется.

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

Проверьте цепочку, которую сервер действительно отправляет, с помощью openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts и подтвердите её локально с помощью openssl verify -CAfile ca.pem -untrusted chain.pem server.crt. Если сделать это до изменения, у вас будет базовая линия для последующего сравнения.

Условие третье: кто ещё проверяет имя

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

Перечислите каждого потребителя до изменения и решите для каждого, нуждается ли он в обновлении. Тот, кого вы забудете, и позвонит вам.

Есть и ловушка времени. Проверьте начало действия, а также истечение, потому что сертификат, подготовленный для более поздней активации, отклоняется, если установлен слишком рано, и ошибка выглядит как проблема с часами, а не как проблема подготовки. openssl x509 -noout -dates на новом файле перед развёртыванием — проверка на две секунды. Сохраняйте также поддерживаемый путь восстановления и известную хорошую конфигурацию, чтобы неудачное обновление можно было откатить, восстановив прежний сертификат и ключ.

Разверните, проверьте новой аутентификацией, затем выведите из эксплуатации

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

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

Выводите устаревший материал из эксплуатации только после проверки развёртывания, а скомпрометированный ключ рассматривайте как совершенно отдельный случай: обновление само по себе ничего не отзывает, поэтому затронутой идентичности нужен процесс отзыва и обработки сеансов развёртывания. RFC 5280 определяет правила сертификатов и проверки пути, лежащие в основе всего этого. Держите рутинное обновление листа отдельно от замены CA, чтобы клиентов не просили доверять новому издателю без причины.