Истечение срока действия SSL-сертификата многоязычного сайта внешне выглядит лишь как обычная недоработка в обслуживании, однако на практике часто проявляется так: «в одних странах сайт не открывается, в некоторых языковых версиях возникают ошибки, а часть пользователей всё ещё может получить доступ». Такие явления легко приводят обслуживающий персонал к ошибочному выводу о колебаниях сети, сбое CDN или местных ограничениях доступа. Точнее говоря, истечение срока сертификата является триггером, а то, в каком масштабе проявится проблема, определяется CDN-узлами на периферии в разных регионах, маршрутами DNS-разрешения, стратегиями проверки браузеров и структурой развертывания сайта.
Для сайтов, выполняющих задачу привлечения зарубежных клиентов, это не просто техническое предупреждение. Невозможность установить защищённое соединение на целевой странице Google Рекламы может напрямую повлиять на проверку рекламных объявлений и посещаемость; пользователи органического поиска, увидев после перехода на сайт предупреждение о риске сертификата, обычно не продолжат отправку запроса; ссылки, уже размещённые в социальных сетях и email-маркетинговых кампаниях, также могут внезапно перестать работать в определённом целевом регионе. Поэтому управление SSL-сертификатами многоязычного сайта следует осуществлять совместно с доменами, CDN, маркетинговыми страницами и системой мониторинга.
При установлении HTTPS-соединения сервер предоставляет браузеру цифровой сертификат на основе системы X.509. Браузер проверяет срок действия сертификата, цепочку выдачи, соответствие доменному имени, доверенный статус центра сертификации и связанную информацию об отзыве. Как только указанное в сертификате время «Not After» истекает, клиент обычно считает, что идентичность сервера больше не может быть надёжно подтверждена, и отображает предупреждение о небезопасном соединении, истекшем сертификате или ошибке защищённого соединения.
Строго говоря, если конечный сертификат для одного домена и одного маршрута доступа истёк, это может затронуть все клиенты с нормальными возможностями проверки. Так называемая «недоступность в отдельных регионах» не означает, что истёкший сертификат становится недействительным только для какой-либо страны: пользователи из разных регионов могут фактически подключаться к разным сервисным узлам и получать разные конфигурации сертификатов.
Многоязычные сайты особенно подвержены такой сложности. Языковые версии могут различаться субдоменами, например de.example.com и ja.example.com; также могут использоваться пути каталогов; кроме того, компании могут развертывать интернет-магазин, основной сайт и рекламные целевые страницы на разных платформах. Если список доменов SAN в сертификате неполный либо на одном из субдоменов всё ещё привязан старый сертификат, возможна ситуация, когда англоязычная версия работает нормально, а японская блокируется, либо главная страница открывается, но страницу отправки запроса использовать невозможно.

Наиболее распространённая причина — несинхронизированные сертификаты на периферийных узлах CDN. Глобальная CDN распределяет запросы на разные узлы в зависимости от местоположения пользователя, качества сети и правил маршрутизации. После продления сертификата, если исходный сервер, балансировщик нагрузки и панель управления CDN не были обновлены согласованно либо новый сертификат ещё не развернут на всех периферийных узлах, пользователи из Северной Америки могут получить новый сертификат, тогда как пользователи из Европы или Юго-Восточной Азии всё ещё попадут на узел со старым сертификатом. В такой ситуации проверка только из корпоративной сети и вывод о том, что «сайт восстановлен», не означают, что он восстановлен во всём мире.
Вторая категория проблем связана с DNS и распределением трафика. Многоязычные сайты часто используют интеллектуальное DNS-разрешение, региональное разрешение или несколько записей CNAME, поэтому IP-адреса, возвращаемые в разных странах, могут отличаться. Команда обслуживания может обновить основной вход для главного домена, но пропустить маршрут для одного региона, старый IPv6-адрес или резервный адрес балансировщика нагрузки; в результате пользователи будут подключаться к серверу, на котором всё ещё установлен просроченный сертификат. Ситуация, при которой IPv4 работает нормально, а IPv6 — с ошибками, встречается при диагностике довольно часто.
Ещё один источник различий — сами клиентские устройства. Более новые браузеры и операционные системы обычно строже обрабатывают недействительные сертификаты; на старых устройствах, при использовании корпоративных прокси, управляемых браузеров или терминалов с различным состоянием кэша способы отображения предупреждений могут отличаться. При отсутствии промежуточных сертификатов или неправильной настройке порядка цепочки в одних средах цепочка может быть дополнена из кэша, а в других TLS-рукопожатие будет немедленно прервано. Нельзя считать, что с цепочкой сертификатов нет проблем, только потому, что небольшое число устройств «всё ещё может открыть сайт».
При устранении неполадок чаще всего впустую тратится время, когда смотрят только на статус «выдан» в панели управления сертификатами. Выдача сертификата, установка на сервере, привязка к CDN и публикация на периферийных узлах — это разные этапы. Получение нового сертификата не означает, что внешние пользователи уже используют именно его. Необходимо выполнять проверку TLS-рукопожатия из регионов, у операторов связи или с облачных хостов, где наблюдается ошибка, и подтверждать фактически возвращаемые серийный номер сертификата, срок действия, альтернативные имена субъекта и цепочку сертификатов, а не только проверять локальные файлы.
Диагностику можно проводить по цепочке доступа: сначала определить, на какие IPv4- и IPv6-адреса в итоге разрешается проблемный URL; затем отдельно проверить сертификаты, возвращаемые каждым адресом на порту 443; после этого сверить привязки сертификатов для домена CDN, домена обращения к источнику, слушателя балансировщика нагрузки и веб-службы исходного сервера; в конце проверить, передаётся ли корректное имя хоста SNI. Без передачи SNI сервер может вернуть сертификат сайта по умолчанию, что способно скрыть или создать проблему несоответствия доменного имени.
Контрольный список обслуживания должен как минимум охватывать основной домен, версии с www и без www, все языковые субдомены, домены интернет-магазина, домены статических ресурсов, домены перенаправления коротких рекламных ссылок, а также возможно ещё используемые тестовые или миграционные точки входа. Языковым версиям на основе каталогов не всегда требуются отдельные сертификаты, но если страницы ссылаются на другие HTTPS-ресурсы, домены ресурсов также должны входить в область мониторинга. В противном случае сама страница может открываться нормально, но изображения, скрипты, платёжные компоненты или интерфейсы форм могут быть заблокированы браузером.
Автоматическое продление стоит использовать, однако это не является «решением раз и навсегда». Автоматизация может покрыть лишь часть действий по запросу или обновлению сертификата; необходимо также назначить ответственных за постоянную действительность прав DNS-проверки, охват всех узлов скриптами развертывания, корректное использование нового сертификата CDN и внешнюю проверку после изменений. Рекомендуется настроить несколько напоминаний до даты истечения и сохранять отпечаток сертификата, место привязки, способ продления, ответственного сотрудника и план отката. Для сайтов с пиковыми маркетинговыми кампаниями окно истечения срока также следует исключить из периодов интенсивного размещения рекламы, продвижения на выставках и запуска новых продуктов.
Ценность комплексных услуг по созданию сайтов и маркетингу в таких вопросах заключается не в простом администрировании сертификатов, а в увязке технического состояния с каналами привлечения трафика. Компания «Иинбао Информационные Технологии (Пекин)» с 2013 года предоставляет цифровые услуги для компаний, выходящих на зарубежные рынки; её решения по интеллектуальному созданию сайтов, многоязычным сайтам, трансграничным интернет-магазинам, а также SEO, рекламе и социальным медиа обычно затрагивают доступ к доменам, размещение страниц и непрерывное обслуживание на различных рынках. В подобных платформенных проектах мониторинг сертификатов должен быть включён в проверку публикации сайта и маркетинговых кампаний, а не выполняться только после жалоб пользователей.
При получении обратной связи о том, что «сайт не открывается в отдельных регионах», сначала следует зафиксировать страну пользователя, домен доступа, устройство и браузер, скриншот ошибки и примерное время, а затем сверить эти данные с региональным DNS-разрешением и журналами узлов. Обычно это эффективнее, чем многократно обновлять страницу. После завершения исправления также следует повторно проверить по реальному маршруту доступа из целевых рынков главную страницу, языковые разделы, формы, страницу оформления заказа в интернет-магазине и рекламные целевые страницы. Восстановление сертификата — это только отправная точка; обслуживание можно считать действительно завершённым лишь после подтверждения, что зарубежные пользователи могут стабильно получать доступ и выполнять конверсионные действия.
Связанные статьи
Связанные продукты