Где настроить ssl. Как установить SSL сертификат: пошаговая инструкция. Плагины работающие по HTTP

Компания «Окна Рехау» специализируется на производстве и установке пластиковых окон и дверей в Москве. С момента разработки сайта компания заказывает услуги 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 или оставьте запрос на

С каждым днем необходимость в защищенном соединения стает все острее. Во-первых, это более безопасная работа с сайтом, потому что все данные передаются в шифрованном виде, во-вторых, это зелёный замочек рядом с адресом сайта, что вызывает некое доверие к порталу, в-третьих, по заявлению представителей Google, сайты работающие на https имеют преимущество в поисковой выдаче.

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

Получения и установка SSL-сертификата Let’s Encrypt

1. Для получения сертификата воспользуемся сайтом https://www.sslforfree.com/ . Переходим по ссылке и прямо на главной странице видим основное поле. Вбиваем туда имя нашего домена и нажимаем кнопку “Create Free SSL Certificate” .

2. Далее сайт нам предлагают на выбор несколько вариантом подтверждения домена. Нажимаем “Manual Verification” , после “Retry Manual Verification” . В итоге, мы получаем два файла которые необходимо залить на сайт в папку /.well-known/acme-challenge . Выполняем данные действия и нажимаем “Download SSL Certificate” .

3. Наш SSL-сертификат готов, срок его действия 90 дней , после необходимо повторить процедуру. Остается только установить его на сайт.

4. Процесс установки сертификата на каждом хостинге может немного отличаться, если у вас установлена какая-либо панель управления (ISP Manager, cPanel и т.д.), то сделать через нее не составит большого труда. Для этого переходим в раздел “SSL сертификаты” и выполняем установку по инструкции. В случае отсутствия панели установка происходит через конфиги web-сервера, подробнее о процессе установки SSL-сертификата на Apache в CentOS.

5. Настройка редиректа с http на https . Сделать это можно несколькими способами, через панель хостинга, через файл.htaccess, через конфигурацию вашего web-сервера или через PHP (любой другой язык, на котором сделан сайт).

Все способы рассматривать не будем, это материал для другой статьи. Самый распространённый пример, редирект с http на https через.htaccess . Добавляем нижеуказанный код в начало файла.htaccess:

RewriteEngine On RewriteCond %{HTTPS} off RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI}

< IfModule mod_rewrite . c > RewriteEngine On RewriteCond % { HTTPS } off RewriteRule ^ (. * ) $ https : //%{HTTP_HOST}%{REQUEST_URI} < / IfModule >

6. Процесс установки закончен, теперь необходимо проверить сайт, чтобы все картинки, стили, скрипты подгружались по https соединению , в противном случае сайт не будет помечаться как безопасный. Проще всего вообще удалить “http:” из подключаемых файлов, то есть сделать так.

Вступление

Если у вас безопасный веб-сервер, пользователи, волнующиеся за безопасность своих данных, могут быть уверены, что запросы зашифрованы, поэтому их данные в безопасности. Лучшим путем для этого является использование Apache 2, лидирующего веб-сервера под Linux и Secure Sockets Layer, протокол безопасной передачи данных. Transport Layer Security (TLS) является развитием SSL, но они работают практически одинаково. Я буду ссылаться только на SSL.

SSL - протокол для безопасной передачи зашифрованных данных между веб-браузером и веб-сервером. В большинстве случаев, аутентификацию проходит сервер, что позволяет клиенту быть уверенным в том, что сервер является требуемым ему, а не наоборот. Как бы то ни было, когда соединение устанавливается, обе стороны находятся в безопасности, так как только клиент и сервер имеют доступ к ключу. Это работает в течении многих запросов, сервер не интересует, кем является клиент так долго, сколько он остается тем же клиентом на протяжении запроса. Если вас волнует аутентификация клиента, есть возможность использовать клиентские SSL сертификаты (или htaccess, Kerberos или другие, близкие к ним методы), но это не будет рассматриваться в этой статье.

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

Протокол SSL работает следующим образом:
1. Клиент подключается к веб-серверу и дает список доступных кодов.
2. Сервер берет наиболее устойчивый код, который поддерживает и он, и клиент, и посылает сертификат со своим именем и ключ кодирования, подписанный доверенным Удостоверяющим Центром (Certificate Authority, далее - CA), таким как Verisign.
3. Клиент проверяет сертификат с помощью CA. На практике, хранят набор CA локально, поэтому это может быть сделано без контакта в реальном времени с CA, и поэтому более быстро.
4. Клиент посылает назад случайное число, зашифрованное с помощью публичного ключа сервера. Только клиент знает это число, и только сервер может его расшифровать (используя личный ключ); вот где реализуется безопасность от участия третей стороны.
5. Сервер и клиент используют случайное число для генерирования содержимого ключа, который используется на протяжении передачи данных.

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

Настройка Apache для работы с SSL проста, но есть несколько необходимых шагов. Эта статья рассказывает, как получить сертификат, подписанный CA и как скомпилировать и настроить Apache для работы с SSL. Я использую Apache 2 с mod_ssl . ApacheSSL (реализация Apache с возможностями SSL) также доступен, но сейчас он уже устарел; mod_ssl намного лучше.

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

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

Теоретически, преимуществом использования пароля являтся повышение защиты. Хотя, на практике пароли не дает такой большой защиты. Если кто-то сможет прочитать или скопировать приватный ключ, значит, у него уже есть доступ к системе и возможность получить пароль, например, используя такую программу, как кейлоггер. Пароль защитит от скрипт-кидди, но не от серьезного взломщика. Возможно, для большинства людей нет смысла его использовать.

Для тестовых целей, или для небольшой локальной сети, вы можете создать сертификат, подписанный вами. Вы можете сделать это, выполнив команду:
openssl req -new -x509 -days 365 -sha1 -newkey rsa:1024 \ -nodes -keyout server.key -out server.crt \ -subj "/O=Company/OU=Department/CN=www.example.com"
Давайте рассмотрим опции более подробно:
- -x509 означает, что сертификат обязателен, правильнее, чем просто запрос сертификата (смотри ниже)
- -days 365 устанавливает время истечения сертификата, равное году. Вы можете увеличить этот срок. Запомните дату истечения срока, чтобы обновить её при необходимости.
- -sha1 указывает, что будет использован SHA1 для шифрования.
- rsa:1024 делает ключ 1024 битным RSA.
- -nodes указывает отсутствие пароля.
- -keyout и -out указывают, где хранить сертификат и ключ. Ключ должен быть доступен для чтения только для root; сертификат может быть доступен для чтения для world, но должен быть доступным для чтения пользователю, который запускает Apache.
- -subj устанавливает имя компании, имя отделения компании и адрес веб-сайта. Если вы это пропустите, вас попросят это сделать. CN должен совпадать с адресом сайта, иначе сертификат не будет соответствовать, и пользователи будут получать предупреждение при подключении. Убедитесь, что вы не запрашиваете пароль.

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

Не смотря на это, безусловно, лучше использовать сертификат, подписанный доверенным Удостоверяющим Центром, таким как Verisign (который имеет наибольший охват рынка), или меньшей организацией. Большинство браузеров уже имеют набор предустановленных сертификатов, заверенных CA, которые верифицируют сертификат вашего веб-сервера при подключении клиента. Это уменьшает количество трудностей для конечного пользователя и удостоверяет законность вашего сайта.

Чтобы получить сертификат, подписанный CA, прежде всего вы должны создать криптографическую пару и запрос сертификата:
openssl req -new -sha1 -newkey rsa:1024 -nodes \ -keyout server.key -out www.example.com.csr \ -subj "/O=Company/OU=Department/CN=www.example.com"
Этот пример работает так же, как и предыдущий, но на этот раз мы не используем опцию -x509. Выполнение этой команды приведет к генерации ключа и запроса сертификата, но не самого сертификата. Если вы ввели CN и так далее, вы не должны вводить адрес e-mail или пароль.

Ключ сервера (файл server.key, который, опять же, должен быть доступен для чтения только для root) остается на вашем веб-сервере; запрос (файл www.example.com.csr) отправляется в CA. Вы можете назвать файл запроса так, как вам вздумается, но назвав его по своему доменному имени, вы упростите задачу для CA.

Следующей стадией будет послать этот файл www.example.com.csr в CA, с вашей оплатой. Они должны вернуть его достаточно быстро, если вы предоставили всю требуемую информацию в вашем запросе. Выбранный вами CA объяснит их действия на своем сайте. Вам может понадобиться поменять формат файла на PEM, но, в случае Verisign, этого делать не придется.

Когда вы получите файл назад в PEM формате, переименуйте его в server.crt (это не является строгой необходимостью, но соответствует условиям Apache) и проверьте его:
openssl verify -CAfile /path/to/trusted_ca.crt \ -purpose sslserver server.crt
Затем проверьте, что результат выполнения этих двух команд одинаков, т.е., что сертификат соответствует приватному ключу:
openssl x509 -noout -modulus -in server.pem | openssl sha1 openssl rsa -noout -modulus -in server.key | openssl sha1
Теперь установите ваш ключ (сгенерированный выше как server.key) и сертификат (server.crt) в /etc/apache2/ssl или предпочитаемый вами каталог настроек, если он другой. Как указано выше, очень важно убедиться, что server.key доступен для чтения только для root, в то время как сертификат сервера может быть доступен для чтения для world, но принадлежать и быть доступным для записи только для root.

Компиляция Apache с SSL.

Итак, ваш сертификат сгенерирован. Теперь вам надо настроить свой сервер для его использования.

Для подавляющего большинства людей, лучшим способом установить и управлять Apache2 - модули, полученные через менеджер пакетов вашего дистрибутива. Apache2 из Debian идет вместе с модулем SSL, но он не включен по умолчанию. Для его включения вы должны выполнить команду: a2enmod ssl и перезапустить веб-сервер.

Чтобы сделать это, добавьте строчку
Include /etc/apache2/mod_ssl.conf
в ваш /etc/apache2/apache2.conf (этот файл может также называться httpd.conf). Вы должны исправить её, обозначив соответствующее расположение файла mod_ssl.conf. Затем перезапустите веб-сервер.

Если вы хотите скомпилировать Apache2 из исходных кодов, в зависимости от того, какие установки вы до этого использовали, вы можете уже иметь или не иметь поддержку SSL. Проверьте это командой apache2 -l. Если перекомпиляция понадобится, запустите./configure со всеми опциями, которые вы использовали до этого, добавив к ним --enable-ssl и --enable-setenvif (последняя нужна для совместимости с капризами Internet Explorer). Затем установите его как обычно, с помощью make;make install и проверьте правильность прав доступа.

Настройка Apache с SSL.

Следующим шагом будет настройка Apache2. Следующие инструкции приведут к запуску сервера как безопасного (порт 443) и как обычного веб-сервера (порт 80). Прежде всего, вам надо настроить сервер на принятие запросов на оба порта. Или отредактируйте /etc/apache2/ports.conf (в Debian, это входит в apache2.conf), или отредактируйте /etc/apache2/apache2.conf, включив строки:
Listen 80 Listen 443
Затем отредактируйте /etc/apache2/sites-enabled/yoursite для использования настроек SSL. Разделение настроек обычного и безопасного сервера с помощью VirtualHost - простейший способ из соображений условий эксплуатации. Любые настройки вне секций VirtualHost (например, установка ServerAdmin) будут применяться для обоих (и любых других) VirtualHost. Добавьте следующий текст в файл конфигурации:
# ================================================= # SSL/TLS settings # ================================================= NameVirtualHost *:443 DocumentRoot "/local/www/ssl_html" SSLEngine on SSLOptions +StrictRequire SSLRequireSSL SSLProtocol -all +TLSv1 +SSLv3 SSLCipherSuite HIGH:MEDIUM:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM SSLRandomSeed startup file:/dev/urandom 1024 SSLRandomSeed connect file:/dev/urandom 1024 SSLSessionCache shm:/usr/local/apache2/logs/ssl_cache_shm SSLSessionCacheTimeout 600 SSLCertificateFile /etc/apache2/ssl/server.crt SSLCertificateKeyFile /etc/apache2/ssl/server.key SSLVerifyClient none SSLProxyEngine off AddType application/x-x509-ca-cert .crt AddType application/x-pkcs7-crl .crl SetEnvIf User-Agent ".*MSIE.*" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0
Несколько замечаний об этой конфигурации:
- SSLEngine должен быть включен, обозначая, что сервер использует SSL.
- DocumentRoot устанавливает корневой каталог виртуального хоста. Это значит, что вы можете отделять безопасное содержимое от обычного.
- SSLRequireSSL запрашивает использование SSL (на этом виртуальном сервере), то есть, пользователь не может подключиться к этому виртуальному хосту с помощью обычного HTTP-запроса. Вот зачем мы разделили безопасное и обычное содержимое.
- SSLProtocol отключает все протоколы, отличные от TLS v1.0 и SSL v3.0. Для современных браузеров все будет работать хорошо.
- SSLCipherSuite устанавливает использование только HIGH и MEDIUM шифров. SHA1 считается более безопасным, чем MD5, поэтому выбран он.
- SSLCertificateFile и SSLCertificateKeyFile указывают расположение файлов сертификата и ключа.
- SSLVerifyClient должна быть установлена как "none", если не используется аутентификация примера.

Чтобы запускать обычный сервер на 80 порту, добавьте следующий текст в конфигурационный файл:
NameVirtualHost: *.80 DocumentRoot "/local/www/html"
После сохранения отредактированного конфигурационного файла, перезапустите сервер. Если вы использовали пароль при генерации сертификата, вам понадобится ввести его при запросе.

Тестирование.

Создайте базовую страницу index.html в корневой директории вашего сервера, если у вас ещё нет содержимого там.

Затем направьте свой браузер на https://yoursite.com. Вы должны увидеть открытие SSL-соединения и загрузку страницы. Если вы используете сертификат, подписанный вами, ваш браузер даст предупреждение о том, что подлинность сервера не может быть проверена. Вы можете выбрать просмотр сертификата и принять его. Если вы используете внешний сертификат, все должно пройти без проблем.

Убедитесь, что не можете получить доступ к безопасному содержимому, используя http://. Если вы попробуете, вы должны получить сообщение об ошибке.

Устранение проблем.

Если это работает не так, как ожидалось, прежде всего, проверьте, что ваш сервер вообще запущен с помощью команды ps -a | grep apache. Если она не вернет результата, попробуйте перезапустить сервер и проверьте сообщения об ошибке в консоли.

Также проверьте, что права доступа к файлам сертификата и ключа установлены правильно (см. выше), также, как и права к тестовому HTML-файлу и директории, в которой он находится.

Затем, проверьте логи. Вы должны проверить как логи сервера, так и логи SSL, которые вы настроили в конфигурационном файле выше. Если вы не нашли там ничего полезного, попробуйте поменять значение LogLevel в файле конфигурации Apache2 на "debug", перезапустите Apache2 и протестируйте снова. Это должно дать больше данных в логах.

Если вы запускаете веб-сервер на 80 порту, попробуйте запросить страницу с помощью http://, вместо https://, чтобы понять, заключается ли проблема в веб-сервере или в SSL-соединении. Учтите, что в приведенных выше установках, корневые каталоги веб-сервера разные для http:// и https://, так что вы не можете (или не должны!) получить доступ к тому же содержимому. Если ваша тестовая страница в корневом каталоге http:// работает, в то время, как тестовая страница в корневом каталоге https:// не работает, это поможет вам более точно указать на проблему.

Если проблема в SSL соединении, удобным инструментом будет s_client, который является диагностической утилитой для решения проблем в TLS/SSL-соединениях. Обычное его использование: /usr/bin/openssl s_client -connect localhost:443. Также существует множество других опций, которые вы можете узнать из документации. Если вы получили сообщения об ошибках, это должно вам помочь в определении проблемы.

Заключение.

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

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

Если настроить SSL неверно, пользы не будет даже от наилучшего сертификата

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

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

Пройдя проверку и получив файлы сертификата, Алексей взялся за его установку. Он шаг за шагом следовал руководству по установке. Но что-то пошло не так… Страница начала загружаться медленней, временами была недоступной, и, как выяснилось в тесте от Qualys SSL Labs, не была действительно защищенной. Что же произошло?

Ошибки конфигурации из-за устаревшего руководства

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

Например, в инструкции отсутствовало указание, что нужно отключить SSL 3-й версии. Уже давно известно о небезопасности протоколов шифрования SSLv3 и RC4, и существует достаточно альтернатив для них. В октябре 2015 года поисковый гигант Google решил попрощаться с этими небезопасными стандартами. Поэтому мы посоветовали Алексею отключить эти SSL-протоколы и использовать TLS в версиях 1.0, 1.1 и 1.2.

Конфигурация SSL при обмене ключами

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

Cookies также следует защищать

Алексей решил использовать файлы Cookies. Он добавил соответствующее предупреждение для посетителей сайта и указал на использование этого технологии в Политике конфиденциальности.

Тем не менее, он не заметил одну деталь: файлы cookies также необходимо защищать, в противном случае возрастает возможность проведения MITM-атаки. С помощью специальных флагов можно установить, будут ли cookies передаваться по защищенному HTTPS-соединению или по незащищенному HTTP-соединению.

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

Использование HSTS для устранения ошибок

Как мы видим, возможность управлять зашифрованными сайтами через HTTP, то есть по незащищенному каналу, открывает большую дыру в безопасности. Эту проблему можно решить с помощью механизма HSTS. HSTS (сокращенно от «HTTP Strict Transport Security») – это технология, которая принудительно активирует защищенное HTTPS-соединение. Все современные браузеры используют HSTS как стандарт. Активированный HSTS устанавливает, что (HTTP-)сервера должны использовать защищенное соединение. Также HSTS-стандарт обязывает прикладные программы взаимодействовать с сайтом только по зашифрованному каналу. В двух словах: HSTS предотвращает использование HTTP и активирует HTTPS-соединение.

OCSP для увеличения секретности

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

С помощью метода «OCSP-Степлинг» можно решить проблемы, вызванные OCSP. Через определенные промежутки времени, например, каждый час, веб-сервер получает OCSP-ответ о состоянии собственного сертификата. Этот ответ отправляется непосредственно браузеру пользователя при первичном рукопожатии. Соединение между браузером пользователя и OCSP-ответчиком с этой целью не требуется. Безопасность процесса обеспечивается тем, что ответ OCSP–ответ всегда подписан OCSP-ответчиком центра сертификации, и эту подпись проверяет браузер.

HPKP — пиннинг открытого ключа

Можно ли доверять сертификату из цепочки корневого и промежуточных сертификатов? Чтобы получить ответ на этот вопрос, используется процедура, называемая HPKP, сокращенно от HTTP Public Key Pinning. Пиннинг открытого ключа позволяет определить, когда открытый ключ сертификата был изменен для определенного хоста. Это может произойти со скомпрометированными сертификатами. Таким образом, HPKP становится механизмом, который проверяет подлинность сертификатов SSL/TLS.

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

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

• используйте безопасное HTTPS-соединение для всех веб-сервисов;
• автоматическое перенаправление: чтобы избежать незашифрованных обращений к серверу, настройте автоматическое перенаправление на HTTPS-версию;
• библиотеки TLS: полагайтесь только на последние версии. При использовании TLS вы никого не исключаете, но если вы применяете незащищенный SSL, вы также включаете и потенциальных хакеров;
• настройте HSTS, чтобы гарантированно исключить незашифрованные соединения. Это можно сделать двумя способами: во-первых, вы можете дополнить заголовок HSTS так, чтобы браузер обращался только к HTTPS-версии сайта. Во-вторых, вы можете поместить свой сайт в список предварительной загрузки HSTS. Он оповещает современные браузеры, что HTTP-обращения необходимо автоматически перенаправлять на HTTPS;
• заказывайте SSL/TLS сертификаты только на доверенных сайтах;
• лучше всего заказывайте SSL сертификаты с расширенной проверкой (

TLS или безопасность транспортного уровня - предшественник SSL, отвечает за безопасность на уровне сокетов, по сути это защищённый протокол созданный для того, чтобы обеспечить безопасную передачу обычного сетевого трафика.

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

В этой статье я расскажу как создать самостоятельно подписанный сертификат SSL для Apache на базе Ubuntu 14.04, что позволит вам шифровать поступающий трафик. Хотя такой способ не обеспечивает проверки подлинности сервера, он позволяет пересылать информацию в защищенном режиме.

Требования

Прежде чем начать, требуется выполнить некоторые настройки. Пользователь, под которым мы будем работать должен иметь sudo привелегии. Также нам понадобится установленный Apache. Если вы его ещё не установили, то можете сделать это выполнив следующие команды:

Sudo apt-get update sudo apt-get install apache2

Шаг 1 - Активация модуля SSL

Пакет Apache для Ubuntu 14.04 по-умолчанию поддерживает SSL . Его достаточно просто активировать. Команда для активации модуля:

Sudo a2enmod ssl

После активации SSL следует перезапустить сервер для вступления в силу новых настроек:

Теперь наш веб сервер поддерживает SSL, осталось выполнить некоторые настройки.

Шаг 2 - создание подписанного сертификата SSL

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

Sudo mkdir /etc/apache2/ssl

Теперь создадим здесь ключ и сертификат одной командой:

Sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/apache2/ssl/apache.key -out /etc/apache2/ssl/apache.crt

Давайте подробно разберёмся в параметрах команды:

• openssl - основной инструмент для создания и управления сертификатами, ключами, запросами на подпись и т.д. для OpenSSL
• req - этот параметр задаёт запрос на подпись сертификата X.509. X.509 - стандартная структура открытого ключа, которой придерживается SSL для управления ключами и сертификатами. Нам необходим этот параметр так как мы хотим создать новый сертификат.
• -x509 - этот параметр указывает на то, что мы хотим создать самостоятельно подписанный сертификат.
• -nodes - указывает на то, что мы не хотим создавать кодовую фразу. При создании кодовой фразы у вас могут возникнуть проблемы при автоматическом запуске Apache, так как каждый раз придется её вводить.
• -days 365 - срок действия сертификата - один год.
• -newkey rsa:2048 - этот параметр указывает на одновременное создание приватный ключа и запроса на сертификат. Это необходимо, так как мы не создали приватный ключ заранее. rsa:2048 - создает RSA ключ длиной 2048 бит.
• -keyout - имя файла создаваемого приватного ключа.
• -out - имя файла создаваемого сертификата.

После запуска этой команды вам предстоит ответить на несколько вопросов. Наиболее важный из которых - Common Name (e.g. server FQDN or YOUR name)". Здесь следует ввести доменное имя ассоциируемое с сертификатом, или открытый IP адрес при отсутствии доменного имени.

Вопросы выглядят примерно следующим образом:

Country Name (2 letter code) :RU State or Province Name (full name) :Moscow Locality Name (eg, city) :Moscow Organization Name (eg, company) :Your Company Organizational Unit Name (eg, section) :Department of Kittens Common Name (e.g. server FQDN or YOUR name) :your_domain.com Email Address :[email protected]

Ключ и сертификат будут созданы в каталоге /etc/apache2/ssl .

Шаг 3 - Настройка Apache для использования SSL

Теперь у нас есть сертификат и ключ и мы можем настроить Apache для использования этих файлов в файле виртуальных хостов. Вместо использования шаблона 000-default.conf мы воспользуемся шаблоном default-ssl.conf , который уже включает в себя некоторые необходимые настройки.

Откройте этот файл с правами root:

Sudo nano /etc/apache2/sites-available/default-ssl.conf

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

ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined SSLEngine on SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key SSLOptions +StdEnvVars SSLOptions +StdEnvVars

Выглядит довольно сложно, но нам и не надо глубоко вникать в структуру этого файла. Для начала укажем обычные параметры, которые мы задаем при создании виртуального хоста (ServerAdmin, ServerName, ServerAlias, DocumentRoot и т.д.) и укажем место хранения SSL сертификатов. В итоге файл настройки должен выглядеть примерно следующим образом:

ServerAdmin [email protected] ServerName your_domain.com ServerAlias www.your_domain.com DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined SSLEngine on SSLCertificateFile /etc/apache2/ssl/apache.crt SSLCertificateKeyFile /etc/apache2/ssl/apache.key SSLOptions +StdEnvVars SSLOptions +StdEnvVars BrowserMatch "MSIE " \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 BrowserMatch "MSIE " ssl-unclean-shutdown

Сохраните и закройте файл после исправления.

Шаг 4 - активация виртуального хоста с SSL

Теперь настало время включить наш виртуальный хост. Выполняем команду:

Sudo a2ensite default-ssl.conf

Перезапускаем Apache:

Sudo service apache2 restart

Теперь виртуальный хост, который будет служить для безопасной передачи данных, должен запуститься.

Шаг 5 - проверка

Итак, мы выполнили предварительную настройку, настало время проверить её. Заходим на наш сервер через протокол https://

Https://you_domain.com

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

Итак, нажимаем “Proceed anyway” (продолжить). Вы будете перенаправлены в корневой каталог вашего домена. Теперь ваш трафик зашифрован. Вы можете убедиться в этом увидев значок замка на панели меню.

Заключение

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

Если вы собираетесь запускать проект с использованием SSL, следует задуматься над приобретением SSL сертификата от удостоверяющего центра.