Автоматизация получения SSL сертификатов – Зарисовки сисадмина

Что дальше?

Итак, после того, как сертификат получен, сервер передает данные сеансового ключа – это то, с помощью чего дальше будет осуществляться шифрование. Если сервер считает, что нужно аутентифицировать клиента (например, доступ открыт только определенному кругу лиц), он может спросить: клиент, кто ты? И тогда клиенту надо будет послать свой сертификат. После получения сообщения

ServerHelloDone

клиент понимает, что пора проверять сертификаты и работать с ключами.

Всё, о чем мы говорили, до TLS 1.3 идет по открытому каналу, и все эти штуки может видеть кто угодно. С этим связаны несколько интересных атак, о которых вы можете почитать сами.Во второй серии части статьи мы узнаем, как клиент проверяет сертификат.

Вторая часть: Введение в TLS для п̶р̶а̶к̶т̶и̶к̶о̶в̶ Патриков (часть 2)

Что такое tls и зачем он патрику

TLS (Transport Layer Security) – это протокол защиты транспортного уровня. Он нужен для того, чтобы никто не мог вас «прослушать» и узнать какую-то важную информацию (чаще всего пароли, если говорить о работе в сети). А еще для того, чтобы защититься от подделывания и модификации трафика в процессе передачи. Именно в этих двух вещах состоит назначение TLS.

Для наглядности давайте рассматривать TLS handshake как звонок Патрика Губке Бобу. Во время звонка кто-то может подслушать разговор (стоя рядом с Патриком либо включившись в середине линии), и вообще на другом конце может быть не Губка Боб – все эти проблемы актуальны. И чтобы их порешать, Патрик хочет использовать TLS.

Вкратце, верхнеуровневый handshake выглядит так:

Патрик: Хочу использововать TLS, шифры-версии такие-то.Губка Боб: Ок, давай использовать шифры-версии такие-то.

Caa rr

Есть такая проблема, что люди, которым все верят, иногда не очень хорошие. Одна из причин того, что Symantec стал частью DigiCert, состоит в том, что он (Symantec) выписывал сертификаты без запроса от владельцев домена. Так делать нельзя, обидно было всем, но больше всех самому Symantec, потому что пришлось продать свой бизнес.

Для того, чтобы сервер меньше зависел от таких недобросовестных товарищей, есть такая штука как CAA RR – запись в DNS, где написано, кому владелец разрешает выписывать сертификаты для своего домена. Эта функция есть и в Plesk, она пока используется мало, примерно как DNSSec, – но тем не менее.

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

Также CAA RR с того момента, как мы делали их поддержку в Plesk, расширились указанием методов валидации (то есть, можно также указать здесь, каким методом ты валидируешь, что этот домен твой) и Account URI (Uniform Resource Identifier). Популярный среди пользователей Plesk Let’s Encrypt уже всё это поддерживает (молодец!).

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

Connect: ftp

Здесь мало что можно сказать. Основная проблема – SNI (это когда на одном IP разные домены). На уровне FTP имя домена не передается. В эксплицитном варианте работать не может, потому что некуда его писать. Существует несколько вариантов решения — одни предлагают так, другие так, общее решение пока не принято, стандарта нет.

Кратко: поддержка TLS для FTP в каком-то виде есть (FTPS, SFTP — аналог FTP, реализованный через SSH), но некоторые аспекты не охвачены в силу технических ограничений самого FTP.

Connect: mail

Многие клиенты считают, что на 587-м порту должен быть TLS, но здесь тоже есть нюансы: кто-то ожидает TLS по умолчанию, а кто-то ждет явного запроса

STARTTLS

от клиента. Из-за этого в разных сочетаниях mail-сервера и mail-клиента иногда возникают нежелательные эффекты. Например, клиент заходит на 587 порт, ожидая, что там будет TLS, в то же время сервер ждет, что клиент сам явно запросит

STARTTLS

. Ничего не получив, клиент откатывается на 25-й порт. В итоге – молчаливое переключение на небезопасное соединение по SMTP. При тестировании и разработке стоит помнить о таких эффектах сочетаний клиента и сервера. В Autodiscover есть разные возможности указать про TLS: как оно должно быть, что ожидается и что делать. Многие mail-клиенты понимают эти вещи.

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

Dns-challenge

Кроме ACME, есть еще DNS-challenge. Например, тебе говорят: заведи в своей DNS-зоне txt-запись, положи в нее данные. Есть и другие способы, но мало распространённые, а один вообще отменили, потому что он оказался уязвимым. Что у нас в Plesk: wildcard-сертификаты (которые могут быть выписаны только по DNS-challenge) у многих людей не работают, потому что очень часто Plesk не управляет DNS-зонами домена и экстеншн

не может автоматизировать создание записи в DNS-зоне.

Domain validation

Субъектом является домен, то есть здесь мы проверяем только его. Раньше, когда не было автоматических валидаторов, валидация происходила в основном по e-mail через сервис Whois. Это считалось достаточным основанием для того, чтобы считать, что ты владелец этого домена.

Organization validation

В поле «subject», кроме доменного имени, указывается еще и имя организации. Проверка состоит в валидации, принадлежит ли домен данной организации и работает ли там тот, кто пришел за сертификатом. Как это делается: по реестрам организации ищут, звонят, просят что-то сделать (телефон оказался верным, правильный человек ответил – значит, скорее всего всё хорошо).

Pki платформа по управлению цифровыми сертификатами

Tls handshake

Итак, теперь мы знаем, как инициировать общение с использованием TLS в разных соединениях и Патрик смог сообщить о своем желании Губке Бобу. Как только они договорились, что будут использовать TLS, производится TLS Handshake. Его результатом должна стать договорённость клиента и сервера о том, как они всё это шифруют.

Автоматизация получения ssl сертификатов – зарисовки сисадмина

add-apt-repository ppa:certbot/certbot
apt-get update

apt-cache search certbot

apt-get install certbot

chown root:www-data /var/www/site/letsencrypt
chmod 755 /var/www/site/letsencrypt

certbot certonly --config /etc/letsencrypt/cli.ini -d site.domain -d www.site.domain

Еще два слова о let’s encrypt

Важный аспект в работе с сертификатами Let’s Encrypt – лимиты. В случае сомнений (или подозрений, что они достигнуты) лучше всего пройти по ссылочке:

Иногда их обновляют. Есть неочевидные лимиты, про которые люди забывают: чаще всего, судя по обращениям в поддержку, они сталкиваются с лимитом в 100 доменных имен в сертификате. Еще у Let’s Encrypt есть staging-сервер и там лимиты больше, но такие сертификаты считаются не доверенными (non-trusted) и для браузера они аналогичны самоподписанным.

На практике с лимитом в 100 имен к нам приходят редко (при том, что у сайтов на Plesk в общей сложности 1 300 000 Let’s Encrypt сертификатов). Медиана, согласно нашей статистике, – 20 имен на сертификат. Так что, если что-то не работает, посмотрите – возможно, достигнут лимит. У Let’s Encrypt хороший error reporting, и обычно можно понять, что произошло.

Как же получить сертификат?

Вкратце – вот так:

Патрик говорит центру сертификации (Certificate Authority): мне нужен сертификат. Этот человек (или организация) проверяет, действительно ли это Патрик. Проверки могут быть самыми разными. Конечно, Патрик как клиент может и не иметь сертификата, а вот если сертификата нет у сервера, то никакого TLS не будет.

Проверяется, всё ли правильно указано в заявке сертификата, действительно ли Патрик владеет этим субъектом (subject), на который просит сертификат. Этим занимаются вышестоящие удостоверяющие центры (Certificate Authority centres) – условные люди, которым все верят. Чтобы выписать сертификат, нужно составить CSR (Certificate signing request, запрос на выдачу сертификата).

Это тоже структура, работать с которой довольно сложно, потому что сервисов, позволяющих всё задать, указать, проверить и посмотреть, мало.

Итого, мы генерируем пару публичный ключ: приватный ключ, но отдаем только публичный, а приватный прячем. Затем формируем Certificate Signing Request и подписываем своим приватным ключом. Отправляем всё это центру сертификации, и тот начинает проверку. Она может быть разной, для особо крутых сертификатов есть специальные хитрые процедуры, но мы остановимся на общем случае.

Получение сертификата: автоматизация

Теперь поговорим об автоматизированном получении DV сертификатов. Для наглядности посмотрим, как это делает наш любимый Let’s Encrypt. У него вообще хорошая документация, если кому интересно, и даже на русском.

Собственно сертификат

Вместе с ответом «Давай делать вот так» сервер посылает свой сертификат или сертификаты – их может быть много.

Что представляет собой сертификат? Это связь информации (subject) – чаще всего это имя домена или организации, — и публичного ключа (public key). То есть, сертификат говорит: «Чувак, мой public key вот такой. Сейчас мы с его помощью договоримся о сессионных ключах».

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

Таким образом, сертификат – это структура ‘Subject: Public key’ плюс подпись того ишьюера (issuer в транслитерации на русский выглядит ужасно, но самый близкий синоним здесь — не очень близкий по контексту «эмитент»), который этот сертификат выписал.

Давайте пробежимся по сертификату и посмотрим, какие с ним могут быть проблемы.

Во-первых, serial Number подразумевает уникальность только в пределах ишьюера, хотя некоторый софт считает, что он уникален во всей вселенной. К счастью, чаще всего он действительно полностью уникален.

Также в сертификате указывается, какие алгоритмы используются для шифрования и подписи: RSA или ECDSA — то есть, какую криптографию использовать для работы с этим публичным ключом. Основная разница между RSA и ECDSA в том, что математический принцип работы ECDSA основан на эллиптических кривых, а RSA — просто на натуральных числах, поэтому он медленнее и для того, чтобы его нельзя было взломать, используются огромные биты ключей (3-4 тысячи).

А для ECDSA достаточно ключа длиной в 300 бит и работает он быстрее. Поэтому многие переходят на ECDSA – handshake сам по себе тяжелый и хочется его сократить. ECDSA можно попросить при выписке сертификата, и если ишьюер его поддерживает, он вам сделает.

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

Типы сертификатов

Их три:

Шифры и версии

Как уже говорилось, на первом этапе выбирается, какая версия TLS и какие шифры будут использоваться для шифрования. Обычно шифр выглядит так:

Набор шифров есть в реестре IANA, а в протоколе TLS в бинарном виде лежит только его ID. Как видно на рисунке, здесь не просто (и не только) шифр, а еще режим его работы и другие детали, необходимые для TLS-handshake. Углубляться в подробности Патрику не нужно. Всё, что важно на данном этапе, это запомнить, что эти буквочки — это хорошо (а остальные — нехорошо):

Картинка для запоминания хороших шифров:

Если запоминать тяжело, есть хорошие сервисы, которые могут вам про это рассказать, например, сервис от Mozilla ssl-config.mozilla.org.

Тут же можно посмотреть, что где и как поддерживается – за этим ребята из Mozilla пытаются следить.

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

Также обе стороны указывают максимальную поддерживаемую версию протокола – в данном случае Патрик более продвинутый, чем Губка Боб.