Как настроить tls соединение

Настройка TLS-соединений на сервере отчетов, работающем в собственном режиме

Основной режим служб Reporting Services использует для установки зашифрованных подключений к серверу отчетов службу HTTP SSL. Протокол TLS ранее назывался SSL. Если в локальном хранилище сертификатов на компьютере сервера отчетов установлен файл сертификата (.cer), можно привязать сертификат к резервированию URL-адреса служб отчетности, чтобы обеспечить поддержку соединений сервера отчетов по зашифрованному каналу.

Если используется режим интеграции служб Reporting Services с SharePoint, см. дополнительные сведения в документации по SharePoint. Например, руководство по включению TLS в веб-приложении SharePoint 2010.

Поскольку службы IIS также используют HTTP-службу SSL, возникает ряд важных проблем взаимодействия, которые необходимо учитывать при запуске служб IIS и служб Reporting Services на одном компьютере. Ознакомьтесь с разделом «Проблемы взаимодействия со службами IIS», где приводятся рекомендации по решению данных проблем.

Требования к сертификату сервера

Сертификат сервера должен быть установлен на компьютере (клиентские сертификаты не поддерживаются). Службы Reporting Services не содержат функций запроса, формирования, загрузки или установки сертификата. В Windows Server, начиная с версии 2012, доступна оснастка «Сертификаты», с помощью которой можно запрашивать сертификаты из доверенного центра сертификации.

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

Если службы IIS и Reporting Services работают вместе на одном компьютере, для установки сертификата на компьютер можно использовать консольное приложение «Диспетчер IIS». Оно включает возможности создания и упаковки запроса файла сертификата (CRT) для последующей обработки надежным центром сертификации. Центр сертификации создаст файл сертификата (CER) и вышлет его обратно. Установку файла сертификата в локальное хранилище можно выполнить при помощи консоли управления службами IIS. Дополнительные сведения см. в разделе Использование SSL для шифрования конфиденциальных данных на веб-узле TechNet.

Проблемы взаимодействия со службами IIS

Присутствие на одном компьютере служб IIS и служб Reporting Services оказывает значительное влияние на TLS-соединения с сервером отчетов:

Если установлены службы IIS, то должна быть постоянно запущена служба W3SVC. HTTP-служба SSL создает зависимость от служб IIS, если обнаружит, что они запущены. Это означает, что если службы IIS и Reporting Services установлены на одном компьютере и URL-адреса серверов отчетов настроены на TLS-соединения, то должна быть запущена служба W3SVC.
Удаление службы IIS может временно нарушить работу службы по привязанному к TLS-соединению URL-адресу сервера отчетов. По этой причине рекомендуется перезапустить компьютер после удаления служб IIS. Перезагрузка компьютера необходима для очистки всех сеансов TLS из кэша. В некоторых операционных системах время кэширования TLS-сеансов составляет до 10 часов, в результате чего URL-адрес https:// продолжает работать даже после удаления привязки TLS из резервирования URL-адресов в компоненте HTTP.SYS. При перезагрузке компьютера все открытые подключения, использующие канал, закрываются.

Привязка TLS к резервированию URL-адресов служб Reporting Services

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

Привязку сертификата можно выполнить при помощи программы настройки служб Reporting Services. Если сертификат установлен в хранилище локального компьютера правильно, программа настройки служб Reporting Services обнаружит его и отобразит в списке Сертификаты SSL на страницах URL-адрес веб-службы и URL-адрес веб-портала.

Настройка URL-адреса сервера отчетов для TLS

Запустите программу настройки служб Reporting Services и подключитесь к серверу отчетов.
Щелкните URL-адрес веб-службы.
Разверните список TLS/SSL-сертификатов. Reporting Services производят в локальном хранилище поиск сертификатов проверки подлинности сервера. Если сертификат установлен, но его нет в списке, то может понадобиться перезапустить службу. Это можно сделать с помощью кнопок Стоп и Пуск на странице Состояние сервера отчетов в программе настройки служб Reporting Services (верхняя страница).
Выберите сертификат.
Нажмите кнопку Применить.
Щелкните URL-адрес, чтобы проверить работоспособность.

Для тестирования URL-адреса необходима настройка базы данных сервера отчетов. Если база данных сервера отчетов еще не создана, то это необходимо сделать до начала тестирования URL-адреса.

Резервирования URL-адресов для веб-портала и веб-служб сервера отчетов настраиваются независимо. Вы также можете настроить доступ к веб-порталу через канал с TLS-шифрованием, сделав следующее.

Перейдите по URL-адресу веб-портала.
Выберите Дополнительно.
В разделе Несколько HTTPS-удостоверений для выбранного сейчас компонента Reporting Services выберите Добавить.
Выберите сертификат, а затем щелкните ОК и Применить.
Проверьте URL-адрес.

Хранение привязок к сертификату

Привязки к сертификату хранятся в файле HTTP.SYS. Представление определенных пользователем привязок также сохраняется в разделе URLReservations файла RSReportServer.config. Настройки в файле конфигурации являются только представлением фактических значений, указанных в другом месте. Изменять значения непосредственно в файле конфигурации нельзя. Параметры настройки появятся в файле только в результате использования программы настройки служб Reporting Services или поставщика инструментария управления Windows (WMI) для привязки сертификата.

Если настройка привязки выполняется при помощи TLS/SSL-сертификата в службах Reporting Services, а в дальнейшем потребуется удалить сертификат из компьютера, обеспечьте удаление привязки из служб Reporting Services перед удалением сертификата из компьютера. В противном случае будет невозможно удалить привязку при помощи программы настройки служб Reporting Services или WMI и появится уведомление об ошибке «Недопустимый параметр». Если сертификат уже удален из компьютера, можно использовать средство Httpcfg.exe для удаления привязки из компонента HTTP.SYS. Дополнительные сведения о Httpcfg.exe см. в документации по продукту Windows.

Привязки TLS являются общими ресурсами в Microsoft Windows. Изменения, проведенные в диспетчере конфигурации служб Reporting Services или других программах наподобие диспетчера IIS, могут отразиться на работе других приложений, работающих на этом же компьютере. Рекомендуется пользоваться для изменения привязок тем же средством, которое использовалось для их создания. Например, если привязки TLS создавались с помощью Configuration Manager, рекомендуется работать с ними в той же программе в течение всего срока их службы. Если же для создания привязок использовался диспетчер IIS, рекомендуется выполнять все дальнейшие операции с этими привязками с помощью диспетчера IIS. Если службы IIS установлены на компьютере до установки служб Reporting Services, рекомендуется проверить конфигурацию TLS в IIS перед настройкой служб Reporting Services.

Установление безопасного соединения с TLS¶

Fabric поддерживает защищенную связь между узлами через TLS. TLS-соединение может использовать как одностороннюю (только сервер), так и двустороннюю (сервер и клиент) аутентификацию.

Настройка TLS для пир-узлов¶

Пир-узел является и TLS-сервером, и TLS-клиентов. Первым он является, когда другой узел, приложение или CLI устанавливает с ним соединение, а последним — когда он сам устанавливает это соединение с другим пиром или ордерером.

Чтобы включить TLS на пир-узле, необходимо установить следующие параметры конфигурации:

peer.tls.enabled = true
peer.tls.cert.file = полный путь к файлу, содержащему серверный сертификат
peer.tls.key.file = полный путь к файлу, содержащему серверный приватный ключ
peer.tls.rootcert.file = полный путь к файлу, содержащему цепочку сертификатов CA, выдавшего серверный сертификат

По умолчанию, если TLS включен на узле, то аутентификация клиентов выключена. Это означает, что пир-узел не будет проверять сертификаты клиентов (другого пира, приложения или CLI) во время TLS-рукопожатия. Чтобы включить аутентификацию клиентов, установите параметр peer.tls.clientAuthRequired на true , и peer.tls.clientRootCAs.files на файлы цепочек CA, содержащие сертификаты CA, выдающие TLS-сертификаты клиентам вашей организации.

По умолчанию, узел будет использовать одни и те же сертификат и ключ в роли сервера и в роли клиента. Чтобы в роли клиента использовать другую пару сертификат+ключ, используйте параметры peer.tls.clientCert.file и peer.tls.clientKey.file .

TLS может также быть настроен через следующие переменные окружения:

CORE_PEER_TLS_ENABLED = true
CORE_PEER_TLS_CERT_FILE = полный путь к серверному сертификату
CORE_PEER_TLS_KEY_FILE = полный путь к серверному приватному ключу
CORE_PEER_TLS_ROOTCERT_FILE = полный путь к файлу с цепочкой CA
CORE_PEER_TLS_CLIENTAUTHREQUIRED = true
CORE_PEER_TLS_CLIENTROOTCAS_FILES = полный путь к файлу с цепочкой CA клиентов
CORE_PEER_TLS_CLIENTCERT_FILE = полный путь к клиентскому сертификату
CORE_PEER_TLS_CLIENTKEY_FILE = полный путь к клиентскому приватному ключу

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

Когда пир присоединяется к каналу, корневые цепочки CA сертификатов участников канала считываются пиром из конфигурационного блока и добавляются в структуру данных, содержащую корневые CA-сертификаты TLS клиентов и серверов. Так peer-to-peer и peer-to-orderer коммуникация должна сработать беcшовно.

Настройка TLS для ордерер-узлов¶

Чтобы включить TLS на ордеринг-узлах, установите следующие параметры конфигурации:

General.TLS.Enabled = true
General.TLS.PrivateKey = полный путь к файлу, содержащему серверный приватный ключ
General.TLS.Certificate = полный путь к файлу, содержащему серверный сертификат
General.TLS.RootCAs = полный путь к файлу, содержащему цепочку сертификатов CA, выдавшего серверные сертификаты

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

General.TLS.ClientAuthRequired = true
General.TLS.ClientRootCAs = полный путь к файлу, содержащему цепочку CA, выдавшего файлы клиентам

TLS может также быть настроен через следующие переменные окружения:

ORDERER_GENERAL_TLS_ENABLED = true
ORDERER_GENERAL_TLS_PRIVATEKEY = полный путь к файлу, содержащему серверный приватный ключ
ORDERER_GENERAL_TLS_CERTIFICATE = полный путь к файлу, содержащему серверный сертификат
ORDERER_GENERAL_TLS_ROOTCAS = полный путь к файлу, содержащему цепочку сертификатов CA, выдавшего серверные сертификаты
ORDERER_GENERAL_TLS_CLIENTAUTHREQUIRED = true
ORDERER_GENERAL_TLS_CLIENTROOTCAS = полный путь к файлу, содержащему цепочку CA, выдавшего файлы клиентам

Configuring TLS for the peer CLI¶

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

CORE_PEER_TLS_ENABLED = true
CORE_PEER_TLS_ROOTCERT_FILE = полный путь к файлу, содержащему цепочку сертификатов CA, выдавшего серверные сертификаты

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

CORE_PEER_TLS_CLIENTAUTHREQUIRED = true
CORE_PEER_TLS_CLIENTCERT_FILE = полный путь к клиентскому сертификату
CORE_PEER_TLS_CLIENTKEY_FILE = полный путь к клиентскому приватному ключу

При использовании команд, подсоединяющихся к ордерер-службе, например peer channel или or peer chaincode , следующие аргументы командной строки должны быть указаны, если на ордерере включен TLS:

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

Отладка связанных с TLS проблем¶

Перед тем как начать отлаживать такие проблемы, советуется включить GRPC debug на обеих сторонах соединения для получения дополнительной информации. Для того, чтобы включить GRPC debug , установите переменную окружения FABRIC_LOGGING_SPEC так, чтобы она включала grpc=debug . Например, чтобы установить стандартный уровень логирования на INFO и уровень логирования gRPC на DEBUG , установите такую спецификацию логирования: grpc=debug:info .

Если вы видите сообщение об ошибке remote error: tls: bad certificate на стороне клиента, обычно это означает, что TLS-сервер включил аутентификацию клиента и сервер либо вообще не получил сертификата клиента, либо получил невалидный сертификат, которому он не доверяет. Проверьте, что клиент отправляет свой сертификат и что этот сертификат был подписан CA, которому доверяет пир или ордерер.

Если вы видите сообщение об ошибке remote error: tls: bad certificate в логах вашего чейнкода, проверьте, что чейнкод был собран с chaincode shim версии Fabric v1.1 или новее.

This work is licensed under a Creative Commons Attribution 4.0 International License Revision 33015615 .

Что такое SSL и TLS, как установить и настроить

Основная установка и настройка будет проходить под Debian 8 Jessie, вебсервер NGINX, в бекенде Apache или PHP-FPM.
Инструментарий: Far Manager и Putty.
Команды вводятся в консоль SSH.
Если вы авторизованы не под root , добавляйте перед консольными командами sudo

Что такое 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 в выборе версии сервера

Сначала убедимся, что certbot ещё не установлен:
certbot —help
Если увидите ошибку, значит, надо его установить.

apt-get install certbot -t jessie-backports

Если вылезла ошибка The value ‘jessie-backports’ is invalid for APT::Default-Release as such a release is not available in the sources
, нужно настроить поддержку Backports

Как настроить поддержку Backports

Пишете в консоль (добавляет дополнительный источник для пакетов):

echo "deb http://ftp.debian.org/debian jessie-backports main contrib non-free" >> /etc/apt/sources.list

Потом обновляете список пакетов:

apt-get update

и снова пробуете установить Certbot:

apt-get install certbot -t jessie-backports

Затем проверяете, как вышло

certbot --help

certbot --help

Установка Certbot в CentOS 7

Установка происходит так:

yum -y install yum-utils

yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional

yum install certbot

Если у Вас CentOS 6, воспользуйтесь универсальной инструкцией ниже.

Универсальная инструкция по установке Certbot

Скачиваем Certbot:

wget https://dl.eff.org/certbot-auto

chmod a+x certbot-auto

mv certbot-auto /usr/local/bin/certbot

certbot --help

certbot --help

Должы увидеть что-то подобное:

Настройка Certbot

Теперь, когда certbot установлен (а вы можете убедиться в этом, задав команду
certbot —help ), советую заглянуть в cron-задачи

cd /etc/cron.d

Расписание Cron для Certbot

В директории должен появиться файл certbot с примерно следующим содержанием

Самая последняя строчка — это правило cron, которое будет проверять сертификаты SSL, TLS дважды в день и обновлять устаревшие. К сожалению, он не перезагружает вебсервер, поэтому Вам нужно добавить правило && /etc/init.d/nginx reload вручную в конец строки.

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

0 */12 * * * root test -x /usr/bin/certbot && perl -e 'sleep int(rand(3600))' && certbot -q renew && /etc/init.d/nginx reload

nano

crontab -e

0 */12 * * * test -x /usr/bin/certbot && perl -e 'sleep int(rand(3600))' && certbot -q renew && /etc/init.d/nginx reload

Далее, подготовка, тестирование и установка сертификата для сайта.

Подготовка и тестирование конфигурации SSL, TLS

Перед тем, как получить сертификат SSL/TLS, хорошей практикой будет протестировать правильность настройки сервера. Дело в том, что если есть проблема, которая не даст получить или обновить сертификат: центр сертификации имеет жёсткие лимиты обращений к нему (10 в час). И если есть ошибка, которую никак не удаётся выявить, то можно очень быстро упереться в лимит. Чтобы избежать этой проблемы, можно воспользоваться Staging Environment от Let’s Encrypt.
Staging Environment — это тестовая среда, полностью имитирующая общение с центром сертификации, и выдающая недоверенные сертификаты-пустышки. Однако, она имеет повышенные лимиты обращения к ней и служит исключительно для тестирования и настройки конфигурации сервера:

Выдача и обновление сертификата на 1 домен имеет лимит 30 000 в неделю.
Ошибка валидации имеет лимит 60 раз в час.

Чтобы воспользоваться тестовой окружающей средой, достаточно для certbot использовать ключ —staging .
Например, так можно протестировать выдачу сертификата:

certbot certonly --webroot -w /var/www/example.com -d example.com -d www.example.com --email [email protected] --agree-tos --staging

Кстати, посмотреть, как происходит обновление сертификатов, но без реального обновления, просто проверить правильность конфигурации, можно командой:

certbot renew --dry-run

А обновить все сертификаты на сервере вручную можно командой

certbot renew

После перезагрузите NGINX

nginx -s reload

Установка сертификата SSL, TLS от Let’s Encrypt

Вводим команду в консоль Putty:

certbot certonly --webroot -w /var/www/example.com -d example.com -d www.example.com --email [email protected] --agree-tos

-w /var/www/example.com — путь до директории с файлами сайта
-d example.com -d www.example.com — прописываем имена доменов
—email [email protected] — ваш email, куда можно будет восстановить доступ
—agree-tos — согласие с лицензионными требованиями

Если домен в кириллице, надо получить его Punnycode (например, яндекс.рф имеет код xn--d1acpjx3f.xn--p1ai ) и пользоваться этим кодом. Сделать это можно с помощью Punycode-конвертера.

Сертификат Let

Если всё нормально, вам выдаст сообщение об успешном завершении создания сертификата

Итак, сертификат установлен в директорию /etc/letsencrypt/live//

Идём настраивать NGINX.

Настройка SSL, TLS в NGINX

Открываем конфигурационный файл вашего сайта.
Если NGINX настроен как тут, то конфигурационный файл может быть расположен тут:
/etc/nginx/vhosts/example.com.conf

Для уменьшения загрузки процессора официальная документация рекомендует

установить число рабочих процессов равным числу процессоров,
разрешить keep-alive соединения,
включить разделяемый кэш сессий,
выключить встроенный кэш сессий
и, возможно, увеличить время жизни сессии (по умолчанию 5 минут):

Изменения я буду комментировать

# Создаём отдельный server для перенаправления с http на https server < server_name example.com www.example.com; # Можно указать любые домены и поддомены, смотря как вы настроили сертификат listen 1.2.3.4:80; #где 1.2.3.4 - айпи вашего сервера rewrite ^(.*) https://$host$1 permanent; # Редирект HTTP/1.1 301 Moved Permanently с http на https ># А это основной сервер с https server < server_name example.com www.example.com; # Копируем из верхнего сервера listen 1.2.3.4:443 ssl http2; #вместо 1.2.3.4 вставляете IP своего сервера. http2 включчает поддержку протокола http/2 ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # Сертификат ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # Ключ # Рекомендации по кешированию запросов keepalive_timeout 70; # 70 секунд держим соединение открытым keepalive_requests 150; # 150 запросов максимум на 1 соединение, после закрываем ssl_session_cache shared:SSL:10m; # Разделяемый между всеми процесами кеш сессий на 10 байт с названием SSL. 1 Мб вмещает около 4000 сессий ssl_session_timeout 10m; # 10 минут - максимальное время жизни сессии # А строки ниже - для усиления безопасности соединения ssl_prefer_server_ciphers on; # Указывает, чтобы при использовании протоколов SSLv3 и TLS серверные шифры были более приоритетны, чем клиентские ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA; # Типы шифров ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Разрешённые типы протоколов . # Тут остальные правила NGINX

Сохранили, проверили, перезагрузили

nginx -t && service nginx reload

Настройка SSL, TLS на WordPress

Для примера, возьмём сайт на WordPress и настроим на нём SSL/TLS, сделаем его доступным по HTTPS.
Нужно будет обязательно пройтись по списку и внести соответствующие изменения:

Переписать в базе данных все ссылки, заменив http://example.com на https://example.com
Для этого, вы можете воспользоваться WP-Cli или специальной утилитой Seach Replace DB
Переписать в файлах темы все ссылки, заменив http:// на https:// или //
Отредактировать wp-config.php , а именно, перед define('WP_DEBUG', false); добавить:

// example.com меняем на своё имя домена define('WP_HOME', 'https://example.com'); define('WP_SITEURL', 'https://example.com'); // Принудительная авторизация в админке по защищённому протоколу define('FORCE_SSL_ADMIN', true); // Чтобы предотвратить бесконечный редирект с http на https if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false) $_SERVER['HTTPS']='on';

Как перенести сайт с HTTP на HTTPS правильно

Я считаю, что можно не ждать склейки http и https, и сразу настроить редирект на https, они всё равно склеятся, но далее приведу рекомендации, которые дают специалисты по поисковому продвижению

Если вы переводите существующий проиндексированный сайт на SSL, то сначала рекомендуется, чтобы Yandex склеил http и https версии сайта. Для этого, вы должны сначала настроить сайт так, чтобы он был доступен и по http, и по https верно, а затем прописать в robots.txt нужный адрес в директиве Hosts.

Не забудьте добавить новую версию сайта на HTTPS в Яндекс Вебмастер и Google Webmasters.

Вот, скажем, пример файла robots.txt для сайта sheensay.ru

User-agent: Yandex Disallow: Host: https://sheensay.ru User-agent: * Disallow: Sitemap: https://sheensay.ru/sitemap.xml

Далее, рекомендуется, чтобы все внутренние ссылки были относительными либо начинались строго с протокола https:// . У всех внешних javascript скриптов, ссылок, вставленных картинок, аудио- и видеоплееров, и других внешних объектов протоколы http:// заменяются на абсолютные https:// или относительные // .
Приведу пример:

НЕПРАВИЛЬНО:
ПРАВИЛЬНО:
ПРАВИЛЬНО:

Далее, проверяем секцию head, ищем теги и , и следим, чтобы адреса в них начинались с https://
Таким образом, вы добьётесь более быстрой склейки разных версий сайта в одну.

Далее, дождавшись, когда Яндекс всё склеит правильно, можно настроить 301 редирект с http на https

Как настроить 301 редирект с HTTP на HTTPS

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

301 редирект с HTTP на HTTPS в NGINX

Тут нужно указать 2 блока server , для http (там мы настраиваем редирект) и для https

server < server_name example.com www.example.com; # Можно указать любые домены и поддомены, смотря как вы настроили сертификат listen 1.2.3.4:80; #где 1.2.3.4 - айпи вашего сервера rewrite ^(.*) https://$host$1 permanent; # Редирект HTTP/1.1 301 Moved Permanently с http на https >server

301 редирект с HTTP на HTTPS в .htaccess (Apache)

Если у Вас основной сервер Apache, в его конфигурационном файле ( apache.conf ) или в .htaccess в корне сайта прописываем

RewriteEngine On RewriteBase / RewriteCond % !=1 [NC] RewriteRule ^(.*) https://%/$1 [L,R=301]

RewriteEngine On RewriteCond % !^443$ RewriteRule .* https://%% [R=301,L]

Эта конструкция отлавливает все запросы к портам, отличным от 443 (а именно на 443 порту сидит SSL), и редиректит на нужную версию сайта с HTTPS.

Если у вас во фронтенде NGINX, то редирект в .htaccess может и не сработать. В таком случае, рекомендую воспользоваться редиректом в WordPress.

301 редирект с HTTP на HTTPS в WordPress

Чтобы сделать 301 редирект на https в wordpress, достаточно найти в корне сайта wp-config.php и прописать там в любом месте (если ещё не прописано, example.com меняете на свой домен):

define( 'WP_HOME', 'https://example.com' ); define( 'WP_SITEURL', 'https://example.com' );

В большинстве ситуаций этого достаточно.

Если доступа к wp-config.php нет, то есть ещё один вариант.
Код ниже используете в MU Plugin, также можно создать обычный плагин (требует активации) или вставить в functions.php рабочей темы:

Настройка HTTPS в админке WordPress

Перед включением кода убедитесь, что сайту уже присвоен HTTPS: (Настройки — Общие)

Как проверить правильность работы SSL, TLS

В интернете можно найти множество сервисов, которые помогут определить, как правильно вы установили SSL и настроили сайт под него.
Один из таких сервисов: ssllabs.com

Рекомендую проверять правильность установки и настройки сертификата SSL/TLS с помощью ssllabs.com

Вы просто вводите адрес сайта и через несколько минут получаете результаты теста. Например, вот высший результат тестирования ( A+ ) по домену https://sheensay.ru

Результат тестирования SSL/TLS

Как усилить безопасность SSL, TLS

Бывает так, что сертификат установлен, а тестирование ssllabs показывает не лучший грейд безопасности.
Чтобы добиться заветного A+ , нужно правильно настроить NGINX.
Для этого, сначала запускаем следующую команду, которая сгенерирует нужные ключи для Forward Secrecy (прямая секретность означает, что если третья сторона узнает какой-либо сеансовый ключ, то она сможет получить доступ только к тем к данным, что защищены этим ключом, не более):

openssl dhparam -out /etc/letsencrypt/dhparam.pem 2048

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

server < server_name sheensay.ru www.sheensay.ru; ssl_session_cache shared:SSL:10m; # Разделяемый между всеми процесами кеш сессий на 10 байт с названием SSL. 1 Мб вмещает около 4000 сессий ssl_session_timeout 10m; # 10 минут - максимальное время жизни сессии add_header Strict-Transport-Security "max-age=31536000;"; # Заголовок, принудительно включающий защищённое соединение, минуя небезопасный HTTP # Заголовок Content Security Policy - отвечает за то, что считать безопасным подгружаемым контентом на странице add_header Content-Security-Policy-Report-Only "default-src https:; script-src https: 'unsafe-eval' 'unsafe-inline' *.yandex.ru; style-src https: 'unsafe-inline' fonts.googleapis.com; img-src https: data:; font-src https: data: fonts.googleapis.com; child-src https: www.youtube.com; report-uri /csp-report"; ssl_stapling on; ssl_stapling_verify on; ssl_trusted_certificate /etc/letsencrypt/live/sheensay.ru/chain.pem; # домен меняете на свой resolver 8.8.4.4 8.8.8.8 valid=300s; resolver_timeout 10s; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:DES-CBC3-SHA:!RC4:!aNULL:!eNULL:!MD5:!EXPORT:!EXP:!LOW:!SEED:!CAMELLIA:!IDEA:!PSK:!SRP:!SSLv:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA'; ssl_prefer_server_ciphers on; ### Чтобы у нас заработал Forward Secrecy, сгенерируем ключ командой ниже: ## openssl dhparam -out /etc/letsencrypt/dhparam.pem 2048 ### После генерации расскомментируем строку ниже ssl_dhparam /etc/letsencrypt/dhparam.pem; ### Дальше другие настройки сервера ### .

После всех манипуляций, не забудьте перезагрузить NGINX

service nginx reload

Видео установки и настройки SSL сертификата в хостинге Beget

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

Как установить SSL/TLS, если на сервере несколько сайтов

Обычно, проблемы возникают, когда на сервере уже есть 1 сайт на HTTPS, и на этот сервер нужно перенести другой сайт.
Либо, ещё более патовая ситуация: нужно перенести сайт на HTTP и сделать его доступным по HTTPS. Проблема будет возникать из-за того, что на сервере на порту 443 уже есть сайт с сертификатом SSL/TLS, и обращения будут идти на него, и certbot не сможет прописать сертификат сайту, а сайты по HTTP будут недоступны.
Для решения этой проблемы можно сгенерировать временный самоподписанный сертификат:

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes

Эта команда создаст 2 файла в директории, из которой вызывается команда (обычно это /root ):

cert.pem — это сертификат SSL/TLS;
key.pem — это ключ к сертификату.

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

Ещё пример, когда такое решение пригодится — на CloudFlare, настроенном на Flexible SSL, плагин Broken Link Checker при сканировании выдаёт ошибки доступа к изображениям Connection Failed . И тут тоже помогут самоподписанные сертификаты на 443 порту сайта.

Ключи прописываете в конфигурации сервера (пример есть ниже). Далее:

Если сайт нужен по HTTP, просто делаете редирект с HTTPS на HTTP, по аналогии с редиректом на HTTPS, только наоборот (пример далее);
Если сайт нужен по HTTPS, делаете сайт доступным по HTTP, затем получаете сертификат с помощью certbot, а дальше всё как по инструкции выше — редирект на HTTPS, прописывание сертификатов, настройка URL, и так далее.

Пример, как сделать редирект с HTTPS на HTTP в NGINX

Допустим, самоподписанные сертификаты сгенерированы командой выше и располагаются в каталоге /root/ . Тогда, чтобы настроить редирект с HTTPS на HTTP для нового сайта example.com , мы можем использовать следующую конфигурацию ( example.com заменяем на свой домен, 1.2.3.4 — на свой IP сервера):

server < server_name example.com www.example.com; listen 1.2.3.4:443 ssl; ### Вместо 1.2.3.4 нужно подставить IP сервера ssl_certificate /root/cert.pem; # Путь к самоподписанному сгенерированному сертификату ssl_certificate_key /root/key.pem; # Путь к ключу самоподписанного сертификата rewrite ^(.*) http://$host$1 permanent; >server

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 это делается так:

update-ca-certificates --fresh

Эта команда обновляет символические ссылки сертификатов в /etc/ssl/certs .

Если это не помогло, то нужно будет обновить пакеты системы.

Сначала убедитесь, что пакеты безопасности в /etc/apt/sources.list выглядят примерно так:

deb http://security.debian.org/debian-security stretch/updates main contrib non-free deb-src http://security.debian.org/debian-security stretch/updates main contrib non-free

Если всё в порядке, обновляем пакеты

apt update && apt upgrade -y

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

apt-cache policy ca-certificates

Простая настройка взаимной проверки подлинности клиента и сервера с использованием TLS

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

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

Мы рассмотрим следующие вопросы:

Запуск сервера
Отправка приветствия серверу (без шифрования)
Включение HTTPS на сервере (односторонний TLS)
Аутентификация клиента (двусторонний TLS)
Установление двустороннего TLS-соединения с использованием доверенного удостоверяющего центра.
Автоматизация различных подходов к аутентификации

Идентификационные данные объекта: хранилище KeyStore, хранящее пару ключей — закрытый (private) и открытый (public).
TrustStore: хранилище KeyStore, содержащее один или большее количество сертификатов (открытых ключей). Это хранилище содержит список доверенных сертификатов. Оно хранит данные о приложениях, которым доверяет наше приложение.
Односторонняя аутентификация (односторонний TLS, односторонний SSL): HTTPS-соединение, при установке которого клиент проверяет сертификат противоположной стороны.
Двусторонняя аутентификация (двусторонний TLS, двусторонний SSL, взаимная аутентификация): HTTPS-соединение, при установке которого клиент и противоположная сторона проверяют сертификаты друг друга.

Работа с keytool
Работа с openssl
Настройка HTTP-клиентов
Обзор свойств Spring-приложения

1. Запуск сервера

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

Java 11
Maven 3.5.0
Eclipse, Intellij IDEA (или любой другой текстовой редактор вроде VIM)
Доступ к терминалу
Копия этого проекта

В данном проекте содержится Maven-обёртка, поэтому запустить его можно и не устанавливая Maven. Тут будут приведены сведения и о стандартных командах, рассчитанных на mvn, и о командах, ориентированных на использование Maven-обёртки.

Если вы хотите запустить этот проект с использованием Java 8 — вы можете переключиться на более старую его версию с использованием нижеприведённой команды.

git checkout tags/java-8-compatible

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

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

cd server/ && mvn spring-boot:run

Вот команда, рассчитанная на Maven-обёртку:

cd server-with-spring-boot/ && ./../mvnw spring-boot:run

2. Отправка приветствия серверу (без шифрования)

Сейчас сервер работает на порте, используемом по умолчанию (8080) без шифрования. С помощью следующей команды, задействующей curl , можно обратиться к конечной точке hello :

curl -i -XGET http://localhost:8080/api/hello

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

HTTP/1.1 200 Content-Type: text/plain;charset=UTF-8 Content-Length: 5 Date: Sun, 11 Nov 2018 14:21:50 GMT Hello

Обратиться к серверу можно и с использованием клиента, код которого находится в директории client . Клиент зависит от других компонентов проекта. Поэтому, прежде чем его запускать, нужно выполнить в корневой директории проекта команду mvn install или ./mvnw install .

В клиенте реализован интеграционный тест, основанный на Cucumber. Его можно запустить, обратившись к классу ClientRunnerIT из IDE, или выполнив в корневой директории следующую команду:

cd client/ && mvn exec:java

При использовании Maven-обёртки это будет такая команда:

cd client/ && ./../mvnw exec:java

Тут имеется файл Hello.feature, который описывает шаги интеграционного теста. Этот файл можно найти в папке ресурсов теста клиентского проекта.

Есть и другой метод запуска и клиента, и сервера. Он представлен следующей командой, выполняемой в корневой директории проекта:

mvn clean verify

Вариант этой команды для Maven-обёртки выглядит так:

./mvnw clean verify

Клиент, по умолчанию, отправляет запросы к localhost , так как он рассчитан на то, что сервер выполняется на том же компьютере, что и он сам. Если сервер работает на другой машине — соответствующий URL можно передать клиенту при запуске, воспользовавшись следующим аргументом VM:

-Durl=http://[HOST]:[PORT]

3. Включение HTTPS на сервере (односторонний TLS)

Теперь давайте разберёмся с тем, как защитить сервер с помощью TLS. Сделать это можно, добавив соответствующие свойства в файл application.yml , хранящий настройки приложения.

Речь идёт о следующих настройках:

server: port: 8443 ssl: enabled: true

Возможно, тут у вас появится вопрос о причинах изменения номера порта сервера на 8443 . Дело в том, что tomcat-серверы, поддерживающие HTTPS, принято размещать на порте 8443. А серверы, поддерживающие HTTP — на порте 8080 . Поэтому при настройке подобного соединения можно использовать и порт 8080 , но поступать так не рекомендуется. Тут можно почитать подробности о том, какие номера портов используются в разных ситуациях.

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

IllegalArgumentException: Resource location must not be null

Причина его появления заключается в том, что серверу, для установки защищённого соединения с внешними сущностями, нужно хранилище ключей с сертификатом сервера. Сервер может предоставить более подробную информацию об этом в том случае, если воспользоваться следующими аргументами VM:

-Djavax.net.debug=SSL,keymanager,trustmanager,ssl:handshake

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

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

keytool -v -genkeypair -dname "CN=Hakan,OU=Amsterdam,O=Thunderberry,C=NL" -keystore shared-server-resources/src/main/resources/identity.jks -storepass secret -keypass secret -keyalg RSA -keysize 2048 -alias server -validity 3650 -deststoretype pkcs12 -ext KeyUsage=digitalSignature,dataEncipherment,keyEncipherment,keyAgreement -ext ExtendedKeyUsage=serverAuth,clientAuth -ext SubjectAlternativeName:c=DNS:localhost,IP:127.0.0.1

Теперь нужно сообщить серверу о том, где именно находится хранилище ключей, и указать пароли. Сделаем это, отредактировав наш файл application.yml :

server: port: 8443 ssl: enabled: true key-store: classpath:identity.jks key-password: secret key-store-password: secret

Замечательно! Только что мы настроили TLS-шифрование соединений между сервером и клиентом! Испытать сервер можно так:

curl -i --insecure -v -XGET https://localhost:8443/api/hello

Клиент можно запустить и прибегнув к классу ClientRunnerIT.

В результате можно будет увидеть следующее сообщение:

java.net.ConnectException: Connection refused (Connection refused)

Возникает такое ощущение, что клиент пытается поприветствовать сервер, а сервер ему найти не удаётся. Проблема заключается в том, что клиент пытается обратиться к серверу, работающему на порте 8080 , а сервер ждёт запросов на порте 8443 . Исправим это, внеся некоторые изменения в класс Constants . А именно — найдём эту строку:

private static final String DEFAULT_SERVER_URL = "http://localhost:8080";

И приведём её к такому виду:

private static final String DEFAULT_SERVER_URL = "https://localhost:8443";

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

javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Дело тут в том, что клиент собирается наладить обмен данными по HTTPS. Он, при выполнении процедуры рукопожатия, получает сертификат сервера, который он пока не может распознать. А это значит, что нам ещё нужно создать хранилище TrustStore. В таких хранилищах находятся доверенные сертификаты. Клиент сопоставляет то, что он получает в ходе процедуры рукопожатия, с тем, что есть в TrustStore. Если полученный им сертификат входит в список доверенных сертификатов — процедура продолжается. А прежде чем создавать TrustStore — нужно обзавестись сертификатом сервера.

Экспортировать сертификат сервера можно такой командой:

keytool -v -exportcert -file shared-server-resources/src/main/resources/server.cer -alias server -keystore shared-server-resources/src/main/resources/identity.jks -storepass secret -rfc

Теперь можно создать TrustStore для клиента и импортировать туда сертификат сервера такой командой:

keytool -v -importcert -file shared-server-resources/src/main/resources/server.cer -alias server -keystore client/src/test/resources/truststore.jks -storepass secret -noprompt

TrustStore для клиента мы создали, но сам клиент пока об этом не знает. А это значит, что клиенту надо сообщить о том, что ему следует пользоваться TrustStore, указав адрес хранилища и пароль. Клиенту надо сообщить и о том, что включена аутентификация. Всё это делается путём приведения файла application.yml клиентского приложения к такому виду:

client: ssl: one-way-authentication-enabled: true two-way-authentication-enabled: false trust-store: truststore.jks trust-store-password: secret

4. Аутентификация клиента (двусторонний TLS)

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

Приведём файл сервера application.yml к такому виду:

server: port: 8443 ssl: enabled: true key-store: classpath:identity.jks key-password: secret key-store-password: secret client-auth: need

Если после этого запустить клиент, то он выдаст следующее сообщение об ошибке:

javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate

Это указывает на то, что клиент не обладает подходящим сертификатом. Точнее — у клиента пока вообще нет сертификата. Поэтому создадим сертификат следующей командой:

keytool -v -genkeypair -dname "CN=Suleyman,OU=Altindag,O=Altindag,C=NL" -keystore client/src/test/resources/identity.jks -storepass secret -keypass secret -keyalg RSA -keysize 2048 -alias client -validity 3650 -deststoretype pkcs12 -ext KeyUsage=digitalSignature,dataEncipherment,keyEncipherment,keyAgreement -ext ExtendedKeyUsage=serverAuth,clientAuth

Нам ещё нужно создать TrustStore для сервера. Но, прежде чем создавать это хранилище, нужно иметь сертификат клиента. Экспортировать его можно так:

keytool -v -exportcert -file client/src/test/resources/client.cer -alias client -keystore client/src/test/resources/identity.jks -storepass secret -rfc

Теперь создадим TrustStore сервера, в котором будет сертификат клиента:

keytool -v -importcert -file client/src/test/resources/client.cer -alias client -keystore shared-server-resources/src/main/resources/truststore.jks -storepass secret -noprompt

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

Приведём файл application.yml клиента к такому виду:

client: ssl: one-way-authentication-enabled: false two-way-authentication-enabled: true key-store: identity.jks key-password: secret key-store-password: secret trust-store: truststore.jks trust-store-password: secret

Сервер тоже не знает о только что созданном для него TrustStore. Приведём его файл application.yml к такому виду:

server: port: 8443 ssl: enabled: true key-store: classpath:identity.jks key-password: secret key-store-password: secret trust-store: classpath:truststore.jks trust-store-password: secret client-auth: need

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

Примите поздравления! Только что вы настроили двусторонний TLS!

5. Установление двустороннего TLS-соединения с использованием доверенного удостоверяющего центра

Есть и другой способ организации двусторонней аутентификации. Он основан на использовании доверенного удостоверяющего центра. У такого подхода есть сильные и слабые стороны.

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

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

1. Создание удостоверяющего центра

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

keytool -v -genkeypair -dname "CN=Root-CA,OU=Certificate Authority,O=Thunderberry,C=NL" -keystore root-ca/identity.jks -storepass secret -keypass secret -keyalg RSA -keysize 2048 -alias root-ca -validity 3650 -deststoretype pkcs12 -ext KeyUsage=digitalSignature,keyCertSign -ext BasicConstraints=ca:true,PathLen:3

Ещё можно воспользоваться существующим удостоверяющим центром.

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

Для того чтобы подписать сертификат — нужен .csr-файл (Certificate Signing Request, файл запроса на подпись сертификата). Создать его можно с помощью особой команды.

Вот её вариант для сервера:

keytool -v -certreq -file shared-server-resources/src/main/resources/server.csr -keystore shared-server-resources/src/main/resources/identity.jks -alias server -keypass secret -storepass secret -keyalg rsa

Вот — эта команда для клиента:

keytool -v -certreq -file client/src/test/resources/client.csr -keystore client/src/test/resources/identity.jks -alias client -keypass secret -storepass secret -keyalg rsa

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

3. Подписание сертификата с помощью запроса на подпись сертификата

Вот соответствующая команда для клиента:

keytool -v -gencert -infile client/src/test/resources/client.csr -outfile client/src/test/resources/client-signed.cer -keystore root-ca/identity.jks -storepass secret -alias root-ca -ext KeyUsage=digitalSignature,dataEncipherment,keyEncipherment,keyAgreement -ext ExtendedKeyUsage=serverAuth,clientAuth

Вот команда для сервера:

keytool -v -gencert -infile shared-server-resources/src/main/resources/server.csr -outfile shared-server-resources/src/main/resources/server-signed.cer -keystore root-ca/identity.jks -storepass secret -alias root-ca -ext KeyUsage=digitalSignature,dataEncipherment,keyEncipherment,keyAgreement -ext ExtendedKeyUsage=serverAuth,clientAuth -ext SubjectAlternativeName:c=DNS:localhost,IP:127.0.0.1

4. Замена неподписанного сертификата подписанным

В хранилище идентификационных данных сервера и клиента всё ещё хранится неподписанный сертификат. Сейчас можно заменить его на подписанный. У инструмента keytool есть одна не вполне понятная особенность. А именно — он не позволяет напрямую импортировать в хранилище подписанный сертификат. Если попытаться это сделать — будет выведено сообщение об ошибке. Сертификат, подписанный удостоверяющим центром, должен быть представлен в файле identity.jks .

Экспортируем подписанный сертификат:

keytool -v -exportcert -file root-ca/root-ca.pem -alias root-ca -keystore root-ca/identity.jks -storepass secret -rfc

Выполним на клиенте следующие команды:

keytool -v -importcert -file root-ca/root-ca.pem -alias root-ca -keystore client/src/test/resources/identity.jks -storepass secret -noprompt keytool -v -importcert -file client/src/test/resources/client-signed.cer -alias client -keystore client/src/test/resources/identity.jks -storepass secret keytool -v -delete -alias root-ca -keystore client/src/test/resources/identity.jks -storepass secret

На сервере выполним такие команды:

keytool -v -importcert -file root-ca/root-ca.pem -alias root-ca -keystore shared-server-resources/src/main/resources/identity.jks -storepass secret -noprompt keytool -v -importcert -file shared-server-resources/src/main/resources/server-signed.cer -alias server -keystore shared-server-resources/src/main/resources/identity.jks -storepass secret keytool -v -delete -alias root-ca -keystore shared-server-resources/src/main/resources/identity.jks -storepass secret

5. Организация взаимодействия клиента и сервера, основанного исключительно на доверии к удостоверяющему центру

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

Сделаем это, выполнив на клиенте следующую команду:

keytool -v -importcert -file root-ca/root-ca.pem -alias root-ca -keystore client/src/test/resources/truststore.jks -storepass secret -noprompt

На сервере выполним такую команду:

keytool -v -importcert -file root-ca/root-ca.pem -alias root-ca -keystore shared-server-resources/src/main/resources/truststore.jks -storepass secret -noprompt

В хранилищах TrustStore всё ещё хранятся собственные сертификаты клиента и сервера. Эти сертификаты нужно удалить.

Выполним на клиенте такую команду:

keytool -v -delete -alias server -keystore client/src/test/resources/truststore.jks -storepass secret

Вот — команда для сервера:

keytool -v -delete -alias client -keystore shared-server-resources/src/main/resources/truststore.jks -storepass secret

Если снова запустить клиент — можно видеть успешное прохождение теста. А это значит, что клиент и сервер успешно обмениваются данными, используя сертификаты, подписанные удостоверяющим центром.

6. Автоматизация различных подходов к аутентификации

Всё, о чём мы говорили выше, можно автоматизировать с помощью скриптов, которые находятся в папке script рассматриваемого нами проекта. Для запуска скриптов можете воспользоваться следующими командами:

./configure-one-way-authentication — настройка односторонней аутентификации.
./configure-two-way-authentication-by-trusting-each-other my-company-name — настройка двусторонней аутентификации.
./configure-two-way-authentication-by-trusting-root-ca my-company-name — настройка двусторонней аутентификации с использованием удостоверяющего центра.

Протестированные клиенты

Ниже приведён список протестированных клиентов. Настройки для HTTP-клиента, написанного на чистом Java, можно найти в классе ClientConfig. В директории service нашего проекта содержатся отдельные HTTP-клиенты, выполняющие демонстрационные запросы. Настройки HTTP-клиентов, основанных на Kotlin и Scala, включены в состав проекта в виде вложенных классов. Все примеры клиентов используют одну и ту же базовую конфигурацию SSL, созданную в классе SSLConfig.

Apache HttpClient → Настройки клиента | Пример запроса
Apache HttpAsyncClient → Настройки клиента | Пример запроса
Apache 5 HttpClient → Настройки клиента | Пример запроса
Apache 5 HttpAsyncClient → Настройки клиента | Пример запроса
JDK HttpClient → Настройки клиента | Пример запроса
Old JDK HttpClient → Настройки клиента и пример запроса
Netty Reactor → Настройки клиента | Пример запроса
Jetty Reactive HttpClient → Настройки клиента | Пример запроса
Spring RestTemplate → Настройки клиента | Пример запроса
Spring WebFlux WebClient Netty → Настройки клиента | Пример запроса
Spring WebFlux WebClient Jetty → Настройки клиента | Пример запроса
OkHttp → Настройки клиента | Пример запроса
Клиент Jersey → Настройки клиента | Пример запроса
Старый клиент Jersey → Настройки клиента | Пример запроса
Google HttpClient → Настройки клиента | Пример запроса
Unirest → Настройки клиента | Пример запроса
Retrofit → Настройки клиента | Пример запроса
Асинхронный Http-клиент → Настройки клиента | Пример запроса
Feign → Настройки клиента | Пример запроса
Methanol → Настройки клиента | Пример запроса
Vertx Webclient → Настройки клиента и пример запроса

Fuel → Настройки клиента и пример запроса
Http4k с Apache 4 → Настройки клиента | Пример запроса
Http4k с Async Apache 4 → Настройки клиента | Пример запроса
Http4k с Apache 5 → Настройки клиента | Пример запроса
Http4k с Async Apache 5 → Настройки клиента | Пример запроса
Http4k с Java Net → Настройки клиента | Пример запроса
Http4k с Jetty → Настройки клиента | Пример запроса
Http4k с OkHttp → Настройки клиента | Пример запроса
Kohttp → Настройки клиента и пример запроса
Ktor с движком Android → Настройки клиента | Пример запроса
Ktor с движком Apache → Настройки клиента | Пример запроса
Ktor c CIO-движком (I/O на основе корутин) → Настройки клиента | Пример запроса
Ktor с движком Okhttp → Настройки клиента | Пример запроса

Twitter Finagle → Настройки клиента | Пример запроса
Twitter Finagle Featherbed → Настройки клиента и пример запроса
HTTP-клиент Akka → Настройки клиента | Пример запроса
Dispatch Reboot → Настройки клиента и пример запроса
ScalaJ / Simplified Http Client → Настройки клиента и пример запроса
Sttp → Настройки клиента и пример запроса
Requests-Scala → Настройки клиента и пример запроса
Клиент Http4s Blaze → Настройки клиента | Пример запроса
Клиент Http4s Java Net → Настройки клиента | Пример запроса