Некоторые технические подробности центров сертификации

By | Ноябрь 30, 2014

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

Теперь время рассмотреть техническую сторону.

Технические подробности

Общие сведения

Сертификаты в X.509 PKI (Public Key Infrastructure, инфраструра открытых ключей) могут применяться в решении различных задач, наиболее важной из которых является аутентификация доменных имён. В этой системе, центрам сертификации (Certificate Authority, CA) PKI сообщество «доверяет» удостоверение того, что сторона запрашивающая сертификат действительно представляет доменные имена, перечисленные в запросе на получение сертификата.

Здесь речь идёт, по большей части, о центрах сертификации, относимым к корневым. Актуальный их перечень можно найти на сайте CA/Browser forum

Существует три основных класса проверок осуществляемых центрами сертификации, а следовательно и сертификатов, ими выдаваемых:

  • Extended Validation (расширенная проверка, EV) — центр сертификации осуществляет проверку правомерности использования заявителем доменного имени и связь с организацией (существует, документы в порядке, домен принадлежит организации, организация запросила выпуск сертификата)
  • Organization Validation (проверка организации, OV) — центр сертификации проверяет, что доменное имя действительно контролируется заявителем, а также то, что доменное имя принадлежит организации.
  • Domain Validation (проверка домена, DV) — центр сертификации проверяет, что сторона, запросившая сертификат, действительно контролирует домен, для которого сделан запрос.

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

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

Подтверждение владения доменом для класса DV

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

  • Сгенерировать запрос на сертификат PKCS#10 — CSR
  • Скопировать-Вставить CSR на странице CA
  • Доказать владение доменом посредством одного из следующих методов:
    • Разместить выданный CA объект (URI challenge) в заданное место на сервере
    • Разместить выданную CA строчку (DNS challenge) в заданный узел DNS, соответствующий подтверждаемому домену
    • Получить сообщение от CA (email challenge) на (теоретически) контролируемый администратором домена адрес электронной почты и ввести полученный код на странице CA
  • Скачать выпущенный сертификат и установить его на сервер.

Необходимо отметить, что для подтверждения по классу DV, проверки по всем указанным методам, возможно произвести в автоматическом режиме, без участия системного администратора. Этот факт поставлен во главу угла в решении нового центра сертификации Let’s Encrypt, которое строится на базе протокола ACME.

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

Для валидации того, что сервер-заявитель имеет право отправлять данные от имени некоторого домена, центр сертификации работающий по протоколу ACME требует от сервера-заявителя (называемого агентом) решение одного из наборов задач (challenge set), формируемых центром сертификации из следующих типов:

  • создание в зоне DNS проверяемого домена записи типа TXT вида _acme-challenge.example.com., в качестве содержимого которой устанавливается некий токен, генерируемый сервером ACME
  • поместить файл с тем, чтобы он был доступен по URI https://example.com/yetanothertoken, для чего агент настраивает временный сервер HTTPS (с самоподписанным сертификатом); проверка производится HTTP-методом GET со строны CA на предмет доступности ресурса по URI
  • настроить временный сервер HTTPS (с самоподписанным сертификатом), способный установить соединение TLS с сервером ACME (центром сертификации). По этому методу, самоподписанный сертификат формируется агентом так, чтобы содержать в поле subjectAltName массив из двух значений: проверяемый домен и домен вида Z.acme.invalid», где Z расчитывается как функция SHA-256 от (R || S), в которой R — это случайное значение, сообщаемое сервером ACME в процессе обмена, а S — случайное значение, сообщаемое клиентом (агентом). Этот же метод, по сути, используется системой на основе протокола ACME для подтверждения того, что запрашивающая сторона действительно владеет закрытым ключом, которым подписывается сертификат.
  • перечень поддерживаемых типов проверок может быть расширен в будущем, например в планах разработчиков находятся: проверка по электронной почте, DNSSEC и WHOIS.

После подтверждения «владения» (в действительности, администрирования) доменом, происходит формирование запроса на сертификат (CSR) агентом.

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

При обработке CSR (передаваемого в центр сертификации в формате base-64 encoded  DER), сервер ACME проверяет валидность полей перед выпуском сертификата. Система устроена так, что центр сертификации будет отбрасывать из выпускаемого сертификата любые имена сущностей, для которых у запрашивающего сертификат клиента нет авторизации.

В ответ сервера, содержащий сертификат сформированный по запросу, включается собственно сертификат (в формате base-64 encoded DER) и цепочка родительских сертификатов в виде массива в формате base64, DER, в порядке требуемом для осуществления TLS-рукопожатия, т.е. так, что первый сертификат в массиве подтверждает непосредственно сгенерированный сертификат,  а каждый последующий подтверждает непосредственного предшественника; корневой сертификат, при этом, может быть отброшен, поскольку подразумевается, что он уже существует на клиенте.

Follow me

Denis Borchev

Engineer at Netcube LLC
Computer Networking Engineer with 10 years of experience; MSc Applied CS, CCNP/CCDP.
Follow me
Author: Denis Borchev

Computer Networking Engineer with 10 years of experience; MSc Applied CS, CCNP/CCDP.