Как установить 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–сертификат и установить его на облачный VPS от Infobox . Базовые SSL–сертификаты бесплатно выдает центр сертификации StartCom .

Бесплатные сертификаты StartSSL класса 1 служат для подтверждения доменных имен и адресов электронной почты. Проверки заказчиков, как правило, производятся автоматически и требуют минимального участия со стороны сотрудников StartCom. В процессе проверки подтверждается то, что подписчик является владельцем домена и действующего ящика электронной почты.

Бесплатные сертификаты предназначены для веб-сайтов, которым необходима защита секретности личных данных и предотвращение возможности прослушивания интернет-соединений. Информация, представленная в сертификатах этого вида, кроме имени домена и адреса электронной почты, не подтверждена. Если вам необходима сертификация более высокого уровня - можно заказать SSL сертификат в панели управления Infobox на главной странице в блоке «Мои услуги» -> «Заказать новую услугу». Доступ к панели управления предоставляется при заказе любой услуги, например VPS или облачных VPS .

Для обеспечения секретности передаваемых данных простых сайтов сертификаты StartCom подходят неплохо.
Бесплатные сертификаты от StartCom на самом деле не совсем бесплатные. Если потребуется отзыв сертификата - эта процедура стоит $24 у StartCom.

Заказ бесплатного SSL–сертификата

Откройте страницу заказа бесплатного сертификата SSL. Заполните информацию о вас (данные должны быть реальными, это очень важно).

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

Введите код и нажмите «Continue»

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

После этого будет сгенерирован сертификат для доступа к сертифицирующему центру StartCom. Сохраните его в безопасном месте и установите в систему, выполнив по нему двойной клик мышью и нажав «Install».

Теперь у вас есть доступ к сертифицирующему центру. На следующем шаге введите имя домена, для которого хотите получить сертификат.

Для подтверждения домена необходимо создать на нем один из трех адресов:

• postmaster@domain
• hostmaster@domain
• webmaster@domain

Если у вас еще не подключена почта для домена, можно привязать домен к бесплатной Яндекс.Почте или воспользоваться бизнес-почтой «Офис 24»

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

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

Рекомендуется пропустить этот шаг и сгенерировать CSR на вашем облачном VPS. Так секретный ключ не окажется у StartCom.
Для генерации CSR подключитесь к виртуальному серверу по SSH (подробнее в следующем разделе) и выполните команду:
openssl req -new -newkey rsa:4096 -nodes -keyout /etc/ssl/private.key -out /etc/ssl/domain.csr

В FQDN укажите ваш домен. E–mail адрес обязательно должен быть в этом домене, например [email protected].

После генерации выведите на экран консоли содержимое файла domain.csr:
cat /etc/ssl/domain.csr
и вставьте в поле мастера выдачи сертификатов, который появится после нажатия на Skip окна генерации сертификатов.

Согласитесь с предложенным именем домена.

На следующем шаге добавьте поддомен www к сертификату.

Завершите процесс получения ssl.crt и сохраните его.

Вам понадобится корневой и промежуточный сертификаты StartCom. Для их получения перейдите в раздел Toolbox -> StartCom CA Certificates.
Сохраните файлы по ссылке Class 1 Intermediate Server CA (sub.class1.server.ca.pem) и StartCom Root CA (ca.pem).

В итоге у вас будут сохранены на локальном компьютере следующие полезные файлы:

• ca.pem
• sub.class1.server.ca.pem
• ssl.crt

На сервере в папке /etc/ssl/:

• private.key

Копируем файлы на сервер

Создайте сервер из шаблона Ubuntu 14.04 lamp в облаке . Процесс создания сервера был рассмотрен в статье ранее.
Необходимо скопировать ca.pem, sub.class1.server.ca.pem и ssl.crt в папку /etc/ssl (если ее нет - создать).

Это можно сделать например через Filezilla (установка клиента рассмотрена также в статье). Однако способ подключения будет отличаться, так как нужен доступ не только к папке сайта, но и ко всему серверу.

Добавьте новое SFTP подключение, как показано на скриншоте ниже. Используйте логин и пароль от сервера, которые пришли на вашу электронную почту после создания сервера, а также внешний ip–адрес сервера.

При подключении подтвердите, что вы подключаетесь к известному вам серверу, нажав OK.

Подключение будет успешно установлено.

Перейдите в папку "/etc/ssl" и скопируйте туда файлы ca.pem, sub.class1.server.ca.pem и ssl.crt.

Теперь подключитесь к серверу по SSH .

Включаем SSL в NGINX

В шаблоне LAMP настраивать SSL нужно на реверс-прокси NGINX.

Если ранее при генерации CSR вы установили пароль, расшифруйте приватный ключ командой:
openssl rsa -in /etc/ssl/ssl.key -out /etc/ssl/private.key

Объедините корневой и промежуточный сертификаты командой:
cat /etc/ssl/sub.class1.server.ca.pem >> /etc/ssl/cau.pem

Добавьте к объединению ваш сертификат
cat /etc/ssl/ssl.crt /etc/ssl/cau.pem >> /etc/ssl/group.crt

Откройте результат в nano:
nano /etc/ssl/group.crt
Сохраните изменения (Ctrl+X, Y, Enter).

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

Теперь установите права для доступа к private.key:
chmod 600 /etc/ssl/private.key

Отредактируйте файл конфигурации nginx:
nano /etc/nginx/sites-enabled/default

Внесите изменения, как показано на скриншоте ниже (вместо le-vert.ru используйте ваш домен):

Перезапустите NGINX.
service nginx restart

Если вы попробуете зайти на сайт по ip–адресу по протоколу HTTPS, то вы увидите предупреждение о том, что сертификат небезопасен.

Для безопасного соединения заходите на сайт по имени домена.

Для этого в DNS-записи А для домена и поддомена www укажите ip–адрес сайта и дождитесь обновления DNS. Либо для тестирования пропишите соответствие ip–адреса сервера и домена в файле hosts вашей ОС.

Единственное небезопасное что осталось - картинкa на странице загружается по http. Для того, чтобы сайт был доверенным, загружайте картинки по https.

После того как 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 . В сети много подобных сервисов, которые показывают уровень сертификата, ключ подписи, центр сертификации, срок действия и т. д.

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-сертификатам, поэтому для полноценной конфигурации потребуется указать и другие параметры. Указанные директивы записываются в блоке (для виртуального сервера) или в конфигурационном файле корневого сервера (для стандартного Web-сервера).

В данном примере выполняется включение 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-сайте, доступ к которому должен быть ограничен.

Компания «Окна Рехау» специализируется на производстве и установке пластиковых окон и дверей в Москве. С момента разработки сайта компания заказывает услуги SEO и интернет-рекламы в WebCanape, поэтому специалисты по продвижению тщательно следят за позициями сайта в поиске и планируют долгосрочное развитие ресурса.

После появления новости, что с 1.01.2017 сайты, на которых собираются данные кредитных карт или пароли, будут отмечаться в браузере Google Chrome как потенциально опасные для пользователей, принято решение об установке SSL-сертификата и переводе сайта на защищенный протокол.

HTTPS (от англ. HyperText Transfer Protocol Secure) — расширение http-протокола, которое поддерживает шифрование данных и обеспечивает их защиту от прослушивания и изменения.

Зачем нужен https-протокол?

• Обеспечивает безопасный обмен информацией между сайтом и девайсом пользователя
• Повышает доверие к сайту и поддерживает его репутацию в глазах посетителей
• Число сайтов, которые работают по незащищенному http-протоколу сокращается. HTTPS становится основным стандартом
• HTTPS входит в перечень ранжирующих факторов при поисковой выдаче Google

Как он работает?

Для корректной работы HTTPS используется сертификат, состоящий из открытого и приватного ключа.

Первый нужен клиенту, другой — серверу для шифрования и дешифрования запросов.

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

Почему это важно для сайта?

1. С начала 2017 года Google Chrome помечает некоторые сайты без https как небезопасные и понижает их в выдаче поисковых систем.
2. Если сайт обеспечивает надежную передачу данных (то есть использует протокол https), он может рассчитывать на дополнительный бонус при ранжировании.

Покупаем и устанавливаем SSL-сертификат — 7 простых шагов

Шаг 1 . Переходим на страницу заказа SSL-сертификатов.

Шаг 2 . Выбираем нужный тип сертификата.

Шаг 3 . Генерируем CSR-запрос.

CSR (Certificate Signing Request) — запрос на получение сертификата. Это текстовый файл, содержащий открытый ключ и закодированную информацию об администраторе домена.

Важно! Обязательно сохраните полученный при генерации CSR-запроса файл ключа. Он еще понадобится.

Шаг 4 . Заполняем анкетные данные сертификата (на английском языке), оплачиваем услугу любым удобным способом.

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

Важно! Письмо может быть отправлено только на «approver email», который вы указываете при заказе сертификата.

При необходимости отправку письма подтверждения SSL-сертификата можно повторить.

Письмо подтверждения выглядит так:

Шаг 6 . Дожидаемся выпуска сертификата и скачиваем его с сайта сертификационного центра или сайта-партнера.

Шаг 7 . Устанавливаем сертификат на хостинг, где размещается сайт. Для этого используем файл(ы) сертификата и файл ключа, полученный на 3-м шаге.

Предварительная подготовка сайта к переходу на https

Подготовка проходит в девять этапов.

1. Меняем все ссылки на страницы сайта (и элементы страниц), для которых устанавливается защищенное соединение.
2. Весь контент сайта, в том числе внешние модули, фото и скрипты, тоже должен подгружаться по протоколу https. Иначе браузер посчитает, что на странице есть небезопасные материалы и не покажет в адресной строке зеленый значок. Несмотря на то, что страница будет загружена по https.

Самая распространенная ошибка — размещение на сайте, который работает по https, не только защищенного, но и обычного контента. В таких случаях один или несколько элементов (обычно изображения, скрипты, Flash-файлы или CSS) загружаются на странице https с использованием незащищенного внешнего URL, начинающегося с http://.

Список незащищенных элементов на страницах со смешанным содержанием можно найти в консоли JavaScript (в некоторых браузерах она может называться отладчиком JavaScript) либо в инструментах разработчика браузера.

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

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

1. Версия сайта с https должна быть доступной и работать без ошибок, как и версия с http. Для обеих версий файл robots.txt должен быть одинаковым.

Важно! Ранее рекомендовалось использовать параллельно два файла robots.txt и на период переклейки в Яндекс закрыть https-версии сайта от индексации Google. Сейчас этого не требуется. Был протестирован и утвержден вариант без закрытия от индексации в Google. Если доступны обе версии сайта, Google по умолчанию показывает в выдаче https-версию, а Яндекс делает это только после переиндексации.

В robots.txt должна быть строчка:

Host: https://www. адрес-сайта.ru/

Это значит, что https-версия является главным зеркалом.

Если все сделано верно, результат будет выглядеть так:

1. Добавляем обе версии сайта в Вебмастер Яндекса, указываем предпочтительный протокол в разделе «Настройка индексирования — Переезд сайта».

1. В Google Search Console добавляем сайт с протоколом https и подтверждаем права.

Google понимает, что http и https являются разными протоколами одного и того же сайта. Если он найдет работающий https протокол, по ходу переиндексации контента заменит http на https. Это произойдет даже без перенаправления и добавления https-версии в Google Search Console.

1. Ждем переиндексации сайта в Яндекс. Это произойдет, когда в индекс зайдут версии страниц с https, а версии с http выпадут из него.

Переклейка начинается через 2-3 недели. К сожалению, повлиять на ее скорость невозможно — это автоматический процесс.

Когда начнется переклейка, в Вебмастере Яндекса появится уведомление:

Также можно увидеть, что https-версия стала отображаться как основная:

Неглавное зеркало начнет выпадать из индекса Яндекса, главное — попадать в него:

У крупного ресурса все страницы не переиндексируются мгновенно.

1. После склейки сайтов настраиваем постраничный 301-редирект со страниц с http на страницы с https (за исключением файла robots.txt).

Нежелательно делать это прежде чем сайты будут признаны зеркалами. Иначе по правилам Яндекса при обработке перенаправлений страницы с редиректами исключатся из поиска.

На период склейки зеркал сайт должен оставаться доступным по обоим адресам.

Для перенаправления с http:// на https:// в.htaccess можно воспользоваться тремя способами:

• ручной корректировкой файла htacces;
• настройкой редиректов через панель управления хостингом;
• написанием программного скрипта настройки редиректов.

Результаты

Приведенный алгоритм действий подтвержден Яндексом и протестирован при переезде нескольких сайтов с хорошей историей. Он позволяет свести к минимуму потери трафика и позиции сайта в результатах поиска.

Однако служба поддержки Яндекса отвечает, что не может гарантировать 100% сохранение позиций сайта при склейке зеркал.

Как правило, на время переклейки сайта наблюдается временное ухудшение позиций в результатах поиска как в Яндекс, так и в Google. Но позиции в течение одного-двух месяцев полностью восстанавливаются.

Что еще нужно помнить?

1. Базовый алгоритм перевода сайта на https, который используем при переездах, доступен по ссылке >>
2. Удостоверьтесь в работоспособности и наличии доступов к почтовому ящику, на который высылается письмо со ссылкой на подтверждение выпуска сертификата.
3. Созданная версия с https доступна наряду с версией с http. Причем в robots.txt должна быть прописана строчка, указывающая на то, что https-версия является главным зеркалом.
4. После того как сайты склеятся, нужно настроить постраничный 301-редирект с http на https.
5. Если домен https был признан зеркалом домена http до переклейки (то есть https-версия была признана неглавным зеркалом), нужно расклеить зеркала, а затем выбрать https-версию в качестве главного зеркала.

Хотите заказать установку SSL-сертификата? Свяжитесь с нами по телефону: 8-800-200-94-60 , доб. 321 или оставьте запрос на