Как установить SSL сертификат: пошаговая инструкция. Подтверждение в Google webmaster
Установка SSL сертификата
Для установки сертификата потребуется:
- Файл сертификата и цепочка сертификата . Центр сертификации присылает эти данные на почтовый ящик владельца сертификата.
- Ключ сертификата. Он у вас должен быть. Ключ генерируется перед заказом сертификата, на основе ключа генерируется csr запрос.
- Root доступ к серверу.
Инструкция по установке SSL-сертификата на домен средствами панели ISPmanager
После выпуска заказанного сертификата, на email, который был указан при заказе, Вы получите все необходимые файлы.
1. Зайдите в ISPmanager под пользователем, которому принадлежит домен. Войдя под root"ом это можно сделать так: ISPmanager - Пользователи - выделите пользователя - нажмите "Вход" (справа вверху кнопка с изображением лестницы и двери).
Примечание: не забудьте для пользователя включить SSL (ISPmanager - Пользователи - двойной клик по пользователю - вкладка "Права")
2. В разделе World Wide Web - "SSL-сертификаты" - справа вверху кнопка "Создать". Укажите "Тип сертификата" - существующий и заполните все поля:
Имя сертификата - имя сертификата, под которым он будет отображаться в системе. Может содержать буквы латинского алфавита, цифры, точки, а также знаки _ и -
Приватный ключ - укажите содержимое файла приватного ключа
Сертификат - укажите содержимое файла SSL-сертификата
Пароль - указывайте, если ключ сертификата зашифрован (обычно не требуется)
Цепочка сертификатов - Certificate bundle: цепочка сертификатов, которыми подписан данный сертификат. Подробнее о цепочках, в зависимости от типа сертификата, можно узнать в специальной статье .
3. После успешного добавления сертификата в разделе "WWW домены" можно его включить для сайта (двойной клик - установить галочку "SSL" - выбрать из списка нужный сертификат)
4. Детальная проверка установленного сертификата доступна по ссылкам:
Ручная установка SSL сертификата
Веб-сервер Apache
Если ssl запросы обрабатывает Apache, то сертификат устанавливается в файле конфигурации Apache. Проверить какой веб сервис отвечает на 443 (ssl) порту можно командой:
- Linux:
- FreeBSD:
Для установки сертификата откройте конфигурационный файл Apache. На FreeBSD это /usr/local/etc/apache22/httpd.conf. Debian - /etc/apache2/apache2.conf. Centos - /etc/httpd/conf/httpd.conf. Найдите VirtualHost вашего домена.
Иногда вы можете найти блоки
Создайте блок
- /var/www/user/data/www/domain.com - путь до домашней директории вашего домена.
- /path/to/ca.crt - файл корневого сертификата.
Перезапустите Apache командой apachectl restart или apache2ctl restart
Веб-сервер Nginx
Если ssl запросы обрабатывает Nginx, то сертификат устанавливается в файле конфигурации Nginx.
Откройте конфигурационный файл Nginx. На Linux - /etc/nginx/nginx.conf
Создайте серверный модуль для SSL соединения. Пример:
Server { listen 10.0.0.1:443; server_name domain.com; ssl on; ssl_certificate /path/to/domain.crt; ssl_certificate_key /path/to/domain.key ; }
- domain.com - имя вашего домена.
- 10.0.0.1 - ip адрес, на котором находится домен.
- /path/to/domain.crt - файл, в котором находится сертификат.
- /path/to/domain.key - файл, в котором находится ключ сертификата.
Цепочка сертификатов дописывается в файл с сертификатом.
Возьмем пример с Comodo Positive SSL. Центр сертификации присылает файлы domain.crt, PositiveSSLCA2 и AddTrustExternalCARoot. Цепочкой сертификата будет содержание файла PositiveSSLCA2 + AddTrustExternalCARoot. В итоге файл domain.crt должен содержать сертификат домена + сертификаты PositiveSSLCA2 + AddTrustExternalCARoot.
Перезапустите Nginx
- Linux:
Несколько SSL сертификатов на одном ip адресе
Если используется несколько сертификатов на одном ip адресе, то браузер получит сертификат сервера по умолчанию, независимо от запрашиваемого имени сервера. Это связано с поведением протокола SSL. SSL-соединение устанавливается до того, как браузер посылает HTTP-запрос, и веб сервер не знает имени запрашиваемого сервера. Следовательно, он лишь может предложить сертификат сервера по умолчанию.
Решение для работы нескольких HTTPS-серверов на одном IP-адресе - расширение Server Name Indication протокола TLS (SNI, RFC 6066), которое позволяет браузеру передать запрашиваемое имя сервера во время SSL handshake, а значит сервер будет знать, какой сертификат ему следует использовать для соединения. Почти все современные браузеры поддерживают SNI, однако чтобы использовать SNI, соответствующая поддержка должна присутствовать также в библиотеке OpenSSL. OpenSSL поддерживает SNI начиная с версии 0.9.8f.
Полезные команды Openssl
- Создание ключа для SSL-сертификата.
- Генерация CSR-запроса:
- Убрать пароль с ключа:
- Посмотреть данные CSR:
- Данные сертификата (проверить кем выдан, например):
- Проверить, что ключ соответствует сертификату:
Два значения должны совпадать.
- Узнать длину запроса:
- Проверить выдачу HTTPS:
Создание CSR запроса для Microsoft IIS
- Нажмите на имя сервера.
- Затем справа из меню Actions выберите Create Certificate Request. Откроется окно мастера создания запроса.
- Введите всю необходимую информацию.
Нажмите Next.
- В следующем окне можно все оставить без изменений. Нажмите Next.
- Введите имя вашего CSR файла.
- Откройте файл, используя текстовый редактор. Для оформления сертификата передайте свой CSR вместе с тэгами BEGIN и END.
Установка SSL сертификата на Microsoft IIS
- Нажмите Start - Administrative Tools - Internet Information Services (IIS) Manager.
- Нажмите на имя сервера.
- В разделе IIS откройте Server Certificates.
- Затем справа из меню Actions выберите Complete Certificate Request. Откроется окно мастера.
- Загрузите выданный Вам центром сертификации сертификат. Затем введите имя сертификата (оно необходимо только администратору для дальнейшей работы).
- Нажмите Оk, и сертификат будет установлен на сервер.
- Для того, чтобы установить данный сертификат на нужный веб-домен, перейдите в раздел Sites и выберите сайт, для которого заказан сертификат. Из меню Actions в правой части страницы нажмите на Bindings. Откроется окно Site Bindings.
- В окне Site Bindings нажмите Add... Откроется окно Add Site Binding.
- В меню Type выберите https. В меню IP address должен быть IP адрес сайта или All Unassigned. Порт - 443. В поле SSL Certificate выберите Ваш сертификат.
Нажмите Ok.
- Ваш сертификат установлен.
Для чего необходим SSL-сертификат
HTTP-протокол, по которому в настоящий момент передается большинство html-страниц в сети Интернет, не может защитить данные, передаваемые между сервером и браузером посетителя. К таким данным можно отнести любую передаваемую информацию: пароли, номера телефонов, e-mail и т.д.
Обеспечить защиту передаваемых данных помогает установка SSL-сертификата . В этом случае соединение, устанавливаемое между браузером и сайтом, происходит по протоколу HTTPS. Данные, которые передаются по протоколу HTTPS, кодируются криптографическим протоколом, тем самым обеспечивается их защита.
Установка SSL-сертификат на ваш сайт позволяет:
Для интернет-магазина наличие SSL-сертификата позволит использовать такие сервисы как: Google Merchant и некоторые платежные шлюзы, например Яндекс.Касса
Более подробная информация о необходимости использования SSL-сертификата есть в .
2 способа подключения SSL-сертификата для домена интернет-магазина на InSales
Заказать SSL-сертификат через бэк-офис сайта
Для заказа SSL-сертификата через бэк-офис интернет-магазина на InSales перейдите в раздел Настройки -> Домены -> Нажмите на имя домена , к котрому нужно подключить SSL-сертификат.
В настройках домена нужно выбрать на каких страницах сайта использовать HTTPS:
1. Только при оформлении заказа - это самый безопасный вариант в случае, если сайт уже проиндексирован поисковыми системами. При использовании HTTPS только для страницы оформления заказа шифруются страницы корзины и оформления заказа. На индексацию сайта это никак не повлияет.
2. Для всего сайта - в этом случае будет выполняться шифрование всех страниц сайта. Актуально использовать для новых сайтов, которые еще не проиндексированы поисковыми системами. В случае если сайт уже проиндексирован в инструменах поисковых систем для веб-мастеров нужно будет внести соответствующие настройки, чтобы страницы сайта не выпадали из индекса.
В случае использования шифрования для всех страниц уже проиндексированного сайта предварительно проконсультируйтесь со своим SEO-специалистом и изучите рекомендации Яндекса и Google по миграции сайта с HTTP на HTTPS. Если для вас трафик из Яндекса имеет большее значение, то при настройке включите опцию "". В этом случае переключение сайта на https будет происходить в соотвествии с рекомендациями Яндекса в два этапа.
После нажатия на кнопку "Сохранить" будет выполнено перенаправление на страницу "Ваши домены" , где у домена, к которому подключается SSL-сертификат будет статус "Ожидает оплаты" , а в разделе "Аккаунт" будет выставлен счет на получение SSL-сертификата.
Для оплаты получения SSL-сертификата перейдите в раздел "Аккаунт" -> "Счета" и оплатите счет любым удобным способом.
После оплаты счета SSL-сертификат будет автоматически подключен для вашего домена в течение 4-х часов.
Если при настройке SSL вы выбрали опцию "Включать безопасно для трафика в Яндексе ", то сайт будет работать в переходном режиме. Он будет доступен и по HTTP и по HTTPS, редиректов с HTTP на HTTPS не будет. Выполнив настройки в Яндекс.Вебмастере в соответствии с рекомендациями Яндекса , нужно дождаться когда Вебмастер сообщит о смене главного зеркала на HTTPS. После этого нужно вернуться на страницу Настройки -> Домены и нажать "Проиндекирован. Завершить подключение" .
После этого переход сайта на HTTPS завершится.
Загрузить свой SSL-сертификат
К домену, привязанному к сайту на InSales, также можно подключить сторонний SSL-сертификат.
Мы поддерживаем все типы SSL-сертификатов от любых поставщиков.
Для подключения стороннего SSL-сертификата необходимо запросить у поставщика Приватный ключ и всю Цепочку сертификатов .
Предоставленные поставщиком сертификата данные необходимо выслать нам в с просьбой подключить сертификат для вашего домена. В запросе укажите домен и способ подключения SSL-сертификата: для всего сайта или только для страницы оформления заказа и корзины .
После покупки сертификата Вы можете скачать его в разделе "Общие услуги " . Если же Вы устанавливаете сертификат на Ваш сервер, воспользуйтесь представленными здесь примерами установки.
становка на хостинг .masterhost
Если требуется установить сертификат на домен, который размещен на нашем виртуальном хостинге, то сделать это возможно в двумя способами:
- SNI (бесплатно) :
Древо услуг - Домен - Поддержка SSL - Добавить. - Выделенный IP (140 рублей в месяц. Обычно требуется для работы с некоторыми платежными системами) :
Древо услуг - Домен - Выделенный IP\SSL - Добавить. В выпадающем меню выбираете сертификат.
* Для обновления сертификата, например, после его продления, выполняете аналогичные действия: Древо услуг - Домен - Поддержка SSL или Выделенный IP\SSL (в зависимости от способа установки) - Изменить.
енерация (объединение) сертификата для Windows ПО
Для установки полученного сертификата на любое ПО в Windows требуется, чтобы файл сертификата содержал как сам сертификат, так и закрытый ключ. Т.е. Вам нужно будет объединить полученный у нас сертификат с Вашим файлом закрытого ключа.
Сделать это можно так:
openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt
certificate.pfx - имя сертификата, который Вы получите в результате объединения;
privateKey.key - закрытый ключ;
certificate.crt - сам сертификат, который мы Вам выдали.
pache
- Скопируйте файлы SSL сертификата на Ваш сервер.
- Затем нужно найти файл конфигурации Apache для редактирования.
Чаще всего подобные файлы конфигурации хранятся в /etc/httpd. в большинстве случаев основной файл конфигурации называется httpd.conf. Но в некоторых случаях блоки
могут находиться в нижней части файла httpd.conf. Иногда Вы можете найти такие блоки как отдельно под директорией, к примеру, /etc/httpd/vhosts.d/ или /etc/httpd/sites/, или в файле, который называется ssl.conf. Прежде чем открывать файл в текстовом редакторе, Вы должны убедиться в наличии блоков
в которых содержат настройки Apache. - Далее установите блоки SSL
для задания конфигурации. Если Вам нужно, чтобы Ваш сайт работал и с защищенным, и с незащищенным соединением, Вам необходим виртуальный хост для каждого соединения. Для этого Вам следует сделть копию существующего незащищенного виртуального хоста и создать его для SSL-соединения как описано далее в п. 4.
- Затем создайте блоки
для подключения SSL-соединения. Ниже для Вас приведен очень простой пример виртуального хоста для SSL-соединения. В SSL конфигурацию должны быть добавлены части, которые выделенные полужирным:
DocumentRoot /var/www/html2 ServerName www.yourdomain.com SSLEngine on SSLCertificateFile /path/to/your_domain_name.crt SSLCertificateKeyFile /path/to/your_private.key SSLCertificateChainFile /path/to/root.crt Исправте имена файлов для согласования с файлами сертификатов:- SSLCertificateFile - файл Вашего сертификата (например: your_domain_name.crt).
- SSLCertificateKeyFile - файл ключа, созданного при генерации CSR.
- SSLCertificateChainFile - файл корневого сертификата.
- Теперь проверьте конфигурацию Apache до перезапуска. Всегда лучше проверить файлы конфигурации Apache на ошибки до перезапуска. Так как Apache не запустится заново, если в файлах конфигурации будут фигурировать синтаксические ошибки. Для этого используйте следующую команду: apachectl configtest
- А теперь можно перезапустить Apache.
ginx
- Скопируйте файлы сертификата на сервер.
Скопируйте Ваш сертификат (your_domain_name.crt) и корневой сертификат (root.crt) вместе с.key-файлом который Вы генерировали при создании CSR-запроса в директорию на Вашем сервере, куда Вы собираетесь установить сертификат. Для обеспечения безопасности, сохраняйте файлы с пометкой "только чтение".
- Соедените сертификат с корневым сертификатом.
Вам необходимо соединить файл сертификата с файлом корневого сертификата в единый.pem файл, выполнив следующую команду:
cat root.crt >> your_domain_name.crt - Измените файл виртуального хоста Nginx.
Откройте Ваш файл виртуального хоста Nginx для сайта, который Вы защищаете. Если Вам необходимо, чтобы сайт работал и с защищенным соединением (https), и с незащищенным (http), Вам нужен серверный модуль для каждого типа соединения. Сделайте копию существующего серверного модуля для незащищенного соединения и вставьте ниже оригинала. После этого добавьте строчки, которые приведены ниже жирным шрифтом:
server { listen 443; ssl on; ssl_certificate /etc/ssl/your_domain_name.crt; (or .pem) ssl_certificate_key /etc/ssl/your_domain_name.key; server_name your.domain.com; access_log /var/log/nginx/nginx.vhost.access.log; error_log /var/log/nginx/nginx.vhost.error.log; location / { root /home/www/public_html/your.domain.com/public/; index index.html; } } Настройка имен файлов:- ssl_certificate - файл, содержащий основной и корневой сертификаты (шаг 2).
- ssl_certificate_key - файл с ключем, который был сгенерирован при создании CSR.
- Перезагрузите Nginx.
Введите следующую команду для перезагрузки Nginx:
sudo /etc/init.d/nginx restart
xchange 2010
- Скопировать Ваш сертификат на Exchange сервер.
- Затем запустить консоль управления Exchange данным образом: Start > Programs > Microsoft Exchange 2010 > Exchange Management Console.
- Теперь нажмите "Manage Databases" и далее "Server configuration".
- Далее выберите Ваш SSL сертификат из меню в центре окна, затем нажмите на "Complete Pending Request" в меню "Actions".
- Откройте файл Вашего сертификата, после нажмите Open > Complete
Exchange 2010 довольно часто выдает сообщение об ошибке, которая начинается фразой "The source data is corrupted or not properly Base64 encoded." Игнорируйте данную ошибку.
- Далее вернитесь к консоли управления Exchange и нажмите "Assign Services to Certificate", чтобы начать использовать сертификат.
- Из списка выберите Ваш сервер, нажмите "Next".
- Теперь выберите сервисы, которые должны быть защищены сертификатом и нажмите Next > Assign > Finish. Теперь Ваш сертификат установлен и готов к использованию на Exchange.
SSL-сертификаты Web-сайтов и их применение
Часть 2. Установка SSL-сертификатов для клиента и сервера и ограничение доступа к Web-сайту на стороне сервера
Серия контента:
Наиболее распространённой областью применения SSL-сертификатов является защита HTTP-трафика, для чего сертификат устанавливается на Web-сервер и используется для шифрования трафика между сервером и клиентом. Корпоративная почта и системы групповой работы, системы хранения документов и всевозможные Web-приложения - все они нуждаются в защите HTTP-трафика.
Поэтому защита внутренних ресурсов обычно начинается с внедрения корпоративных SSL-сертификатов. В данной статье описывается процесс установки сертификата для сайта, активации сертификата в Web-браузере клиента и ограничения круга пользователей, которым разрешается посещать Web-сайт.
Установка серверного сертификата
Часто используемые сокращения.
- SSL - уровень защищенных сокетов (secure socket layer);
- CA - удостоверяющий центр (center of authority);
- CSR - запрос на сертификацию (certificate signing request);
- CRL - список отозванных сертификатов (certificate revocation list);
- PKCS - криптографические стандарты с открытым ключом (public-key cryptography standards);
- CN - общие данные (common name).
Для того, чтобы к Web-сайту можно было обращаться по протоколу HTTPS, на нем должен быть установлен собственный сертификат. "Собственный" означает, что имя сайта, используемое клиентами для обращения к сайту, совпадает с именем, указанным в поле CN сертификата. Однако, так как по требованиям протокола SSL комбинация "адрес:порт" должна быть уникальной, то установить несколько различных виртуальных серверов (с различными сертификатами) на один порт 443 не получится, и для каждого сервера потребуется выделить отдельный порт и указать его при описании данного сервера.
Процесс создания SSL-сертификата для сервера описывался в предыдущей части статьи. Поэтому предполагается, что серверный сертификат уже создан и подписан в корпоративном СА, а также имеются файлы myfile.key и myfile.crt, соответствующие ключу и сертификату сайта. Но до того, как клиенты Web-сайта смогут начать ими пользоваться, эти файлы потребуется подключить к Web-серверу (в рамках данной статьи используется Wеб-сервер Apache) через конфигурационный файл виртуального сервера (или корневого сайта) как показано в листинге 1:
Листинг 1. Подключение SSL-сертификатов
SSLEngine on SSLProtocol all -SSLv2 SSLCipherSuite HIGH:MEDIUM:EXP:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM:+EXP SSLCertificateFile "/etc/ssl/certs/myfile.crt" SSLCertificateKeyFile "/etc/ssl/certs/myfile.key"В листинге 1 приведены только параметры (директивы конфигурации Apache), относящиеся к SSL-сертификатам, поэтому для полноценной конфигурации потребуется указать и другие параметры. Указанные директивы записываются в блоке
В данном примере выполняется включение SSL (1-ая строка), на 2-ой строке происходит отключение слабой и небезопасной версии 2.0 протокола SSL. Затем на 3-ей строке устанавливаются параметры защищенного соединения, которые могут использоваться (какой набор параметров будет выбран, зависит еще и от подключающегося клиента). На строках 4 и 5 указываются SSLCertificateFile и SSLCertificateKeyFile – пути к файлу c SSL-сертификатом и к файлу с ключом сертификата.
Для нормальной работы SSL необходимо, чтобы имя сервера, прописанное в директиве ServerName , совпадало с именем, указанным для поля CN в процессе создания сертификата. Если это правило не выполняется, то при обращении к сайту Web-браузер будет постоянно отображать страницу с предупреждением.
Важное примечание : проверяется именно директива ServerName , а не директива ServerAlias . Если для сервера необходимо указать несколько имен, то их можно прописать в директиве ServerAlias .
Установка сертификата в Web-браузер пользователя
Тем не менее при первой попытке войти на сайт, где установлен SSL-сертификат, подписанный корпоративным СА, все равно возникнет ошибка, так как Web-браузер будет утверждать, что возникла критическая ситуация и это поддельный сертификат. В Web-браузере Google Chrome будет отображена страница красного цвета во весь экран, а в Mozilla Firefox – желтого, при этом обе страницы будут предупреждать пользователя, что произошел критический сбой в системе безопасности, как показано на рисунках 1 и 2.
Web-браузеры выводят сообщения, изображенные на рисунках, так как не могут проверить, какая организация подписала данный сертификат. Как уже упоминалось в прошлой части, система CA – иерархическая, и сертификаты корневых СА распространяются вместе с Web-браузерами. В Google Chrome используется хранилище сертификатов Windows, и его список корневых сертификатов может измениться после установки пакета с обновлениями от Microsoft, а в Mozilla Firefox используется собственное хранилище сертификатов.
Поскольку данный сертификат подписан внутри самой организации, то её корневой сертификат у Web-браузера, конечно, отсутствует, и он считает, что произошла ошибка. Чтобы исправить эту ошибку, достаточно просто распространить на все компьютеры в локальной сети сертификат корпоративного СА (файл caserv.crt) ещё до того момента, как пользователи начнут обращаться к корпоративным Web-ресурсам по протоколу HTTPS. Этот сертификат потребуется установить в системное хранилище Windows и в хранилище Firefox (а если используется еще и Web-браузер Opera, то и в его собственное хранилище).
Процесс установки сертификата не представляет особой сложности, однако система несколько раз уточнит: действительно ли можно доверять этому издателю сертификатов. Также необходимо обратить внимание, куда именно будет установлен сертификат: он должен быть установлен в "Доверенные Корневые Центры Сертификации", а не в какую-либо другую группу.
Преобразование SSL-сертификата из одного формата в другой
Установка корневого сертификата на мобильное устройство (например, смартфон Nokia N95 8G) требует значительно больше усилий, так как смартфон не понимает текстовых сертификатов (формат PEM). Поэтому в данном разделе рассматривается процесс перекодирования сертификата из одного формата в другой.
Существуют два стандартных формата для хранения сертификатов - PEM (текстовый) и DER (двоичный). С точки зрения содержания они не отличаются друг от друга, но текстовый формат разработан так, чтобы его можно было просматривать в текстовых редакторах и без проблем пересылать по почте. Отличие между форматами состоит в степени их поддержки различными устройствами, так как формат PEM поддерживается далеко не всеми устройствами. Поэтому для установки корневого сертификата СА на устройство, которое не поддерживает формат PEM, его потребуется предварительно перекодировать.
Перекодирование сертификата из формата PEM в формат DER выполняется следующей командой:
# openssl x509 -in caserv.crt -out caserv.cer -inform PEM -outform DERРасширение файла (.cer ) – это стандартное расширение для сертификатов формата DER. Этот формат поддерживается большим числом оборудований, в частности, упомянутым выше смартфоном Nokia N95 8G. Обратное преобразование из формата DER в формат PEM выполняется сходным образом:
# openssl x509 -in caserv.cer -out caserv.crt -inform DER -outform PEMДля обратного преобразования в команде достаточно просто поменять порядок аргументов, но полученный таким образом PEM-файл не будет содержать текстовой части (содержимое сертификата, пригодное для просмотра человеком), поэтому для создания сертификата с заполненной текстовой частью используется другая команда:
# openssl x509 -in caserv.crt -out caserv.pem -textЕсли же, наоборот, необходимо удалить из сертификата текстовую часть, то используется следующая команда:
# openssl x509 -in caserv.pem -out caserv.crtСертификат корпоративного СА, перекодированный в формат DER, переносится на смартфон и устанавливается способом, специфичным для конкретного мобильного устройства.
Установка SSL-соединения с Web-сайтом
После того, как сертификат корпоративного СА установлен в качестве корневого, Web-браузеры распознают сертификаты, подписанные им, и больше не выводят страниц с предупреждениями, а сразу устанавливают соединение с запрошенным ресурсом, как показано ниже.
При выполнении подключения к Web-сайту с установленным SSL-сертификатом дополнительно могут проверяться следующие параметры: дата начала и окончания срока действия сертификата. Если дата начала срока действия еще не наступила или наоборот, дата окончания срока действия уже прошла, то сертификат, независимо от наличия установленного корневого сертификата CA, будет объявлен ошибочным.
Также может быть проверено, не отозван ли данный сертификат. Как было упомянуто в предыдущей статье, система должна иметь возможность блокировки сертификатов, которые были выданы людям, на данный момент покинувшим организацию. Поэтому в сертификат можно добавить параметры, которые будут распознаваться Web-браузерами. На основании полученной информации Web-браузер сможет загрузить с указанного адреса CRL и проверить, не входит ли сертификат, используемый для подключения, в список отозванных. Если этот сертификат присутствует в списке отозванных, то соединение будет заблокировано.
Важное примечание : ссылка на CRL должна указываться и в параметре CRLDistributionPoint (как определено в новой версии стандарта), так и в параметре nsCaRevocationList - именно этот параметр считывается многими Web-браузерами, и при его отсутствии возникают сообщения об отсутствующем списке CRL и т.д.
Ограничение возможности подключения для нежелательных клиентов
Посторонние пользователи не должны иметь доступ к корпоративной Intranet-сети - это совершенно очевидно. Поэтому, чтобы иметь возможность управлять клиентскими подключениями с помощью серверного SSL-сертификата, в конфигурационный файл виртуального сервера необходимо добавить строки, приведенные в листинге 2.
Листинг 2. Добавление ограничений на подключение клиентов
SSLCertificateChainFile "/etc/ssl/rootca/caserv.crt" SSLCACertificateFile "/etc/ssl/rootca/caserv.crt" SSLCARevocationFile "/etc/ssl/rootca/cacrl.crl" SSLVerifyClient requireПараметры SSLCertificateChainFile и SSLCACertificateFile задают сертификат корпоративного СА, параметр SSLCARevocationFile определяет путь к CRL, а параметр SSLVerifyClient активирует проверку клиентского сертификата. В этом примере вводится самое простое ограничение: к сайту смогут подключиться только те пользователи, у которых на компьютерах установлен клиентский сертификат, подписанный корпоративным СА. При этом никаких дополнительных проверок выполняться не будет, если на клиентском компьютере, осуществляющем подключение к серверу, отсутствует клиентский сертификат, то в установке подключения будет отказано, как показано ниже.
Если простого условия о наличии SSL-сертификата, подписанного корпоративным СА недостаточно, то на основе параметра SSLRequire можно реализовать более сложные проверки, которые будут учитывать различные параметры сертификата.
Существует еще одна проблема, связанная с задачей организовать доступ к Web-ресурсу с контролем доступа по сертификатам, когда этот Web-сайт не обладает подобной функциональностью. Простым перенаправлением HTTP-запросов на страницу авторизации эту проблему не решить, так как клиент сможет заходить на Web-ресурс напрямую по его внутренним ссылкам, минуя страницу авторизации.
В данном случае может пригодиться такой прием, как «обратное проксирование», при котором, как и в случае обычного проксирования, есть некоторая программа, работающая на сервере и получающая запросы с одной стороны, а затем транслирующая их на другую. При этом достаточно установить защищенное соединение только с самим прокси-сервером, соединение между прокси-сервером и защищенным Web-сайтом может выполняться и без шифрования.
Заключение
C точки зрения организации безопасной ИТ-среды Web-ресурсы любой компании в первую очередь нуждаются в защите HTTP-трафика, причем, как правило, необходимо не только сгенерировать ключи для всех используемых серверов, но и организовать их разделение по портам, так как из-за требований протокола HTTPS на одном физическом сервере на одном и том же порту нельзя разместить несколько виртуальных Web-серверов с поддержкой HTTPS.
Дополнительно следует продумать вопрос, необходимо ли ограничить круг пользователей, которые будут иметь доступ к указанным Web-ресурсам. Если такая необходимость возникнет, то для всех пользователей потребуется сгенерировать клиентские SSL-сертификаты, обеспечить регулярное обновление CRL для отзыва аннулированных сертификатов и активировать поддержку CRL на Web-сайте, доступ к которому должен быть ограничен.
После того как Google сообщил о важности наличия защищённого SSL сертификата и о том, что сайты без него будут помечаться в панели браузера как небезопасные, началась повсеместный переход на протокол https.
Описывать о том, что такое защищённый протокол не буду, эта информация уже много где обсуждалась и описывалась. Если кто не знает, то почитайте на вики .
Ну а в этой статье давайте разберемся, как последовательно и правильно перенести веб-проект на https и при этом максимально безопасно склеить сайты как в Яндекс, так и в Google.
1. Покупаем SSL сертификат
В рамках данной статьи будем рассматривать сертификаты с подтверждением доменного имени и бесплатный let"s encrypt, который, к слову, подключён и к этому блогу.
Какой выбрать SSL сертификат для своего сайта?
Существует с десяток центров сертификации. Но самые популярные: Comodo, GeoTrust и GlobalSign.
Если не брать бесплатные варианты и самые дешёвые сертификаты, то для большинства случаев подойдут следующие:
- Comodo Essential SSL – цена от 650 до 1500 рублей в год;
- GeoTrust RapidSSL - цена от 650 до 1500 рублей в год;
- GlobalSign DomainSSL - от 2000 до 3000 тысяч, но сильно цены не сравнивал по нему, скорей всего есть и дешевле.
Основной минус сертификатов которые дешевле этих, в том, что длина ключа подписи может быть равна 1024 битам. Google и современные браузеры советуют использовать подпись длиною 2048 и более бит. Все вышеописанные сертификаты предоставляют именно такую длину ключа.
Использование бесплатного сертификата Let’s Encrypt
Если проект не коммерческий и не несёт в себе какой-то любой другой функции, связанной с личными данными, регистрациями, введением паролей, то можно использовать бесплатный let"s encrypt. Он обладаем всеми соответствующими характеристиками.
Если планируете подключать сервисы онлайн платежей, то, например, Robokassa с бесплатными сертификатами не будет работать!
Я для себя выбрал Comodo Essential SSL (покупаю по 650 рублей у ). Сложно сказать почему, наверно больше сыграл тот момент, что этот центр сертификации самый популярный в мире:
Важно знать:
- Для кириллических доменов нужны сертификаты с поддержкой IDN;
- Для установки платного сертификата необходимо иметь выделенный ip адрес, для бесплатного Let’s Encrypt это не обязательно.
- Let’s Encrypt выдается на 90 дней и его надо будет переподписывать. Мой хостинг-провайдер () реализовал возможность автоматического продления, за что большое спасибо им!
Если вы не уверены, стоит ли тратить деньги на покупку SSL, то для вас может быть выход установка бесплатного lets encrypt, с переклейкой сайта и определением главного зеркала. А если возникнет в будущем необходимость, то подключите платный сертификат. Для посетителей и поисковиков такой переход будет не заметен и потерь в плане трафика не будет.
2. Подготовка сайта для переезда на HTTPs
Алгоритм действий идентичный для всех систем управления контентом, но я буду делать акцент на WordPress, потому что все сайты у меня на нём и решать некоторые проблемы приходилось с ним.
1 шаг. Устанавливаем новый адрес сайта в настройках WordPress
Эту замену можно сделать и в базе данных на втором шаге. Но могут возникнуть проблемы, если вы выбрали способ замены ссылок на относительные (подробнее ниже).
Замена адреса сайта в административной части WordPress (Настройки -> Общие).
//сайт/contact/
/contact/
http://сайт на https://сайт
Автозамена с помощью SQL команды в phpMyAdmin:
UPDATE wp_posts SET post_content = REPLACE (post_content, "http://сайт" , "https://сайт" ) ;
Если вы воспользовались этой командой, то знайте, что вам надо пройтись так по всем таблицам базы данных (кроме wp_options), так как ссылки ещё есть в таблице с комментариями и так далее. Я лично делаю бекап БД и меняю адреса сразу во всём файле.
Внимание!
Не меняйте ссылки на относительные во всей базе данных, относительными можно делать только для wp_posts (команда выше). Иначе вы замените url сайта в таблице wp_options и потом будут проблемы с авторизацией в админке.
Вот прочитал всё вышеописанное и пришёл к мнению - не надо в базе данных WordPress никаких относительных ссылок , будет меньше проблем! Пусть будут абсолютные.
2 шаг. Меняем все ссылки в шаблоне на относительные, либо на https
Для этого шага советую использовать опять notepad. Выкачать все файлы шаблона на локальный компьютер и автозаменой во всех файлах поменять адреса на относительные:
Могут быть проблемы с подключаемыми внешних скриптами, если сайты на которых они расположены не используют защищённый протокол. Но, сейчас уже большинство сервисов, партнёрских программ перешли установили SSL-сертификат и проблем не должно возникнуть.
3 шаг. Мелкие правки по шаблону
Чтобы админка сайта на WordPress работала через защищённый протокол. Добавьте в файл wp-config код:
define ("FORCE_ SSL _ADMIN" , true ) ;
Решаем проблему со статистикой переходов в Яндекс Метрике. Необходимо на сайт добавить мета тег referrer , это даст возможность отдавать referrer тем посетителям, которые переходят с вашего сайта по ссылкам с не защищённым протоколом.
<meta name = "referrer" content = "origin" >
Чтобы на той стороне, куда идёт трафик, веб мастера в своих системах аналитики смогли отслеживать переходы с вашего сайта. Вам всё равно, а рекламодателям приятно!
На заметку
Сайт будет переклеиваться в поисковиках, будут меняется адреса страниц. Можно воспользоваться этим моментом и поменять, к примеру, неудачную структуру ЧПУ ссылок, перенести какие-то страницы в другой раздел и так далее.
3. Склеиваем сайт
Я не затрагиваю технический процесс подключения сертификата на сервере, я с ним не знаком, да и думаю среди моих читателей мало системных администраторов, которые будут самостоятельно разбираться с этим процессом.
В ISPmanager и подобных консолях реализована автоматическая возможность установки SSL сертификата. В специальное окно необходимо добавить полученный после оплаты и проверки доменного имени коды:
RSA PRIVATE KEY и BEGIN CERTIFICATE
Если вы всё сделали правильно, то сайт должен быть доступен по двум протоколам. После чего можно переходить непосредственно к склеиванию http версии к https. Этот процесс можно разделить на четыре шага:
1. 301 редирект со старого на новый домен.
2. Добавление директивы Host и доступный файл Robots.txt для не главного зеркала
3. Сообщить поисковикам о ваших намерениях поменять главное зеркало сайта.
4. Просканировать сайт на наличие битых ссылок, ошибок.
1. Настраиваем перенаправление
Я сторонник сразу склеить сайты 301 редиректом, но существует мнение, да и сам Яндекс писал у себя на блоге , что лучше оставить две версии сайта доступными для поискового робота, при этом указать главное зеркало в директиве Host и в панели Вебмастера. А 301 редирект включить только после того, как версия c https будет признана главным зеркалом.
Может быть, такой подход и имеет смысл для действительно больших проектов, где несколько десятков тысяч страниц. Но во время переноса информационных сайтов, я не успел заметить серьёзных потерь в трафике, связанных именно с 301 редиректом. Яндекс склеивает сейчас действительно быстро, . За 2-3 недели пока идёт процесс склеивания, старые страницы просто не успевают выпасть из индекса за счёт 301 редиректа и трафик продолжает поступать. Изменение поискового трафика на одном информационном проекте:
28 апреля был установлен SSL сертификат с перенаправлением, а 14 мая Яндекс уже склеил зеркала
Код для 301 редиректа
3. Добавление сайт в панели Вебмастеров
В Яндекс Вебмастере заходите в раздел «Настройки индексирования – Переезд сайта», там добавляете главное зеркало. После удачного склеивания ваш основной сайт и его зеркало будет выглядеть вот так:
В консоли Google для веб-мастеров необходимо добавить новый сайт с https, подтвердить его и нажать на шестерёнку, а там выбрать «Изменение адреса»:
Сканируем сайт на ошибки
После установки 301 редиректа, обязательно просканируйте сайт на наличие битых ссылок, изображений и т.д. Можно с помощью программы .
Даже если вы думаете, что везде заменили ссылки на относительные, всё много раз проверили. Я Вас уверяю, ошибки найдутся, особенно если сайт большой! Если на каких-то страницах всё равное не горит зелёный замочек или у вас перестали работать какие-то скрипты, плагины, то открывайте исходный код страницы и ищите все адреса с http .
Всё, осталось только ждать. Через 2-3 недели Яндекс полностью склеит сайты и в поисковой выдаче появится версия с защищённым протоколом HTTPs. Google потребуется примерно столько же времени.
Проверка SSL сертификата на подлинность
Проверить установку и подлинность вы можете сервисом rus.gogetssl.com/check-ssl-installation . В сети много подобных сервисов, которые показывают уровень сертификата, ключ подписи, центр сертификации, срок действия и т. д.
