Как заставить браузер доверять самоподписанному сертификату

Как создавать надежные SSL-сертификаты для локальной разработки

Случалось ли так, что вы понимали — необходимо добавить HTTPS в приложение, запущенное на локальном хостинге или каком-нибудь еще местном домене вроде local.my-app.com ?

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

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

Ответ прост: создать собственный сертификат, либо подписывающий сам себя, либо заверенный локальным корневым сервером, и внести его в хранилище доверенных сертификатов операционной системы. Далее этим сертификатом можно пользоваться на локальном веб-сервере.

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

Важно отметить вот что: с 1 сентября 2020 года SSL-сертификаты не выдаются дольше, чем на тринадцать месяцев (397 дней). Поэтому для сертификатов, создаваемых в этой статье, мы ограничимся двенадцатью месяцами.

Создание сертификата

Источник сертификата (Certificate Authority)

1. Создайте закрытый ключ и самоподписанный сертификат

openssl req -x509 -nodes -new -sha512 \ 
-days 365 -newkey rsa:4096 -keyout ca.key \ 
-out ca.pem -subj "/C=US/CN=MY-CA"

Опционально: если необходимо, можно заменить MY-CA в CN на что-нибудь другое.

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

openssl x509 -in ca.pem -text -noout

2. Создайте файл сертификата с расширением .crt :

openssl x509 -outform pem -in ca.pem -out ca.crt

Сертификат доменного имени

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

1. Создайте файл расширения x509 v3:

cat > v3.ext authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names 
[alt_names]
# Локальные хостинги
DNS.1 = localhost
DNS.2 = 127.0.0.1
DNS.3 = ::1 
# Перечислите доменные имена
DNS.4 = local.dev
DNS.5 = my-app.dev
DNS.6 = local.some-app.dev
EOF

Следуя этому шаблону, можно добавить сколько угодно доменных имен.

Примечание: пожалуйста, обновите DNS.4, DNS.5 и DNS.6 или удалите их, если у вас не настроены никакие локальные доменные имена.

2. Создайте закрытый ключ и запрос на подпись сертификата:

openssl req -new -nodes -newkey rsa:4096 \ 
-keyout localhost.key -out localhost.csr \ 
-subj "/C=US/ST=State/L=City/O=Some-Organization-Name/CN=localhost"

Опционально: страну, штат, город и организацию можно изменять.

3. Создайте самоподписанный сертификат:

openssl x509 -req -sha512 -days 365 \
-extfile v3.ext \
-CA ca.crt -CAkey ca.key -CAcreateserial \
-in localhost.csr \
-out localhost.crt

Использование сертификата

Приложениям, обслуживающим ваш контент, понадобится доступ к файлам сертификата и закрытого ключа. Это может быть локальный веб-сервер (Apache или NGINX), локальный сервис или какой-то другой локальный инструмент, допустим, сборщик модулей DevServer.

Вот несколько примеров:

Apache

  
. 
ServerName local.dev 
SSLEngine on 
SSLCertificateFile /path/to/localhost.crt 
SSLCertificateKeyFile /path/to/localhost.key 
. 

NGINX

server listen 443; 
ssl on; 
ssl_certificate /path/to/localhost.crt; 
ssl_certificate_key /path/to/localhost.key; 
. 
>

webpack DevServer

webpack-dev-server --open --https \ 
--cert /path/to/localhost.crt \ 
--key /path/to/localhost.key

Express.js

const https = require("https");
const fs = require("fs");
const express = require("express");

// прочитайте ключи
const key = fs.readFileSync("localhost.key");
const cert = fs.readFileSync("localhost.crt");

// создайте экспресс-приложение
const app = express();

// создайте HTTPS-сервер
const server = https.createServer(< key, cert >, app);

// добавьте тестовый роут
app.get("/", (req, res) => res.send("this is an secure server");
>);

// запустите сервер на порту 8000
server.listen(8000, () => console.log("listening on 8000");
>);

Как только вы настроите обслуживающий ваше приложение инструмент на работу с вашим сертификатом, ваше приложение будет доступно по URL’у с HTTPS.

Следуя приведенному выше примеру с Express, вы можете открыть вкладку браузера по адресу https://localhost:8000 и увидеть ваш контент:

Погодите секунду! Где же сообщение «это защищенный сервер»?

Вы рассчитывали увидеть кое-что другое, но именно этого и следовало ожидать — потому что источник сертификата еще не входит в число доверенных.

Доверие к сертификатам

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

macOS — Chrome и Safari

1. Дважды кликните на корневом сертификате ( ca.crt ).

2. Выберите нужную связку ключей [keychain] ( login , если вы хотите, чтобы сертификат считался доверенным только в вашем аккаунте, или System , если сертификат должен считаться доверенным во всей системе).

3. Добавьте сертификат.

4. Откройте «Keychain Access» (если еще не открыт).

5. Выделите keychain, который выбрали раньше.

6. Вы должны увидеть сертификат MY-CA (это будет имя, которое вы, как CN, дали вашему источнику сертификата).

7. Дважды кликните по сертификату.

8. Разверните «Доверять» и выберите опцию «Доверять всегда» в пункте «При использовании этого сертификата».

9. Закройте окно сертификата и введите свой пользовательский пароль (если требуется).

Windows 10 — Chrome, IE11 и Edge

1. Дважды кликните на сертификате ( ca.crt ).

2. Кликните на кнопку «Установить сертификат».

3. Выберите, хотите ли вы хранить его на уровне пользователя или на уровне машины.

4. Кликните «Дальше».

5. Выберите «Разместить все сертификаты в следующем хранилище».

6. Кликните «Обзор».

7. Выберите «Доверенные корневые источники сертификатов».

9. Кликните «Дальше».

10. Кликните «Завершить».

11. Если появится подсказка, кликните «Да».

Firefox

Даже после того, как вы установите доверенный источник сертификата в хранилище, Firefox все равно будет выдавать предупреждения. Этого может не случиться в Windows 10, но почти наверняка случится в macOS. Справиться с этим достаточно просто. Firefox демонстрирует вот такой экран:

Чтобы добавить разрешения сертификату, кликните «Дополнительно…». Сразу же после этого кликните на «Принять риск и продолжить», чтобы дать понять, что вы знаете о риске.

Это нужно сделать всего один раз, но для каждого локального домена.

Заключение

Теперь, когда сертификат создан и доверие к нему обеспечено, вы без проблем можете посещать свой локальный домен! Обслуживание приложений стало безопасным, и вы можете спокойно продолжать разработку. Возвращаясь к примеру с Express, результат на экране будет таким:

Сайт полностью загружен, и рядом с URL в Chrome теперь отображается символ безопасного соединения.

Надеюсь, эта статья помогла вам превозмочь трудности с HTTPS.

• Как исправить ошибки сертификатов в Node-приложениях при работе с SSL
• Как установить несколько версий Python в WSL2 и управлять ими
• Работа с HTML и CSS: 10 полезных приемов для дизайнеров

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

Мы уже рассказывали как сгенерировать SSL-сертификат от Let’s Encrypt в операционных системах Windows и Linux. Это полноценные сертификаты, предназначенные для использования в рабочем окружении. Но для тестирования может потребоваться создание большого их количества, а процесс верификации нескольких сертификатов Let’s Encrypt может быть неудобным. Для массовой генерации больше подходят самоподписанные сертификаты.

В TrueConf Server можно генерировать самоподписанные сертификаты прямо в панели управления сервером. Но если по каким-то причинам этот способ вам не подходит или нужно создать самоподписанный сертификат для других продуктов TrueConf (например, TrueConf Group), то это можно сделать с помощью криптографической библиотеки OpenSSL.

Установка OpenSSL и создание сертификата на Windows

1. Перейдите на страницу загрузки OpenSSL, скачайте необходимый инсталлятор версии Light в зависимости от разрядности ОС и запустите его.
2. После установки программы, необходимо добавить путь к ней как системную переменную. Для этого перейдите в Панель управления → Система → Дополнительные параметры системы → Переменные среды.

   В разделе Системные переменные выберите переменную Path и нажмите Изменить. В открывшемся окне нажмите Создать и введите путь к папке bin установленного приложения ( C:\Program Files\OpenSSL-Win64\bin по умолчанию). Нажмите ОК.

Для применения настроек может понадобиться перезагрузка компьютера.

openssl req — x509 — sha256 — nodes — days 365 — newkey rsa : 2048 — keyout privateKey . key — out certificate . crt

где:
-x509 — уточнение, что нам нужен именно самоподписанный сертификат;
-newkey — автоматическое создание ключа сертификата;
-days — срок действия сертификата в днях;
-keyout — путь (если указан) и имя файла ключа;
-out — путь (если указан) и имя файла сертификата.

Последовательно введите: код страны, её название, город, название компании, название отдела, FQDN сервера или ваше имя и адрес электронной почты.

В папке C:\cеrt сгенерируются 2 файла:

• certificate.crt — сам сертификат;
• privateKey.key — файл ключа.

Установка OpenSSL и создание сертификата на Linux

Для примера мы рассмотрим генерацию самоподписанного сертификата на сервере с развёрнутой ОС Debian 10.

Для выполнения перечисленных далее команд в ОС должна присутствовать программа sudo и пользователь, под которым они запускаются, должен быть в соответствующей группе. В Debian по умолчанию sudo может отсутствовать, проверьте её наличие командой sudo -V и установите при необходимости с помощью команды apt install sudo (выполняется под учётной записью root). А для добавления пользователя с логином user в группу sudo выполните sudo usermod -a -G sudo user .

Некоторые Linux дистрибутивы поставляются с уже установленным пакетом openssl. Чтобы проверить, установлен ли этот пакет у вас, в терминале выполните в терминале команду openssl version . Если в ответ появится текст вида OpenSSL 1.1.0l 10 Sep 2019 , то перейдите к шагу 3.

Обновите установленные в системе пакеты с помощью консольной команды:

Как выпустить самоподписанный SSL сертификат и заставить ваш браузер доверять ему

Все крупные сайты давно перешли на протокол https. Тенденция продолжается, и многие наши клиенты хотят, чтобы их сайт работал по защищенному протоколу. А если разрабатывается backend для мобильного приложения, то https обязателен. Например, Apple требует, чтобы обмен данными сервера с приложением велся по безопасному протоколу. Это требование введено с конца 2016 года.

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

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

openssl genrsa -out rootCA.key 2048

Затем сам сертификат:

openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.pem

Нужно будет ввести страну, город, компанию и т.д. В результате получаем два файла: rootCA.key и rootCA.pem

Переходим к главному, выпуск самоподписанного сертификата. Так же как и в случае с корневым, это две команды. Но параметров у команд будет значительно больше. И нам понадобится вспомогательный конфигурационный файл. Поэтому оформим все это в виде bash скрипта create_certificate_for_domain.sh

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

if [ -z "$1" ] then echo "Please supply a subdomain to create a certificate for"; echo "e.g. mysite.localhost" exit; fi

Создадим новый приватный ключ, если он не существует или будем использовать существующий:

if [ -f device.key ]; then KEY_OPT="-key" else KEY_OPT="-keyout" fi

Запросим у пользователя название домена. Добавим возможность задания “общего имени” (оно используется при формировании сертификата):

DOMAIN=$1 COMMON_NAME=$

Чтобы не отвечать на вопросы в интерактивном режиме, сформируем строку с ответами. И зададим время действия сертификата:

SUBJECT="/C=CA/ST=None/L=NB/O=None/CN=$COMMON_NAME" NUM_OF_DAYS=999

В переменной SUBJECT перечислены все те же вопросы, который задавались при создании корневого сертификата (страна, город, компания и т.д). Все значение, кроме CN можно поменять на свое усмотрение.

Сформируем csr файл (Certificate Signing Request) на основе ключа. Подробнее о файле запроса сертификата можно почитать в этой статье.

openssl req -new -newkey rsa:2048 -sha256 -nodes $KEY_OPT device.key -subj "$SUBJECT" -out device.csr

Формируем файл сертификата. Для этого нам понадобится вспомогательный файл с настройками. В этот файл мы запишем домены, для которых будет валиден сертификат и некоторые другие настройки. Назовем его v3.ext. Обращаю ваше внимание, что это отдельный файл, а не часть bash скрипта.

authorityKeyIdentifier=keyid,issuer basicConstraints=CA:FALSE keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment subjectAltName = @alt_names [alt_names] DNS.1 = %%DOMAIN%% DNS.2 = *.%%DOMAIN%%

Да, верно, наш сертификат будет валидным для основного домена, а также для всех поддоменов. Сохраняем указанные выше строки в файл v3.ext

Возвращаемся в наш bash скрипт. На основе вспомогательного файла v3.ext создаем временный файл с указанием нашего домена:

cat v3.ext | sed s/%%DOMAIN%%/$COMMON_NAME/g > /tmp/__v3.ext

openssl x509 -req -in device.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out device.crt -days $NUM_OF_DAYS -sha256 -extfile /tmp/__v3.ext

Переименовываем сертификат и удаляем временный файл:

mv device.csr $DOMAIN.csr cp device.crt $DOMAIN.crt # remove temp file rm -f device.crt;

Скрипт готов. Запускаем его:

./create_certificate_for_domain.sh mysite.localhost

Получаем два файла: mysite.localhost.crt и device.key

Теперь нужно указать web серверу пути к этим файлам. На примере nginx это будет выглядеть так:

Запускаем браузер, открываем https://mysite.localhost и видим:

Браузер не доверяет этому сертификату. Как быть?

Нужно отметить выпущенный нами сертификат как Trusted. На Linux (Ubuntu и, наверное, остальных Debian-based дистрибутивах) это можно сделать через сам браузер. В Mac OS X это можно сделать через приложение Keychain Access. Запускаем приложение и перетаскиваем в окно файл mysite.localhost.crt. Затем открываем добавленный файл и выбираем Always Trust:

Обновляем страницу в браузере и:

Успех! Браузер доверяет нашему сертификату.

Сертификатом можно поделиться с другими разработчиками, чтобы они добавили его к себе. А если вы используете Docker, то сертификат можно сохранить там. Именно так это реализовано на всех наших проектах.

Делитесь в комментариях, используете ли вы https для локальной разработки?

Максим Ковтун,
Руководитель отдела разработки

Переводим сайт на HTTPS

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

Автор: Peppers Digital

Обмен данными между сайтом и браузером клиента осуществляется по протоколу HTTP (HyperText Transfer Protocol). Его методы обеспечивают корректную работу с любыми гипертекстовыми документами, но уровень безопасности передаваемых данных недостаточно высок.

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

Что все это значит?

Аббревиатура HTTPS расшифровывается как HyperText Transfer Protocol Secure — защищённый протокол для передачи гипертекста.

Стоит отметить, что HTTPS — это не самостоятельный протокол, структура запросов и ответов отличий от HTTP не имеет.

Основная разница — добавление при передаче данных шифрования, которое обеспечивается при помощи механизмов SSL и TLS.

SSL (Secure Sockets Layer) — протокол, повышающий безопасность передачи данных посредством криптографии (шифрования). Он подходит не только для гипертекстовых документов, но и для загрузки файлов, IP-телефонии, электронной почты. Разработка протокола началась в 90-х годах XX века, в 1995 году появилась версия 2.0, а в 1996 — 3.0, которая и стала основой TLS 1.0.

TLS (Transport Layer Security) — современный криптографический протокол, который исключает несанкционированный доступ к данным во время их передачи. Достигается это за счет аутентификации, симметричного и ассиметричного шифрования, средств проверки аутентичности сообщений.

В чем «секрет» HTTPS?

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

Основа сертификата — два криптографических ключа: публичный и приватный. Ключ public шифрует входящие (идущие от клиента к серверу) данные, а private – исходящие. Это секретный ключ, доступ к нему есть только у администратора сайта.

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

Существуют специализированные сервисы для проверки SSL-сертификатов.

Правильность установки сертификата можно проверить здесь.

А этот сервис предоставляет доступ к полной технической информации, содержащейся в сертификате.

SSL сертификаты: основные виды

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

Самоподписанный сертификат

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

• подключение не защищено (Chrome);
  
• соединение с этим сервером небезопасно (Яндекс браузер);
  
• ваше соединение не защищено (Mozilla Firefox);
  
• ошибочный сертификат (Opera).
  

Да, все технические преимущества SSL этот вариант обеспечивает, но для посетителя сайт выглядит подозрительно. И браузер помечает такой сайт в адресной строке браузера следующим образом:

Domain Validated или DV-валидация

Domain Validated или DV-валидация — это сертификат начального уровня доверия. При его выдаче проверяется, как следует из названия, только принадлежит ли доменное имя тому, кто оформляет сертификат. Это самый доступный и распространенный вариант, поскольку:

В адресной строке такой сайт отмечается как безопасный:

Organization Validatio

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

Сертификат выдается после предоставления и проверки соответствующих свидетельств:

• ОГРН;
• ИНН/КПП;
• о праве на владение доменным именем и другие.

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

Organization Validation — сертификат высокого уровня надежности, его стоимость начинается от 2000 рублей в год.

В адресной строке сайт выглядит так: Extended Validation

Extended Validation — это самый надежный из возможных SSL сертификатов. Этот вид валидации предназначен для крупных корпораций. Цена EV-сертификата начинается от 12000 рублей в год. Дополнительное преимущество — отображение в адресной строке браузера названия компании, что повышает доверие клиентов.

Если сайт компании имеет несколько поддоменов (например, для разных регионов или направлений деятельности), может потребоваться установка сертификата Wildcard. Некоторые хостинг-провайдеры предоставляют его в качестве дополнительной услуги.

Стоимость этих сертификатов начинается от 1500 рублей в год.

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

Если вы не определились с выбором вида SSL-сертификата для своего сайта, компания Peppers Digital поможет вам. Также мы можем полностью перенести сайт на HTTPS, избавив вас от любых хлопот, связанных с этим процессом.

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

Преимущества перевода сайта на HTTPS

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

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

Так, в браузере Chrome, начиная с 56 версии (выпущенной в 2017 году), соединение по HTTP на сайтах, запрашивающих какие-либо данные пользователей, отмечается как небезопасное. А такое предупреждение может заставить потенциального клиента отказаться от покупки или регистрации.

Сайты, использующие HTTPS, с 2014 года ранжируются выше в поисковой системе Google. Это может стать весомым конкурентным преимуществом. При этом Яндекс воспринимает и индексирует все сайты в поиске на равных условиях.

Планируется, что к 2021 году все сайты перейдут на HTTPS, а веб-ресурсы, работающие на протоколе HTTP, просто не будут открываться в браузерах.

Переводим сайта на HTTPS: пошаговая инструкция

Для переноса сайта на HTTPS требуется определенное время, поэтому приступать к работе нужно в период, когда активность ваших клиентов в сети минимальна. Не стоит заниматься переносом сайта горячих путевок в разгар туристического сезона, а магазина подарков перед Новым годом. Определить активность посетителей в зависимости от времени года помогут сервисы аналитики (Яндекс.Метрика, Google Analytics), в каждом из них есть параметр «Сезонность».

Первый шаг — это выбор SSL сертификата и организации, которая выдаст его.

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

Далее нужно внести правки в файл robots.txt. Директива Host в этом файле прописывается в виде: Host: https://site.ru, где site.ru — доменное имя вашего сайта. После этих действий сайт должен быть доступен по HTTPS, проверьте это.

User-agent: Yandex … Host: https://site.ru

Теперь нужно сообщить об изменениях поисковым системам. В Яндекс.Вебмастер нужно добавить сайт с новым протоколом. Если права на сайт в этом сервисе до сих пор не подтверждены, самое время сделать это. То, что сайт теперь использует новый протокол, нужно указать и в настройках индексирования в подразделе «Переезд сайта», отметив галочкой пункт «Добавить HTTPS». Не забудьте сохранить изменения!

URL с HTTPS должен быть назначен главным зеркалом сайта.

Изменения произойдут не сразу, иногда на переназначение главного зеркала уходит несколько недель. По завершении в разделе «Уведомления» в Вебмастере появится сообщение, что главное зеркало изменилось и теперь это https://site.ru. Чтобы получить оповещение на почту, можно подписаться на уведомления. На странице «Мои сайты» в Яндекс.Вебмастере сайты будут отмечены как «связанные».

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

После склейки зеркал настраивают 301 редирект в файле .htaccess. Например, не нужно делать двойной редирект с http://www.site.ru на http://site.ru, а затем на https://site.ru. Это приводит к образованию так называемых цепочек переадресации, которые не нравятся поисковым системам.

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

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

Если карта сайта еще не добавлена в Яндекс.Вебмастер, самое время это сделать.

Как только сайты склеились, все тексты и внешние ссылки с исходного сайта будут учитываться для главного зеркала, доступного по HTTPS. Но в Вебмастере они будут размещены в панели того сайта, для которого их изначально добавили.

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

Уведомить о смене главного зеркала сайта потребуется и поисковую систему Google. Для этого в Google Search Console добавляется версия сайта с HTTPS (или все версии, если это не было сделано ранее). После этого в разделе «Настройка сайта» указывается основной домен. Не забудьте также перенести на адрес с HTTPS настройки первоначального сайта.

Использовать инструменты Google для изменения адресов в этой ситуации не нужно.

Не забудьте изменить на адрес с HTTPS внешние ссылки на сайт там, где это возможно (в социальных сетях, сервисах карт, каталогах сайтов).

В целом, переход сайта на HTTPS несложен. Если у вас возникли вопросы, обращайтесь, мы обязательно поможем. А если вы не хотите разбираться во всех тонкостях, закажите перенос сайта на HTTPS в компании Peppers Digital.