Ssl enabled что это
Правильная настройка SSL в NGINX
В данной инструкции разберем принцип правильной настройки поддержки https в веб-сервере NGINX, которая пройдет проверку безопасности с присвоением максимальной категории. Тестировать конфигурацию мы будем с помощью сервиса https://www.ssllabs.com/ssltest/ — наша задача получить категорию А:
Статья не рассчитана на новичков — вы должны понимать общие принципы настройки https в NGINX. Команды, приведенные в данном руководстве выполняются на системе Linux. Для Windows принцип настройки остается таким же, за исключением конкретных команд и путей до конфигурационных файлов.
Для достижения результата мы рассмотрим:
1. Правильный сертификат
Под этим подразумевается выполнение двух условий:
Доверенный центр
Есть список центров сертификации, внесенные в общий реестр доверенных узлов, которые могут выпускать ключи безопасности. Данным центрам по умолчанию доверяют все основные операционные системы.
Для получения сертификата от правильного центра, необходимо за него заплатить или получить бесплатно от Let’s Encrypt. Купить сертификат можно у большинства хостеров или регистраторов доменных имен. Для получения бесплатного сертификата можно воспользоваться инструкцией Получение бесплатного SSL сертификата Let’s Encrypt.
И наоборот, сертификат может быть выпущен не доверенным центром или локально на компьютере (самоподписанный). В таком случае мы получим ошибку при проверке подлинности.
Сертификат для домена
Заказывая сертификат, мы обязательно указываем, для какого доменного имени его будем использовать. Это обязательное требование. Например, если мы хотим настроить SSL-подключение к узлу security.dmosk.ru, то необходимо указывать именно это имя при заказе ключа безопасности. В противном случае, браузер будет выдавать нам ошибку, что сертификат выдан для другого узла.
Также мы можем заказать сертификат типа wildcard — он применим к домену и все его поддоменам. Например, в нашем случае мы можем заказать ключ для *.dmosk.ru — он будет применять для любого доменного имени 3-го уровня с корнем dmosk.ru.
2. Использование всей цепочки сертификатов
Применяя сертификат в NGINX, необходимо загрузить не только сертификат для домена, но и для всех центров сертификации — как основного, так и промежуточных. В противном случае, мы получим ошибку This server’s certificate chain is incomplete. Grade capped to B:
В случае покупки сертификата, нам отправляют все ключи в отдельных файлах. Цепочка сертификатов, как правило, идет в файле chain. Мы должны скопировать последовательность в данном файле и добавить ее к содержимому в файле с сертификатом домена — получиться файл, содержащий как последовательность для домена, так и всех центров. Назвать его можно fullchain.pem.
В случае получение бесплатного сертификата от Let’s Encrypt, мы получаем 4 файла, один из которых называется fullchain.pem — именно он и содержит все необходимые последовательности.
И так, при настройке виртуального домена в NGINX, необходимо указать путь до файла, содержащего в себе все ключи, например:
server <
listen 443;
server_name security.dmosk.ru;
ssl on;
ssl_certificate /etc/nginx/ssl/fullchain.pem;
ssl_certificate_key /etc/nginx/ssl/cert.key;
* в данном примере мы настраиваем NGINX для домена security.dmosk.ru; обратите внимание, что мы указали путь до файла fullchain.pem, в котором должны находиться последовательности, как для домена, так и центров сертификации.
Не забываем перезапустить nginx:
systemctl restart nginx
3. Отключение устаревших протоколов
В случае, если наш веб-сервер поддерживает подключение с использованием устаревших протоколов безопасности, например, TLS 1.0, мы получим ошибку This server supports TLS 1.0 and TLS 1.1:
В NGINX нам необходимо перечислить протоколы, по которым разрешено подключение. Лучше всего это сделать в основном конфигурационном файле:
Внутри раздела http добавим:
* в данном примере мы указали, что разрешены подключения только по TLS версии 1.2.
Не забываем перезапустить nginx:
systemctl restart nginx
4. Задаем приоритет для серверных шифров
Нам необходимо указать, чтобы при использовании протокола TLS серверные шифры были приоритетнее, чем клиентские. В противном случае мы увидим ошибку This server does not support Forward Secrecy with the reference browsers:
Задать настройку можно в разделе http основного конфигурационного файла:
http <
.
ssl_prefer_server_ciphers on;
..
>
Не забываем перезапустить nginx:
systemctl restart nginx
5. Настройка более стойкого ключа Диффи-Хилмана
Для шифрования сессий NGINX использует DH-шифры. Если последовательность не достаточно стойкая (ниже 2048 бит), мы увидим ошибку This server supports weak Diffie-Hellman (DH) key exchange parameters:
Чтобы исправить ошибку, генерируем стойкую последовательность для Diffie-Hellman файла:
В настройках NGINX (разделе http) добавляем:
Не забываем перезапустить nginx:
systemctl restart nginx
(Опционально) Перенаправление с 80 на 443
Стоит добавить настройку для перенаправления запроса с http на https. Для этого в настройке виртуального домена в NGINX добавим:
SSL. Безопасность передачи данных
Как давно вы проверяли надежность своего SSL? Мало просто купить SSL сертификат и его установить, нужно его и настроить.
Почему это важно. Внешний анализ безопасности (ручной или автоматический) обычно начинается с проверки SSL-конфигурации. SSL конфигурация обычно показывает общий уровень защищенности всей системы защиты данных. Поэтому продвинутые пользователи начинают слать запросы типа “как вы можете защитить мои персональные данные, если у вас ещё SSL v3 включён”. В рамках GDPR надежная настройка SSL относится к техническим мерам по защите персональных данных.
Тестирование конфигурации SSL
Проблемы связанные с версиями SSL протоколов:
SSL 2.0, SSL 3.0 и TLS 1.0 настоятельно рекомендуется отключить, так как большинство стандартов безопасности их уже давно не поддерживают (например, PCI DSS 3.1).
Рекомендуемые протоколы TLS v1.1 и TLS v1.2 с актуальными алгоритмами шифрование и снятия хэшей.
Анализ конфигурации SSL
Есть замечательный инструмент SSLLabs Test Tool для проверки тестирования надёжности конфигурации SSL.
A+ и А — это наилучший показатель конфигурация SSL. F — наихудший уровень.
Пример теста SSL для одного из наших сайтов продуктов
Ниже приведен еще один пример того, как быстро проверить уровень SSL-конфигурации с помощью инструмента nmap:
Низкий уровень конфигурации SSL в большинстве случаев связан с использованием устаревших и слабых алгоритмов шифрования.
Этот ресурс предоставляет информацию о том, как настроить хорошие SSL-алгоритмы на Apache, nginx, HAProxy и т. д.
Конфигурация на Nginx
Ниже приведен пример конфигурации веб-серверов на nginx, которые повысили настройку SSL с уровня B до A + и повысили защиту системы:
Конфигурация на Windows
Windows Server 2016 и выше уже имеют конфигурацию SSL, которая соответствует действующим регламентам безопасности (например, SSL v2 и SSL v3 отключены).
В более ранних версиях Windows Servers (2008, 2012) SSL v3 все еще включен, т. е. Вам необходимо вручную отключить устаревшие протоколы. См. рекомендации Microsoft: как отключить PCT 1.0, SSL 2.0, SSL 3.0 или TLS 1.0
Мы используем инструмент IIS Crypto tool, который предоставляет графический интерфейс для отключения слабых шифров и устаревших протоколов. Это позволяет избежать опасной ручной работы с реестром Windows.
Использование SSLLabs Test Tool, его советов и функциональных возможностей позволяет быстро защитить SSL / TLS на Windows.
Реальный пример конфигурации SSL для Windows Server 2012 R2
Что такое SSL и TLS, как установить и настроить
Что такое SSL, TLS
SSL (англ. secure sockets layer — уровень защищённых cокетов) — криптографический протокол, который обеспечивает безопасную связь между сервером и клиентом. Этим протоколом шифруется интернет-трафик, который невозможно прослушать. В 2014 году был скомпрометирован (была обнаружена уязвимость), из-за чего на основании протокола SSL 3.0 был создан стандарт TLS, учитывающий ошибки предшественника, а SSL фактически прекратил своё развитие.
TLS (англ. Transport Layer Security — безопасность транспортного уровня) — криптографический протокол, обеспечивающий защищённую передачу данных от сервера к клиенту. TLS является потомком SSL 3.0. В основе работы лежат симметричное шифрование для конфиденциальности, асимметричная криптография для аутентификации и коды аутентичности сообщений для сохранения их целостности.
Данный протокол широко используется в приложениях, работающих с сетью Интернет, таких как веб-браузеры, работа с электронной почтой, обмен мгновенными сообщениями и IP-телефония (VoIP).
Сегодня, когда говорят об SSL, то, как правило, подразумевают его потомка TLS. Поэтому, когда говорят, что нужно установить SSL сертификат на сайт, то, как правило, подразумевают установку TLS сертификата.
Почему нужно использовать SSL/TLS
Есть как минимум одна веская причина: вы не сможете воспользоваться преимуществами нового протокола HTTP2 (HTTP/2 приходит на смену текущему стандарту HTTP/1.1), если для вашего сайта не установлен и настроен сертификат безопасности SSL/TLS.
Также безопасность данных в интернете является всё более востребованной и актуальной темой. И чем дальше, тем больше: Google заявил, что наличие SSL-шифрования на сайте является положительным фактором в ранжировании сайта в поисковой выдаче. Также, наличие HTTPS является обязательным атрибутом для каждого e-commerce сайта: интернет-магазинов, сервисов по приёму платежей, обменников, а также платных сервисов, данные пользователей которых являются желанной добычей хакеров. Чтобы предотвратить фишинг-атаку на пользователя и не дать обмануть его, и нужно настроить SSL-сертификат безопасности и шифрования данных, чтобы он видел подтверждение того, что находится на правильном сайте.
Бесплатные сертификаты SSL/TLS от Let’s Encrypt
Рекомендую воспользоваться сертификатами SSL/TLS от Let’s Encrypt, так как:
Из минусов — сертификат актуален 90 дней, поэтому настроим его обновление на автомате.
Если у Вас виртуальный хостинг, можете написать в службу поддержки, вам помогут получить сертификат и всё настроят. Если же у вас свой сервер, описание получения сертификата SSL, TLS и его настройки на сервере будет дальше.
Установка Certbot
Сам гайд по установке Let’s Encrypt советует делать всё через Certbot. Сработает, если есть доступ по SSH.
Certbot — это утилита от Let’s Encrypt, помогающая в настройке SSL/TLS сертификата на сервер и его дальнейшем обновлении.
Установка Certbot в Debian 8 Jessie
Помощник Certbot в выборе версии сервера
Если вылезла ошибка The value ‘jessie-backports’ is invalid for APT::Default-Release as such a release is not available in the sources
, нужно настроить поддержку Backports
Как настроить поддержку Backports
Пишете в консоль (добавляет дополнительный источник для пакетов):
Потом обновляете список пакетов:
и снова пробуете установить Certbot:
Затем проверяете, как вышло
Установка Certbot в CentOS 7
Установка происходит так:
Если у Вас CentOS 6, воспользуйтесь универсальной инструкцией ниже.
Универсальная инструкция по установке Certbot
Должы увидеть что-то подобное:
Настройка Certbot
В директории должен появиться файл certbot с примерно следующим содержанием 
Самая последняя строчка — это правило cron, которое будет проверять сертификаты SSL, TLS дважды в день и обновлять устаревшие. К сожалению, он не перезагружает вебсервер, поэтому Вам нужно добавить правило && /etc/init.d/nginx reload вручную в конец строки.
В итоге, строка будет выглядеть примерно так:
Если строка в cron.d отстутствует, можно установить правило обновления сертификатов вручную:
Далее, подготовка, тестирование и установка сертификата для сайта.
Подготовка и тестирование конфигурации SSL, TLS
Перед тем, как получить сертификат SSL/TLS, хорошей практикой будет протестировать правильность настройки сервера. Дело в том, что если есть проблема, которая не даст получить или обновить сертификат: центр сертификации имеет жёсткие лимиты обращений к нему (10 в час). И если есть ошибка, которую никак не удаётся выявить, то можно очень быстро упереться в лимит. Чтобы избежать этой проблемы, можно воспользоваться Staging Environment от Let’s Encrypt.
Staging Environment — это тестовая среда, полностью имитирующая общение с центром сертификации, и выдающая недоверенные сертификаты-пустышки. Однако, она имеет повышенные лимиты обращения к ней и служит исключительно для тестирования и настройки конфигурации сервера:
Кстати, посмотреть, как происходит обновление сертификатов, но без реального обновления, просто проверить правильность конфигурации, можно командой:
А обновить все сертификаты на сервере вручную можно командой
После перезагрузите NGINX
Установка сертификата SSL, TLS от Let’s Encrypt
Вводим команду в консоль Putty:
Если домен в кириллице, надо получить его Punnycode (например, яндекс.рф имеет код xn--d1acpjx3f.xn--p1ai ) и пользоваться этим кодом. Сделать это можно с помощью Punycode-конвертера.
Если всё нормально, вам выдаст сообщение об успешном завершении создания сертификата 
Итак, сертификат установлен в директорию /etc/letsencrypt/live/<тут_ваш_домен>/
Идём настраивать NGINX.
Настройка SSL, TLS в NGINX
Открываем конфигурационный файл вашего сайта.
Если NGINX настроен как тут, то конфигурационный файл может быть расположен тут:
/etc/nginx/vhosts/example.com.conf
Для уменьшения загрузки процессора официальная документация рекомендует
Изменения я буду комментировать
Сохранили, проверили, перезагрузили
Настройка SSL, TLS на WordPress
Для примера, возьмём сайт на WordPress и настроим на нём SSL/TLS, сделаем его доступным по HTTPS.
Нужно будет обязательно пройтись по списку и внести соответствующие изменения:
2 и 3 строки не обязательны, если выполнили первый пункт списка.
Как перенести сайт с HTTP на HTTPS правильно
Я считаю, что можно не ждать склейки http и https, и сразу настроить редирект на https, они всё равно склеятся, но далее приведу рекомендации, которые дают специалисты по поисковому продвижению
Если вы переводите существующий проиндексированный сайт на SSL, то сначала рекомендуется, чтобы Yandex склеил http и https версии сайта. Для этого, вы должны сначала настроить сайт так, чтобы он был доступен и по http, и по https верно, а затем прописать в robots.txt нужный адрес в директиве Hosts.
Не забудьте добавить новую версию сайта на HTTPS в Яндекс Вебмастер и Google Webmasters.
Вот, скажем, пример файла robots.txt для сайта sheensay.ru
Далее, дождавшись, когда Яндекс всё склеит правильно, можно настроить 301 редирект с http на https
Как настроить 301 редирект с HTTP на HTTPS
Для NGINX мы настраивали редирект выше, поэтому если редирект настроили в нём, в Apache ничего не меняем. Но, для примера, покажу блок, ответственный за него
301 редирект с HTTP на HTTPS в NGINX
Эта конструкция отлавливает все запросы к портам, отличным от 443 (а именно на 443 порту сидит SSL), и редиректит на нужную версию сайта с HTTPS.
301 редирект с HTTP на HTTPS в WordPress
Чтобы сделать 301 редирект на https в wordpress, достаточно найти в корне сайта wp-config.php и прописать там в любом месте (если ещё не прописано, example.com меняете на свой домен):
В большинстве ситуаций этого достаточно.
Если доступа к wp-config.php нет, то есть ещё один вариант.
Код ниже используете в MU Plugin, также можно создать обычный плагин (требует активации) или вставить в functions.php рабочей темы:
Перед включением кода убедитесь, что сайту уже присвоен HTTPS: (Настройки — Общие)
Как проверить правильность работы SSL, TLS
В интернете можно найти множество сервисов, которые помогут определить, как правильно вы установили SSL и настроили сайт под него.
Один из таких сервисов: ssllabs.com
Рекомендую проверять правильность установки и настройки сертификата SSL/TLS с помощью ssllabs.com
Вы просто вводите адрес сайта и через несколько минут получаете результаты теста. Например, вот высший результат тестирования ( A+ ) по домену https://sheensay.ru
Результат тестирования SSL/TLS
Как усилить безопасность SSL, TLS
Затем, необходимо присутствие следующих записей в конфигурации сервера:
После всех манипуляций, не забудьте перезагрузить NGINX
Видео установки и настройки SSL сертификата в хостинге Beget
Если Вы хотите установить SSL, TLS сертификат на сайт, который расположен в Beget, Вам пригодится следующая видеоинструкция:
Как установить SSL/TLS, если на сервере несколько сайтов
Обычно, проблемы возникают, когда на сервере уже есть 1 сайт на HTTPS, и на этот сервер нужно перенести другой сайт.
Либо, ещё более патовая ситуация: нужно перенести сайт на HTTP и сделать его доступным по HTTPS. Проблема будет возникать из-за того, что на сервере на порту 443 уже есть сайт с сертификатом SSL/TLS, и обращения будут идти на него, и certbot не сможет прописать сертификат сайту, а сайты по HTTP будут недоступны.
Для решения этой проблемы можно сгенерировать временный самоподписанный сертификат:
Эта команда создаст 2 файла в директории, из которой вызывается команда (обычно это /root ):
Самоподписанные сертификаты годится, скорее, для служебных целей, нежели чем для использования на рабочих сайтах. Дело в том, что к ним нет никакого доверия, они не обеспечивают должной защиты для пользователя, и браузеры будут предупреждать об этом. Но, скажем, в случае настройки сервера с несколькими сайтами, а также для редиректа с HTTPS на HTTP вполне годятся.
Ключи прописываете в конфигурации сервера (пример есть ниже). Далее:
Пример, как сделать редирект с HTTPS на HTTP в NGINX
SSL certificate problem: certificate has expired
Что делать, если при запросах curl вылезает ошибка:
curl: (60) SSL certificate problem: certificate has expired
More details here: https://curl.haxx.se/docs/sslcerts.html
Самым правильным вариантом будет обновление сертификатов на сервере. В Linux Debian, Ubuntu это делается так:
Если это не помогло, то нужно будет обновить пакеты системы.
Сначала убедитесь, что пакеты безопасности в /etc/apt/sources.list выглядят примерно так:
Если всё в порядке, обновляем пакеты
После обновления изменения можно проверить с помощью команды:
MNorin.com
Блог про Linux, Bash и другие информационные технологии
TLS и SSL: Необходимый минимум знаний
TLS и SSL упоминаются в последнее время все чаще и чаще, более актуальным становится использование цифровых сертификатов, и даже появились компании, готовые бесплатно предоставлять цифровые сертификаты всем желающим, чтобы гарантировать шифрование трафика между посещаемыми сайтами и браузером клиента. Нужно это, естественно, для безопасности, чтобы никто в сети не мог получить данные, которые передаются от клиента серверу и обратно. Как же это всё работает и как это использовать? Чтобы это понять, надо, пожалуй, начать с теории, а потом показать на практике. Итак, SSL и TLS.
Что такое SSL и что такое TLS?
SSL — Secure Socket Layer, уровень защищенных сокетов. TLS — Transport Layer Security, безопасность транспортного уровня. SSL является более ранней системой, TLS появился позднее и он основан на спецификации SSL 3.0, разработанной компанией Netscape Communications. Тем не менее, задача у этих протоколов одна — обеспечение защищенной передачи данных между двумя компьютерами в сети Интернет. Такую передачу используют для различных сайтов, для электронной почты, для обмена сообщениями и много еще для чего. В принципе, можно передавать любую информацию таким образом, об этом чуть ниже.
Безопасная передача обеспечивается при помощи аутентификации и шифрования передаваемой информации. По сути эти протоколы, TLS и SSL, работают одинаково, принципиальных различий нет. TLS, можно сказать, является преемником SSL, хотя они и могут использоваться одновременно, причем даже на одном и том же сервере. Такая поддержка необходима для того, чтобы обеспечить работу как с новыми клиентами (устройствами и браузерами), так и с устаревшими, которые TLS не поддерживают. Последовательность возникновения этих протоколов выглядит вот так:
SSL 1.0 — никогда не публиковался
SSL 2.0 — февраль 1995 года
SSL 3.0 — 1996 год
TLS 1.0 — январь 1999 года
TLS 1.1 — апрель 2006 года
TLS 1.2 — август 2008 года
Принцип работы SSL и TLS
Принцип работы SSL и TLS, как я уже сказал, один и тот же. Поверх протокола TCP/IP устанавливается зашифрованный канал, внутри которого передаются данные по прикладному протоколу — HTTP, FTP, и так далее. Вот как это можно представить графически:
Прикладной протокол «заворачивается» в TLS/SSL, а тот в свою очередь в TCP/IP. По сути данные по прикладному протоколу передаются по TCP/IP, но они зашифрованы. И расшифровать передаваемые данные может только та машина, которая установила соединения. Для всех остальных, кто получит передаваемые пакеты, эта информация будет бессмысленной, если они не смогут ее расшифровать.
Установка соединения обеспечивается в несколько этапов:
1) Клиент устанавливает соединение с сервером и запрашивает защищенное подключение. Это может обеспечиваться либо установлением соединения на порт, который изначально предназначен для работы с SSL/TLS, например, 443, либо дополнительным запросом клиентом установки защищенного соединения после установки обычного.
2) При установке соединения клиент предоставляет список алгоритмов шифрования, которые он «знает». Сервер сверяет полученный список со списком алгоритмов, которые «знает» сам сервер, и выбирает наиболее надежный алгоритм, после чего сообщает клиенту, какой алгоритм использовать
3) Сервер отправляет клиенту свой цифровой сертификат, подписанный удостоверяющим центром, и открытый ключ сервера.
4) Клиент может связаться с сервером доверенного центра сертификации, который подписал сертификат сервера, и проверить, валиден ли сертификат сервера. Но может и не связываться. В операционной системе обычно уже установлены корневые сертификаты центров сертификации, с которыми сверяют подписи серверных сертификатов, например, браузеры.
5) Генерируется сеансовый ключ для защищенного соединения. Это делается следующим образом:
— Клиент генерирует случайную цифровую последовательность
— Клиент шифрует ее открытым ключом сервера и посылает результат на сервер
— Сервер расшифровывает полученную последовательность при помощи закрытого ключа
Учитывая, что алгоритм шифрования является асимметричным, расшифровать последовательность может только сервер. При использовании асимметричного шифрования используется два ключа — приватный и публичный. Публичным отправляемое сообщение шифруется, а приватным расшифровывается. Расшифровать сообщение, имея публичный, ключ нельзя.
6) Таким образом устанавливается зашифрованное соединение. Данные, передаваемые по нему, шифруются и расшифровываются до тех пор, пока соединение не будет разорвано.
Корневой сертификат
Чуть выше я упомянул корневой сертификат. Это сертификат авторизационного центра, подпись которым подтверждает, что сертификат, который подписан, является именно тем, который принадлежит соответствующему сервису. В самом сертификате обычно содержится ряд информационных полей, в которых содержится информация об имени сервера, которому выдан сертификат, и сроках действия этого сертификата. Если срок действия сертификата истек, он признается недействительным.
Запрос на подпись (CSR, Certificate Sign Request)
Для получения подписанного серверного сертификата необходимо сгенерировать запрос на подпись (CSR, Certificate Sign Request) и отправить этот запрос авторизационному центру, который вернет подписанный сертификат, устанавливаемый непосредственно на сервер, чуть ниже посмотрим, как это сделать на практике. Сначала генерируется ключ для шифрования, затем на основании этого ключа генерируется запрос на подпись, CSR-файл.
Клиентский сертификат
Клиентский сертификат может быть сгенерирован как для использования в устройствах, так и для использования пользователями. Обычно такие сертификаты используются при двусторонней верификации, когда клиент верифицирует, что сервер действительно тот, за кого себя выдает, и сервер в ответ делает то же самое. Такое взаимодействие называется двусторонней аутентификацией или mutual authentication. Двусторонняя аутентификация позволяет повысить уровень безопасности по сравнению с односторонней, а также может служить заменой аутентификации с использованием логина и пароля.
Цепочка действий по генерации сертификатов
Давайте посмотрим на практике, как происходят действия, связанные с генерацией сертификатов, с самого начала, и при этом на практике.
Первое, что делается — это генерация корневого сертификата. Корневой сертификат подписывается самим собой. А потом уже этим сертификатом будут подписываться другие сертификаты.
Таким образом мы сгенерировали сначала приватный ключ, затем запрос подписи, а затем своим ключом подписали свой же запрос и получили собственный цифровой сертификат, выданный на 10 лет. Пароль (challenge password) при генерации сертификата можно не вводить.
Приватный ключ ОБЯЗАТЕЛЬНО необходимо хранить в надежном месте, имея его можно подписать от вашего имени любой сертификат. А полученный корневой сертификат можно использовать для идентификации того, что сертификат, например, сервера подписан именно нами, а не кем-то еще. Именно такие действия выполняют авторизационные центры, когда генерируют собственные сертификаты. После создания корневого сертификата можно приступать к генерации сертификата сервера.
Просмотр информации о сертификате
Содержимое сертификата можно просмотреть таким образом:
Мы видим, кто выдал этот сертификат и когда заканчивается срок его годности.
Серверный сертификат
Для подписи сертификата для сервера нам нужно выполнить следующие действия:
1) Сгенерировать ключ
2) Сгенерировать запрос на подпись
3) Отправить CSR-файл в авторизационный центр или подписать самостоятельно
В серверный сертификат может включаться цепочка сертификатов, которыми подписан сертификат сервера, но ее можно также хранить в отдельном файле. В принципе, выглядит всё примерно так же, как и при генерации корневого сертификата
Таким образом сертификат сервера подписан и мы будем знать, какой организацией выдан этот сертификат. После подписи готовый сертификат можно использовать по назначению, например, установить на веб-сервер.
Установка SSL/TLS-сертификата на сервер с nginx
Для установки SSL/TLS-сертификата на веб-сервер nginx надо выполнить несколько простых шагов:
2) Прописать необходимые настройки в конфигурационный файл для хоста. Вот как это примерно должно выглядеть (это просто пример):
3) Перезапустить nginx
4) Зайти браузером на 443 порт сервера — https://www.mycompany.com и проверить его работоспособность.
Установка SSL/TLS-сертификата на сервер с Apache
Установка SSL/TLS-сертификата на Apache выглядит примерно так же.
1) Скопировать файлы ключа и сертификата на сервер в соответствующие директории
2) Включить модуль ssl для Apache командой «a2enmod ssl», если он еще не включен
3) Создать виртуальный хост, который будет слушать 443 порт. Конфиг будет выглядеть примерно так:
При этом надо сделать еще кое-что. Найти в файле httpd.conf, или apache2.conf, или ports.conf, в зависимости от системы, такой участок конфига:
Если такого условия нет, его надо добавить в конфиг. И еще одно: Надо добавить строку
Эта строка может находиться в файле httpd.conf, apache2.conf или ports.conf
4) Перезапустить веб-сервер Apache
Создание клиентского сертификата
Клиентский сертификат создается примерно так же, как серверный.
Если необходим клиентский сертификат в формате PKCS12, создаем его:
Теперь можно использовать клиентский сертификат для работы с нашим сервером.
Настройка nginx на использование клиентских сертификатов
Чаще всего, как я уже сказал, используется односторонняя аутентификация, обычно проверяется только сертификат сервера. Давайте посмотрим, как заставить веб-сервер nginx проверять клиентский сертификат. Необходимо в секцию server добавить опции для работы с клиентскими сертификатами:
После этого надо перезагрузить настройки или сервер целиком и можно проверять работу.
Настройка Apache на использование клиентских сертификатов
Apache настраивается также через добавление дополнительных опций в секцию виртуального хоста:
Как видите, опции примерно такие же, как и для nginx, поскольку процесс проверки организован единообразно.
«Прослушка» информации о сертификате при помощи openssl
Для проверки взаимодействия сервера с клиентскими сертификатами можно проверить, устанавливается ли соединение с использованием TLS/SSL.
На стороне сервера запускаем прослушку порта при помощи openssl:
На стороне клиента обращаемся к серверу, например, culr’ом:
В консоли со стороны сервера можно наблюдать процесс обмена информацией между сервером и клиентом.
Со стороны сервера ошибка выглядит так:
Со стороны клиента так:
Добавим с клиентской стороны сертификат и доменное имя (можно для проверки вписать в файл /etc/hosts имя хоста для адреса 127.0.0.1):
Теперь соединение пройдет успешно и можно устанавливать серверный сертификат на веб-сервер, клиентский отдать клиенту, и работать с ними.
Безопасность
При использовании SSL/TLS одним из основных методов является метод MITM (Man In The Middle), «человек посередине». Этот метод основывается на использовании серверного сертификата и ключа на каком-то узле, который будет прослушивать трафик и расшифровывать информацию, которой обмениваются сервер и клиент. Для организации прослушивания можно использовать, например, программу sslsniff. Поэтому корневой сертификат и ключ обычно желательно хранить на машине, которая не подключена к сети, для подписания приносить запросы на подпись на флэшке, подписывать и так же уносить. И, естественно, делать резервные копии.
В общих чертах именно так и используются цифровые сертификаты и протоколы TLS и SSL. Если есть вопросы/дополнения, пишите в комментарии.