Перенос SSL-сертификата на новый сервер: как не остаться без HTTPS при переезде

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

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

Сертификат «привязан» к серверу или его можно переносить?

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

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

Какие файлы нужно подготовить перед переносом?

Стандартный комплект для переноса включает три элемента:

• сам SSL-сертификат домена;
• приватный ключ, сгенерированный вместе с ним;
• цепочку промежуточных сертификатов удостоверяющего центра.

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

Нужно ли вообще переносить старый сертификат, или проще выпустить новый?

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

А вот если сертификат платный, расширенной или организационной проверки (OV, EV), с длительным сроком действия, перевыпуск может означать повторное прохождение проверки документов компании — а это не пять минут, а иногда несколько дней. В этом случае перенос существующего сертификата — заметно более быстрый путь.

Как избежать «окна» без HTTPS во время переезда?

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

Разумная последовательность действий такая: сначала полностью настроить и протестировать сайт и сертификат на новом сервере по его временному адресу или тестовому домену, убедиться, что HTTPS работает корректно, и только после этого переключать DNS-записи основного домена. Такой подход сводит риск простоя практически к нулю.

Что чаще всего идёт не так при переносе сертификата?

Практика показывает несколько типичных ошибок:

• забывают перенести цепочку промежуточных сертификатов — браузер показывает предупреждение о недоверенном соединении, хотя сам сертификат действителен;
• переносят сертификат без приватного ключа или с ключом от другой пары;
• переключают DNS до того, как новый сервер полностью готов принимать HTTPS-трафик;
• забывают про поддомены и дополнительные адреса, которые тоже входили в старый сертификат.

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

Как понять, что перенос прошёл успешно?

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

Как с этим справляется «Клауд АйСи»?

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

А что, если переезжаешь на совершенно другую платформу — например, с обычного хостинга в облако?

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

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