Tls сертификат как получить

Что такое 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
Если увидите ошибку, значит, надо его установить.

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

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

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

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

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

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

certbot --help

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

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

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

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

Скачиваем Certbot:
Даём права на исполнение с помощью chmod
Перемещаем certbot-auto к остальным бинарным файлам, чтобы появилась возможность начинать команды с certbot
Проверяем, что получилось:

Настройка Certbot

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

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

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

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

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

Открываем расписание планировщика (сначала приведу пример для nano, затем для vim):
Добавляем новое правило в конце планировщика:
Затем сохраняем ( Ctrl + X , сохранить кнопкой Y )

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

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

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

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

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

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

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

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

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

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

-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 минут):

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

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

Настройка 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); добавить:

2 и 3 строки не обязательны, если выполнили первый пункт списка.

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

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

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

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

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

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

НЕПРАВИЛЬНО: <img src=»http://placehold.it/250×250″>
ПРАВИЛЬНО: <img src=»//placehold.it/250×250″>
ПРАВИЛЬНО: <img src=»https://placehold.it/250×250″>

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

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

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

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

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

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

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

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

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

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

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

Чтобы сделать 301 редирект на https в wordpress, достаточно найти в корне сайта wp-config.php и прописать там в любом месте (если ещё не прописано, 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 (прямая секретность означает, что если третья сторона узнает какой-либо сеансовый ключ, то она сможет получить доступ только к тем к данным, что защищены этим ключом, не более):

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

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

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

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

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

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

Эта команда создаст 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 сервера):

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/ssl/certs .

Основы HTTPS, TLS, SSL. Создание собственных X.509 сертификатов. Пример настройки TLSv1.2 в Spring Boot

Привет, Хабр! В современном мире абсолютное большинство сайтов используют HTTPS (Google даже снижает рейтинг сайтов работающих по HTTP в поисковой выдаче), а подключение к различным системам происходит по протоколу TLS/SSL. Поэтому любой разработчик рано или поздно сталкивается с этими технологиями на практике. Данная статья призвана помочь разобраться, если вы совершенно не в курсе что это такое и как оно устроено. Мы разберем как работает соединение по протоколу TLS, как выпустить собственные сертификаты и настроем TLS в Spring Boot приложении. Поехали!

Что не так с HTTP?

Проблема протокола HTTP в том, что данные передаются по сети в открытом незашифрованном виде. Это позволяет злоумышленнику слушать передаваемые пакеты и извлекать любую информацию из параметров, заголовков и тела сообщения. Для устранения уязвимости был разработан HTTPS (S в конце значит Secure) — он, хоть не является отдельным протоколом, всего лишь HTTP поверх SSL (а позже TLS), позволяет безопасно обмениваться данными. В отличие от HTTP со стандартным TCP/IP портом 80, для HTTPS используется порт 443.

Secure Sockets Layer (SSL) — это криптографический протокол, обеспечивающий безопасное общение пользователя и сервера по небезопасной сети. Располагается между транспортным уровнем и уровнем программы-клиента (FTP, HTTP и т.п.) (подробнее про уровни телекоммуникаций). Впервые был представлен публике в 1995 году, однако с 2015 года признан полностью устаревшим. На основе спецификации SSL 3.0 в 1996 был разработан TLS 1.0.

И так, что же такое TLS? Transport Layer Security — это развитие идей, заложенных в протоколе SSL. На данный момент актуальной является версия TLSv1.2, с августа 2018 активно вводится TLSv1.3, тогда как TLSv1.1, TLSv1.0, SSLv3.0, SSLv2.0, SSLv1.0 находятся в статусе deprecated. Протокол обеспечивает услуги: приватности (сокрытие передаваемой информации), целостности (обнаружение изменений), аутентификации (проверка авторства). Достигаются они за счет гибридного шифрования, то есть совместного использования ассиметричного и симметричного шифрования.

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

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

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

Что происходит на практике

Client Hello — клиент начинает общение с сервером отсылая информацию о предпочитаемой версии протокола TLS, набора поддерживаемых шифров (Cipher Spec), и случайного простого числа (client random), необходимого в дальнейшем для генерации общего ключа симметричного шифрования.

Что такое Cipher Spec? В процессе установки соединения, клиент и сервер должны договориться о: какой алгоритм использовать для обмена ключами (например, RSA — Риверт-Шамир-Адлеман, DH — Диффи-Хеллмана, ECDH — Диффи-Хеллмана на эллиптических кривых, и др.), какой алгоритм использовать для шифрования данных (AES — Advanced Encryption Standard, 3DES — Tripple Data Encryption Algorithm, и др.), какую криптографическую хэш-функцию использовать для генерации Message Authentication Code (SHA-256, SHA-384, SHA-512 — Secure Hash Algorithm с соответствующей длиной строки в битах с хэшем, и др.).

Что такое Message Authentication Code или MAC? Это хэш, сгенерированный с использованием выбранной криптографической хэш-функции и разделяемого ключа, который добавляется сзади к сообщению. Перед отправкой данных отправитель вычисляет MAC для них, а получатель перед обработкой вычисляет MAC для принятого сообщения и сравнивает его с MAC этого принятого сообщения. Предназначен для проверки целостности, то есть что сообщение не было изменено при его передаче.

Server Hello — сервер отвечает выбранной версией протокола и выбранным из предложенного набора шифром, которые будут непосредственно использоваться, своим случайным простым числом (server random) и идентификатором сессии.

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

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

Что представляет из себя сертификат? Сертификат — это открытый ключ и другая информация о его владельце, а также Электронная Цифровая Подпись (ЭЦП) доверенного центра.

Как работает ЭЦП? При создании ЭЦП хэш данных, которые подписываются, шифруется закрытым ключом, в отличие от обычного ассиметричного шифрования, где зашифровка выполняется открытым ключом. Таким образом, если вам удалось расшифровать открытым ключом хэш, и он оказался идентичен хэшу из данных, — вы можете быть уверены что: подпись была сделана именно владельцем приватного ключа, открытый ключ которого вы используете; данные, которые были подписаны, не изменились с момента подписания.

Но как удостовериться, что открытый ключ принадлежит не злоумышленнику? Существуют корневые удостоверяющие центры (Root Certificate Authority или просто CA — Certificate Authority), которым доверяют все участники обмена информацией. Если в цепочке подписания сертификата сервера есть подпись корневого CA (мы можем проверить ее с помощью открытого ключа CA), то мы можем ему доверять. При этом сертификаты (открытые ключи) корневых CA распространяются посредством включения их в операционную систему или браузер поставщиками. Также стоит отметить, что сертификат может быть подписан сертификатом, который подписан в свою очередь другим сертификатом — это цепочка подписания.

Кем подписан сертификат корневого CA? А никем, нет инстанции выше корневого CA. Сертификат (открытый ключ) в этом случае подписан собственным закрытым ключом. Такие сертификаты называют самоподписанные (sefl-signed).

Server Key Exchange — этот этап происходит не всегда, только если необходимы дополнительные данные для создания симметричного ключа при выбранном алгоритме. Например, при обмене ключами RSA этот шаг пропускается и для обмена общим ключ передается от клиента серверу зашифрованным открытым ключом сервера из его сертификата. Однако в этой статье рассмотрим более надежный алгоритм Диффи-Хеллмана. Сервер отправляет числа p (большое простое число) и g (может быть маленьким), а также рассчитанное число Y_s=g случайно выбранное сервером число mod p, где mod — это операция нахождения остатка от деления. В свою очередь клиент также рассчитывает Y_c=g случайно выбранное клиентом число mod p. После этого сервер считает Y_c случайно выбранное сервером число mod p, а клиент Y_s случайно выбранное клиентом число mod p, в результате чего у клиента и сервера получается одинаковое число. Разберем на примере:

Сервер случайно генерирует число 6, передает клиенту числа p = 17, g = 3, Y_s = 3 6 mod 17 = 15

Клиент случайно генерирует число 7 и возвращает серверу Y_c = 3 7 mod 17 = 11

Сервер считает итоговое число 11 6 mod 17= 8, и клиент 15 7 mod 17 = 8

Server Hello Done — сервер сообщает, что начальный этап установки соединения завершен

Client Key Exchange — как было уже сказано выше, когда сервер передал числа p, g, Y_s в Server Key Echange, клиент передает свое число Y_c в Client Key Exchange. Вычисленное в конце общее одинаковое число используется для создания pre-master secret — предварительного разделяемого ключа. На основании client random, server random и pre-master secret псевдослучайная функция выдает симметричный ключ и ключ вычисления MAC. Таким образом клиент и сервер имеют все необходимое для начала обмена полезной информацией.

Change Cipher Spec — клиент говорит серверу, что он готов перейти на защищенное соединение.

Finished — клиент зашифровывает симметричным ключом первое сообщение с MAC.

Change Cipher Spec — сервер проверяет сообщение Finished от клиента и отправляет в ответ свою готовность к защищенному соединению.

Finished — аналогично клиенту, сервер отправляет тестовое зашифрованное сообщение

После этого соединение считается установленным, и происходит передача полезной информации

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

Двусторонний TLS

Двусторонний TLS или Two Way TLS или mutual TLS (mTLS) означает проверку сертификата клиента. Сервер после своего сообщения Certificate посылает запрос сертификата клиента CertificateRequest. Клиент в ответ отправляет Certificate, сервер производит проверку, аналогичную проверке сертификата сервера клиентом. Далее настройка TLS происходит в описанном выше порядке.

TLSv1.3

Стоит отметить, что все выше написанное относится к TLSv1.2, которая начинает понемногу устаревать. В 2018 году была разработана новая версия 1.3 в которой: были запрещены уже ненадежные алгоритмы, ускорен процесс соединения, переработан протокол рукопожатия и др. Интернет медленно но верно обновляется до TLSv1.3, однако все еще большинство сайтов работают по протоколу TLSv1.2. Поэтому информация в этой статье остается актуальной.

Выпускаем собственные сертификаты

Теперь, когда мы разобрали теорию, самое время приступить к практике! Нам понадобятся OpenSSL и keytool (входит в поставку JDK). Для начала создадим сертификат корневого CA, которым будем подписывать запросы на подпись сертификата клиента и сервера. Сгенерируем приватный ключ RSA зашифрованный AES 256 с паролем «password» длиной 4096 бит (меньше 1024 считается ненадежным) в файл CA-private-key.key:

Нет какого-то принятого стандарта расширений для файлов, связанных с сертификатами. Мы будем использовать:

.key — для приватного ключа

.csr — для запроса на подпись сертификата

.pem — для сертификата в Privacy Enchanced Mail формате. Записывается в base64 между ——BEGIN CERTIFICATE—— и ——END CERTIFICATE——. Также существует Distinguished Encoding Rules (DER) формат, где информация хранится как binary.

p12 — для хранилища ключей с сертификатами (keystore) и хранилища доверенных сертификатов (truststore) в формате Public-Key Cryptography Standards 12.

Далее создадим новый запрос на подпись сертификата CA-certificate-signing-request.csr, передавая информацию о субъекте «CN=Certificate authority» (если не указывать ключ -subj вас попросят указать: Сountry (C), Locality (L), Organisation (O), Organisation Unit (OU), Common Name (CN), Email, Challenge password — все поля, кроме CN опциональны), приватный ключ и пароль от него:

Так как подписать сертификат другим сертификатом пока нельзя, подпишем запрос его же приватным ключом. Получившейся сертификат CA-self-signed-certificate.pem будет самоподписанным со сроком действия 1 день.

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

Подпишем запросы нашим сертификатом CA. Ключ CAcreateserial отвечает за создание файла (в данном случае CA-self-signed-certificate.srl) , в котором будет храниться серийный номер для следующего подписываемого этим сертификатом запроса. Серийный номер для текущего же сертификата сгенерируется случайно.

После этого необходимо создать хранилище ключей с сертификатами (keystore) Server-keystore.p12 для использования в нашем приложении. Положим туда сертификат сервера, приватный ключ сервера и защитим хранилище паролем «password»:

Осталось только создать хранилище доверенных сертификатов (truststore): сервер будет доверять всем клиентам, в цепочке подписания которых есть сертификат из truststore. К сожалению, для Java сертификаты в truststore должны содержать специальный object identifier, а OpenSSL пока не поддерживает их добавление. Поэтому здесь мы прибегнем к поставляемому вместе с JDK keytool:

Для удобства, все описанные выше действия упакованы в bash script.

Настройка TLS в Spring Boot приложении

Основой для нашего проекта послужит шаблон с https://start.spring.io/ с одной лишь зависимостью Spring Web. Для включения TLS указываем в application.properties:

После этого указываем Spring тип keystore, путь к нему и пароль:

Для проверки доступа создадим минимальный контроллер:

Запускаем проект. Попробуем сделать запрос с помощью curl:

Как видим, curl не доверяет сертификату сервера. Сделаем еще один запрос, указав наш CA сертификат в ключе —cacert:

На этот раз все сработало, TLS в Spring Boot работает! Мы на этом не остановимся, добавим в приложение аутентификацию клиента (указываем truststore):

Запускаем и снова пытаемся выполнить запрос:

Очевидно, что сервер закрыл соединение, так как curl не предоставил никакого сертификата. Дополним запрос клиентским сертификатом и его закрытым ключом:

Итоги

В данной статье мы разобрались как работает протокол TLS и для чего он нужен. На практике научились создавать собственные сертификаты и использовать их в Java приложении на Spring Boot. Надеюсь, представленная информация оказалась Вам полезной. Спасибо за внимание!

Получаем бесплатный SSL/TLS-сертификат от Let's Encrypt и настраиваем Nginx

Сегодня расскажу как получить бесплатный SSL/TLS-сертификат от Let’s Encrypt для своих сайтов под Nginx с помощью ACME клиента certbot (программа для получения и обновления сертификата от Let’s Encrypt).

Проект Let’s Encrypt создан для того, чтобы большая часть интернет-сайтов смогла перейти к шифрованным подключениям (HTTPS). В отличие от коммерческих центров сертификации, в данном проекте не требуется оплата. продолжить читать на Википедии

Установка зависимостей

Установим certbot и плагин для Nginx, чтобы он сам настроил нужные хосты в Nginx:

Получаем сертификат для одного домена

Вызываем certbot и передаем ему информацию для генерации сертификата:

—nginx — Заставляет плагин для Nginx перенастраивать хосты в конфигах Nginx (указывает пути до сертификатов, если нет секции для ssl, то создаст их для указанного домена)
-n — Не интерактивный режим, чаще используется для вставки в скрипты деплоя
—agree-tos — Согласие с ACME server’s Subscriber Agreement (ToS — Terms of service)
-m — Ваш Email
-d — Ваше доменное имя

Подтверждение прав на домен

Теперь вам необходимо подтвердить права на указанное доменное имя. Для этого можно создать location в конфиге Nginx:

Либо создать TXT-запись для домена, что более удобно:

Некоторые подробности можно посмотреть на ServerFault

Получаем Wildcard-сертификат

Если у вас много поддоменов, то проще получить Wildcard-сертификат (на все поддомены), эта возможность появилась у Let’s Encrypt весной 2018 года.

certonly — Получить только сертификат (но не устанавливать/применять его)
—preferred-challenges — Подтверждение прав на домен удобнее проводить через DNS
—agree-tos — Согласие с ACME server’s Subscriber Agreement (ToS — Terms of service)
-m — Ваш Email
-d — Ваше доменное имя с префиксом «*.»
-d — Сразу следом указываем каноническое имя домена, если вы им пользуетесь
—manual — Получить сертификат вручную (без помощи плагина для nginx)
—server — Для Wildcard надо указать endpoint (возможные можно посмотреть тут)

Во время запуска этой команды добавьте по запросу две TXT-записи к своему домену, например:

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

Посмотреть список полученных сертификатов

После ввода команды:

можно посмотреть список полученных сертификатов и срок их инвалидации

Проверка сертификатов домена

Если в ответ получили:

То может помочь установка ssl в секции listen:

Как получить TLS-сертификат безопасности на портале “Госуслуги”

Современные сайты используют протокол HTTPS для предоставления безопасного доступа. Это обеспечивает шифрование чувствительной к потере или передаче сторонним лицам информации: паролей, данных банковских карт и т.д. HTTPS в свою очередь использует протокол TLS (развитие SSL) для процессов аутентификации и подтверждения целостности данных. При этом на стороне защищённого ресурса должен быть установлен TLS-сертификат, выпущенный авторизованным центром сертификации, например, Let’s Encrypt.

Зачем нужен сертификат для TrueConf Server?

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

Однако бывают ситуации, когда срок действия сертификата закончился и продлить его нет возможности, или его отозвал выдавший зарубежный центр. В этом случае вы можете бесплатно заказать отечественный сертификат на государственном портале “Госуслуги”. После обращения в течение 5 дней запрос будет рассмотрен и вы получите сертификат от одного из национальных удостоверяющих центров (НУЦ). Для этого требуется выполнение следующих требований:

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

Поддержка со стороны браузеров

Чтобы посетитель сайта мог работать с ним по защищённому протоколу, должна быть поддержка со стороны используемого браузера. По состоянию на июнь 2022 года сертификаты от “Госуслуг” поддерживают Яндекс.Браузер и Atom. При этом признан неполный авторитет сертификатов НУЦ. Это значит, что каждый защищаемый домен должен быть внесён в публичный список, доступный на портале “Госуслуги”:

Как получить TLS-сертификат безопасности на портале “Госуслуги” 1

Рассмотрим получение TLS-сертификата и установку его на TrueConf Server более подробно.

Шаг 1. Подтвердите факт владения доменом

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

Шаг 2. Установите необходимое ПО

Для генерации ключей

Вам потребуется утилита для генерации RSA-ключей, которые будут использоваться порталом для создания сертификата. Мы рекомендуем бесплатную OpenSource-утилиту OpenSSL.

Для установки на ОС Windows вы можете использовать один из инсталляторов с официальной страницы проекта.

На ОС семейства Linux эта утилита уже может быть предустановлена. Проверить это можно с помощью команды для вывода версии пакета: