Руководство по выживанию — TLS/SSL и сертификаты SSL (X.509)

Это руководство по выживанию рассматривает такую вводящую в ступор тему, как сертификаты TLS/SSL и X.509 (SSL), в том числе самоподписанные сертификаты. В нём присутствуют элементы того, что часто называют инфраструктурой открытых ключей (Public Key Infrastructure, PKI).

То, что мы в просторечии называем сертификатами SSL, в действительности должно называться сертификатами X.509. Термин "сертификат SSL" получил распространение в связи с адаптацией Netscape формата сертификата X.509 (одного из стандартов служб каталогов X.500 ITU) при разработке этой компанией оригинальных версий протокола SSL (Secure Socket Layer) в те доисторические времена, когда мир был ещё молод, по планете бродили динозавры, а Интернет был дружелюбным местом. Термин "сертификат SSL" сохраняется и, скорее всего, сохранится в обозримом будущем, поскольку при произношении "сертификат SSL" и "сертификат X.509" первую из фраз выговаривать удобнее. Безусловно, эксперты-лингвисты смогут замечательно это обосновать, ссылаясь на то, что S звучит куда лиричнее, чем X. Для нас, простых смертных, главное преимущество первой фразы в том, что она короче.

В настоящий момент руководство включает SSL, TLS, некоторые детали о X.509 и их применении, а также кое-какие разъяснения о типах сертификатов, в том числе о сертификатах EV, и о процессе доверия. Создание самоподписанных сертификатов представлено в виде рабочего примера использования пакета OpenSSL.

Вы можете либо купить сертификат SSL (X.509), либо сгенерировать свой собственный (самоподписанный) для тестирования или, в зависимости от приложения, даже применения в производственной среде. Хорошие новости: При использовании самоподписанных сертификатов Вы сэкономите несметное количество денег. Плохие новости: При использовании самоподписанных сертификатов никто кроме Вас и (возможно) Ваших ближайших родственников не сможет им доверять. Но, прежде чем выкладывать все свои сбережения за новенький блестящий сертификат X.509 (SSL) или даже за более дорогой сертификат EV SSL (X.509), Вам, вероятно, хотелось бы знать, что они делают и как они это делают. И если Вы впадаете в ступор как только люди начинают говорить об SSL, защите информации и сертификатах — самое время туда впасть. Это руководство не будет лёгким чтивом.

<укоренившиеся привычки> В приведённом ниже списке RFC гиперссылки указывают на текстовые версии, которые мы скопировали на наш сайт, когда эти RFC были выпущены. Мы начинали делать это очень, очень давно, когда RFC содержались в каких-то странных местах, иногда меняющих своё местоположение, а производительность и доступность этих репозиториев оставляла желать лучшего (мягко сказано). Сегодня всё это далеко не так. У IETF и IANA есть солидные веб-сайты с прекрасной производительностью и постоянно совершенствующимися возможностями. Тем не менее, мы упорно продолжаем следовать нашей укоренившейся привычке без всякой видимой причины (старого пса новым трюкам не выучишь...).

Примечание: Если Вы хотите/предпочитаете/нуждаетесь в более продвинутом представлении RFC, то следующая информация специально для Вас. Основной репозиторий RFC поддерживается IETF, текстовые версии (которые считаются нормативными) можно найти на www.ietf.org/rfc/rfcXXXX.txt или на www.rfc-editor.org/rfc/rfcXXXX.txt (где XXXX — состоящий из 4 цифр номер RFC, при необходимости дополненный слева нулями). Опубликованные на настоящий момент RFC размещены на https://www.rfc-editor.org/info/rfcXXXX, здесь содержится различная информация и ссылки на текстовые (нормативные) и PDF (ненормативные) версии документов. RFC в также можно посмотреть на http://datatracker.ietf.org/doc/rfcXXXX/, здесь же содержится различная статусная информация по RFC (в том числе сообщения об ошибках), а также ссылки на просмотр в различных форматах, таких как текст, PDF и HTML (это версии документов, находящиеся в работе). Наконец, существует страница поиска по RFC.</укоренившиеся привычки>

Примечание переводчика: в русском варианте страницы ссылки указывают на HTML-версии RFC на сайте https://tools.ietf.org/html/.

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

Содержание:

• Обзор протокола TLS/SSL
• Последовательность обмена сообщениями протоколов TLS/SSL
• TLS/SSL — детальное описание
• Шифрование — обзор
• Обзор сертификата X.509
• Типы и терминология сертификатов X.509
• Цепочки сертификатов X.509
• Использование сертификатов X.509 (Ну и зачем я это купил?)
• Сертификаты X.509 в организациях, предоставляющих услуги веб-хостинга
• Протоколы, связанные с сертификатами (CMP, CMC/CMS, SCVP, OCSP, HTTP)
  1. Протокол онлайн-получения статуса сертификата (OCSP)
• Формат сертификата X.509
  1. Замечания по полям сертификата subject и subjectAltName
• Списки отзыва сертификатов X.509 (CRL)
• Процесс доверия — удостоверяющие центры и сертификаты X.509
• Сертификаты X.509 расширенной валидации (EV)
• Пример — создание самоподписанных сертификатов (OpenSSL, несколько методов)
• Пример — создание подчинённых УЦ, промежуточных сертификатов и кросс-сертификатов (OpenSSL)
• Пример — создание сертификатов с несколькими именами хоста (OpenSSL)
• Замечания по форматам файлов, связанных с SSL
  1. Формат PEM
  2. Ключевые слова (метки) в строках BEGIN PEM-файла
  3. Имена файлов и их содержимое
  4. Связки сертификатов
  5. Команды OpenSSL для конвертации, извлечения и манипуляций с сертификатами и ключами
  6. Таблица соответствия стандартов PKCS#X и RFC
  7. Работа с сертификатами в основных браузерах
• RFC по теме

Протокол TLS/SSL

Основное предназначение сертификатов SSL (X.509) — использование совместно с протоколом TLS/SSL. Secure Sockets Layer (SSL, уровень защищённых сокетов) — протокол, изначально разработанный Netscape в 1992 году для безопасного обмена информацией между web-сервером и браузером по незащищённым сетям. Претерпел несколько изменений, нынешняя версия 3 датируется 1995 годом и используется в различных клиент-серверных приложениях. В связи с распадом Netscape спецификации SSL в дальнейшем обновляться не будут. Таким образом, этот стандарт повторил судьбу известного мёртвого попугая, и, в конце концов, в RFC 7568 SSL v3 признан устаревшим. Теперь это официально мёртвый стандарт, и потому впредь его использовать не стоит, хотя бы ради сохранения на Земле главенства разумного, доброго и вечного.

IETF стандартизировала Transport Layer Security (TLS, безопасность транспортного уровня) версии 1, незначительно отличающийся от SSL, в RFC 2246, версии 1.1 в RFC 4346, наконец версии 1.2 в RFC 5246. Кроме того, в RFC 3546 определено несколько расширений для случаев, когда TLS используются в системах с ограниченной пропускной способностью, таких как беспроводные сети, в RFC 6066 определён ряд расширений TLS, внесённых в формат расширенного приветствия клиента (представленного в TLS 1.2), в RFC 6961 определён метод уменьшения трафика, когда клиент запрашивает у сервера информацию о состоянии сертификата. И, наконец, в RFC 7925 определяется, что происходит с TLS (и DTLS) при его использовании в IoT (Internet of Things, Интернете вещей или Интернете вещичек, как презрительно называем его мы).

При первоначальной установке защищённого соединения, в зависимости от реализации, будут проводиться переговоры о поддержке конкретного протокола из набора SSLv3, TLSv1, TLSv1.1 или TLSv1.2. Все так привыкли к названию SSL, что в большинстве случаев то, что называют SSL, скорее всего является использованием TLS — например, OpenSSL поддерживает и SSL (версии 3) и TLS (версий 1, 1.1 и 1.2). Поскольку SSL и TLS отличаются друг от друга лишь в деталях, дальнейшее описание относится к обоим протоколам.

Примечание: SSLv2 был отменён RFC 6176, в котором приводится ужасающий список всех его недостатков. Та же печальная участь теперь постигла и SSLv3: он был отменён RFC 7568. Все встречающиеся далее упоминания SSL сохранены в тексте по причине широкого распространения этого термина (он до сих пор используется чаще, чем TLS), однако читателям следует помнить, что речь идёт о TLS.

TLS/SSL работают поверх TCP, но ниже по уровню тех конечных пользовательских протоколов, которые они защищают, таких как HTTP или IMAP (как показано на рисунке 1):

Рисунок 1 — Уровень TLS/SSL

За самими протоколами TLS/SSL не закреплено какого-либо общеизвестного номера порта — вместо этого при использовании с протоколом более высокого уровня, например HTTP, принято обозначать, что этот протокол будет использовать защищённый вариант (HTTPS в случае HTTP), у которого как раз есть общеизвестный номер порта (или порт по умолчанию). Обозначение HTTPS просто указывает на то, что нормальный протокол HTTP будет работать поверх соединения TLS/SSL, которые в свою очередь работают поверх TCP. В случае HTTPS общеизвестный номер порта — 443, в случае IMAPS — 993, POP3S — 995 и так далее.

Дальнейшее описание требует некоторого знакомства с терминами MAC (Message Authentication Code, аутентификационный код сообщения), односторонние хэши, симметричные и асимметричные криптографические алгоритмы. Для тех, кто с ними не знаком, рекомендуется почитать это руководство по выживанию, касающееся криптографии. Осторожно, прочтение этого материала может вызывать переутомление и фобии.

Примечания:

1. Родственный протокол, Datagram Transport Layer Security (DTLS, безопасность транспортного уровня для дейтаграмм), определяет сервис безопасности при использовании UDP (RFC 6347, обновлён в RFC 7507). Поскольку его принципы аналогичны TLS, в дальнейшем в данном руководстве DTLS не обсуждается.

2. Термин TLS 1.2 Suite B (определённый в RFC 6460) определяет набор шифров (смотрите ниже), совместимых с NSA Suite B Cryptography, и имеет значение только при использовании TLS для приложений в интересах национальной безопасности США.

Обзор — установление защищенного соединения

При установлении защищенного соединения с помощью TLS/SSL, например при использовании HTTPS (порт по умолчанию — 443), между клиентом, который всегда является инициатором соединения, и сервером происходит обмен сообщениями. Первый набор сообщений называется протоколом рукопожатия (Handshake Protocol), после обмена этими сообщениями и клиент и сервер входят в протокол записи (или данных) (Record (Data) Protocol). При обмене сообщениями во время протокола рукопожатия достигаются следующие цели:

1. Устанавливается, какой вариант протокола из поддерживаемого (в зависимости от реализации) набора, — SSLv3, TLSv1, TLSv1.1, TLSv1.2, — будет использоваться. Всегда выбирается самый последний из возможных вариантов, то есть у TLSv1 всегда будет приоритет перед SSLv3 в случае, если и клиент и сервер поддерживают оба варианта. Клиент предлагает список вариантов, а сервер выбирает из предложенного списка.

2. Отправляются аутентификационные данные. Обычно сервер посылает аутентификационную информацию в форме сертификата (встроенную в сертификат) X.509 (SSL), но протокол поддерживает и другие методы.

3. Устанавливается идентификатор (ID) сессии, таким образом, при необходимости сессия может быть перезапущена.

4. Происходят переговоры о наборе шифров, состоящем из алгоритма обмена ключами вместе с типом алгоритма шифрования объёмных данных и типом MAC, которые будут использоваться в последующей сессии обмена данными (протокол записи). Обычно в качестве алгоритма обмена ключами используется асимметричный алгоритм (с закрытым и открытым ключом), такой как RSA, DSA или ECC (Elliptic Curve Cipher, шифр на основе эллиптических кривых, смотрите RFC 5289). Асимметричные алгоритмы потребляют очень много ресурсов процессора и потому для последующего шифрования объемных данных (протокол записи) используются симметричные шифры. Алгоритмы обмена ключами применяются для передачи информации, на основании которой могут быть независимо вычислены сеансовые ключи для симметричного шифра. MAC используется для защиты целостности передаваемых/получаемых данных во время протокола записи.

Конечно, это упрощённая схема, и во время установления соединения может совершаться обмен и другими данными, например, в процессе так называемой взаимной аутентификации у клиента для его аутентификации может быть запрошен сертификат X.509 (SSL), но описанный нами процесс — это наиболее распространенный случай, его мы и проиллюстрировали на рисунке 2:

Рисунок 2 - Последовательность обмена сообщениями протоколов TLS/SSL

Примечания:

1. В фазе протокола рукопожатия проводятся переговоры и устанавливается соединение, а в фазе протокола записи происходит передача (инкапсуляция) зашифрованного потока данных, таких как HTTP, SMTP или IMAP.

2. На рисунке 2 чёрными стрелками показаны сообщения, отправляемые открытым текстом (незашифрованные); синими — сообщения, отправляемые с использованием открытого ключа, предоставленного сервером (с помощью шифра обмена ключами), для их обработки требуется, чтобы у сервера был доступ к соответствующему закрытому ключу; зелёными — сообщения, отправляемые с использованием того алгоритма шифрования объёмных данных и того MAC, о которых стороны договорились в процессе переговоров.

3. TLS/SSL позволяют договориться об использовании какого-либо алгоритма сжатия данных (как составной части набора шифров). С учётом скорости современных сетей сжатие данных используется всё реже или вообще не используется, и обычно значение выбранного алгоритма сжатия в согласованном наборе шифров устанавливается в NULL (не используется).

TLS/SSL — детальное описание

В данном разделе приводится более подробное описание обмена сообщениями протоколов TLS/SSL (смотрите рисунок 2 выше) для тех, кто любит покопаться во внутренностях. Если Вам удобнее мириться с тем, что "в мире происходит много необычного", лучше пропустите этот раздел, чтобы не рисковать рассудком.

1. ClientHello (1): Сообщение ClientHello предлагает список поддерживаемых версий/вариантов протоколов, поддерживаемые наборы шифров в порядке предпочтения и список алгоритмов сжатия (обычно NULL). Клиент также посылает случайное значение размером в 32 байта (отметка текущего времени), которое позднее будет использоваться для вычисления симметричного ключа, и идентификатор сессии, который будет равен нулю, если не было предыдущих сессий, либо ненулевому значению, если клиент считает, что предыдущая сессия существует.

   • Каждый набор шифров состоит из алгоритма обмена ключами, алгоритма шифрования объёмных данных и алгоритма MAC (хэширования).

   • Набор шифров, используемый и клиентом и сервером, при первоначальном соединении таков:

     TLS_NULL_WITH_NULL_NULL (0x00, 0x00)
     # первый NULL — алгоритм обмена ключами
     # следующий за ним WITH_NULL определяет алгоритм шифрования объёмных данных
     # последний NULL определяет MAC
     

     Это значение говорит о том, что шифрование выполняться не будет и потому все сообщения до Client Key Exchange (ClientKeyMessage) будут отправляться открытым текстом.

   • Типичный набор шифров:

     TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x00, 0x0A)
     # RSA — алгоритм обмена ключами
     # WITH_3DES_EDE_CBC определяет алгоритм шифрования объёмных данных
     # (Triple DES с циклической цепочкой блоков)
     # SHA — это MAC (хэш)
     

     Примечания:

     1. Каждому набору шифров присвоен свой код. Значение этого кода (два октета) называется Сигнальным значением набора шифров (Signaling Cipher Suite Value, SCSV) — ещё одна фишка для Вашего гик-лексикона.

     2. Корректные значения наборов шифров можно найти в приложениях C RFC по TLS (RFC 2246 для TLS 1, RFC 4346 для TLS 1.1 и RFC 5246 для TLS 1.2). Значения для ECC (шифров на основе эллиптических кривых) приведены в RFC 4492 и RFC 7027.

     3. Слово EXPORT, встречающееся в описаниях некоторых наборов шифров, говорит о том, что эти шифры являются экспортируемыми, то есть некоторые шифры разрешено использовать только в определённых странах (смотрите документацию Бюро промышленности и безопасности (BIS) Министерства торговли США и Вассенарские соглашения), и это необходимо учитывать при настройке системы, которая будет использоваться на международном уровне.

     4. Расширения, определённые в RFC 3546 и в основном используемые в беспроводных сетях, могут быть применены в сообщении ClientHello на манер обеспечения обратной совместимости. RFC 6066 значительно увеличивает количество расширений TLS, многие из которых могут использоваться в обычных (не беспроводных) сетях. Сервер волен молча проигнорировать те расширения, которые он не понимает.

     5. В RFC 6066 представлен тип расширения TLS Certificate Status (status_request), в котором, по существу, сказано: "Я (клиент) абсолютно не доверяю твоему (сервера) сертификату, но я буду абсолютно доверять твоему (сервера) ответу на мой запрос (Certificate Status) о валидности сертификата(!)". Ответ на запрос Certificate Status (обычно получаемый с помощью OCSP) посылается в сообщении CertificateStatus сразу после сообщения Certificate (смотрите ниже). Видимо, запросы Certificate Status (status-request) стали настолько популярны (среди беспроводных устройств?), что есть риск падения OCSP-серверов. В RFC 6961 представлено расширение "certificate_request_v2", снижающее объёмы трафика от сервера TLS серверу OCSP путём разрешения первому из них кэшировать ответы OCSP, а также от сервера TLS клиенту TLS путём разрешения первому из них отправлять всю необходимую информацию, в том числе о промежуточных сертификатах, в одном сообщении CertificateStatus.

   • В RFC 6066 определено опциональное расширение Server Name Indication (SNI), позволяющее клиенту при установке первоначального соединения TLS/SSL посылать имя сервера, такое как www.example.com. Данная возможность (поддерживаемая большинством современных браузеров) позволяет web-серверу, обслуживающему несколько web-сайтов, (например, Apache с настроенной функцией VirtualHost) отправлять специфичный для сайта сертификат в своём сообщении Certificate (3). Конфигурация Apache 2 для поддержки SNI.

   • В RFC 7250 определено расширение client_certificate_format, которое может применяться для указания формата используемого сертификата. Это может быть нормальный формат X.509 или формат RawPublicKey, при котором в последующих сообщениях передачи сертификата протокола рукопожатия сертификат сокращается до одного атрибута subjectPublicKeyInfo.

   • Многие TLS/SSL-клиенты при возникновении сетевых ошибок будут пытаться произвести откат до более низкой версии протокола, что может привести к необоснованному ослаблению соединения. В RFC 7507 определён новый шифр:

     TLS_FALLBACK_SCSV  {0x56, 0x00}
     

     TLS/SSL-клиенты могут включать это сообщение в любую попытку переговоров о понижении версии протокола. Старые сервера проигнорируют такое сообщение, и будет нормальным способом устанавливаться соединение с более низкой версией протокола. Новые сервера, распознающие это сообщение, будут прерывать соединение с клиентом и выдавать предупреждение inappropriate_fallback (86), если предлагаемая клиентом версия протокола ниже, чем та, что поддерживается сервером. Таким образом ограничиваются случаи, когда возможно установление соединения с необоснованным снижением версии протокола.

   • В RFC 7685 определено расширение, которое может быть использовано для дополнения (нулями) размера сообщения ClientHello в целях смягчения эффекта от работы ошибочных реализаций TLS (такого мы не ещё не пробовали).

   • В RFC 7633 определено новое расширение сертификата X.509, которое включает в себя список расширений TLS, поддерживаемых этим сертификатом. Если сервер не предоставляет указанных расширений TLS, клиент может сделать предположение о потенциальной небезопасности сессии и прервать её. Очевидно, что такое решение клиент должен принять не позднее окончания фазы Certificate рукопожатия TLS.

2. ServerHello (2): Сообщение ServerHello возвращает выбранные вариант/номер версии протокола, набор шифров и алгоритм сжатия. Сервер посылает случайное значение размером в 32 байта (отметка текущего времени), которое позднее будет использоваться для вычисления симметричных ключей. Если идентификатор сессии в сообщении ClientHello был равен нулю, сервер создаст и вернёт идентификатор сессии. Если в сообщении ClientHello был предложен идентификатор предыдущей сессии, известный данному серверу, то протокол рукопожатия будет проведён по упрощённой схеме. Если клиент предложил неизвестный серверу идентификатор сессии, сервер возвращает новый идентификатор сессии и протокол рукопожатия проводится по полной схеме.

   В RFC 7250 определено расширение server_certificate_format, которое может применяться для указания формата используемого сертификата. Это может быть нормальный формат X.509 или формат RawPublicKey, при котором в последующих сообщениях передачи сертификата протокола рукопожатия сертификат сокращается до одного атрибута subjectPublicKeyInfo.

3. Certificate (3): Сервер посылает свой сертификат X.509, содержащий открытый ключ сервера, алгоритм которого должен совпадать с алгоритмом обмена ключами в выбранном наборе шифров. Протокол предлагает и другие методы доставки открытого ключа, — можно, например, просто указать на запись DNS KEY/TLSA RR, — но сертификат X.509 является стандартным общепринятым методом. Цель данного сообщения — получение клиентом из доверенного источника открытого ключа сервера, который затем может использоваться этим клиентом для отправки зашифрованного сообщения.

   Примечания:

   1. Хотя в этом сообщении обычно посылается только один сертификат, можно послать и так называемую связку сертификатов (certificate bundle) — более одного сертификата в PEM-файле. Например, связки сертификатов могут быть определены с помощью директивы Apache SSLCertificateChainFile, тогда как единичный сертификат должен быть определён директивой SSLCertificateFile. Обычно связки используются при наличии кросс-сертификатов, появляющихся в результате некоторой формы реструктуризации сертификата, например, при корпоративном поглощении одной компании другой или изменении ключа/размера ключа удостоверяющего центра (CA).

   2. Протокол DNSSEC DANE (RFC 6698) позволяет клиентам получать копию сертификата X.509 сервера с помощью запроса к системе DNS. Однако, сертификаты, полученные по системе DNS с помощью DANE, являются дополнительными по отношению к тем, которые получены в процессе нормального обмена сертификатами TLS/SSL, и служат скорее для того, чтобы патологические параноики могли провести дополнительную верификацию, а пользы в плане повышения безопасности приносят немного (если вообще приносят).

   3. RFC 7250 определяет упрощённый формат сертификата, в котором открытый ключ в чистом виде инкапсулируется в обёртку, состоящую из атрибута SubjectPublicKeyInfo (необходимого для описания свойств открытого ключа). Это скромный шаг в сторону более разумного способа обретения открытого ключа непосредственно от аутентифицированного источника, такого как защищённая DNS-запись DNSSEC.

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

Примечание: Если во время переговоров об установлении TLS/SSL сервер запросил сертификат клиента, то клиент должен отправить свой сертификат (в том же формате, который определен для сервера, с тем исключением, что RFC 6066 позволяет любому клиенту посылать URL сертификата вместо полного сертификата) непосредственно за сообщением ServerDone и до сообщения ClientKeyExchange.

5. ClientKeyExchange (5): Клиент вычисляет так называемый ключ pre-master key, используя случайные числа (или отметки текущего времени) сервера и клиента. Он шифрует этот ключ с помощью открытого ключа сервера, полученного из предоставленного сертификата X.509. Только сервер может расшифровать данное сообщение своим закрытым ключом. Обе стороны независимо друг от друга вычисляют общий секретный ключ master key из ключа pre-master, используя определённый в стандарте алгоритм. Любые сеансовые ключи, которые могут потребоваться, будут производными от этого ключа master key.

   Примечание:

   1. Как известно, TLS (и DTLS) могут быть уязвимы к атакам типа "человек посередине" (Man-in-The-Middle, MTM). Для устранения этой уязвимости в RFC 7627 был переопределён метод вычисления ключа master secret (изначально определённый в RFC 5246). В новом методе вместо случайных чисел сервера и клиента используется хэш полной сессии от сообщения ClientHello до сообщения ClientKeyExchange. Клиент демонстрирует, что он способен использовать новый (переопределённый) алгоритм вычисления master secret, путём отправки в ClientHello пустого расширения extended_master_secret. Если сервер поддерживает новый алгоритм, он также отправит пустое расширение extended_master_secret в сообщении ServerHello. Если клиент или сервер не поддерживают новый алгоритм (RFC 7627), они, конечно же, могут прервать сессию, либо продолжить её с использованием старого алгоритма (RFC 5246).

6. ChangeCipherSpec — клиент (6): Это сообщение указывает, что весь последующий трафик, исходящий от данного клиента, будет зашифрован с помощью выбранного (в результате переговоров) алгоритма шифрования объёмных данных и будет содержать MAC, сформированный по выбранному алгоритму. Номинально это сообщение всегда будет шифроваться текущим шифром, который в стадии установления соединения будет NULL, и, следовательно, данное сообщение отображено на диаграмме как отправляемое в открытом виде. Несмотря на то, что это сообщение показано на диаграмме протокола как отправляемое отдельно, часто оно объединяется с сообщением Client Key Exchange.

7. Finished — клиент (7): Это сообщение содержит все сообщения, отправленные и полученные во время протокола рукопожатия, за исключением сообщения Finished. Оно шифруется с помощью алгоритма шифрования объемных данных и хэшируется с помощью алгоритма MAC, о которых договорились стороны. Если сервер может расшифровать и верифицировать это сообщение (содержащее все предыдущие сообщения), используя независимо вычисленный им сеансовый ключ, значит диалог был успешным. Если же нет, на этом месте сервер прерывает сессию и отправляет сообщение Alert с некоторой (возможно, неконкретной) информацией об ошибке.

   Примечание: В RFC 7918 указано, что при определённых условиях клиент может начать передачу данных сразу же после отправки данного сообщения для сокращения времени ожидания соединения. Если при обработке последующих сообщений от сервера произойдёт ошибка, то соединение будет разорвано, но данные скомпрометированы не будут.

8. ChangeCipherSpec — сервер (8): Это сообщение указывает, что весь последующий трафик, исходящий от данного сервера, будет зашифрован с помощью выбранного (в результате переговоров) алгоритма шифрования объёмных данных и будет содержать MAC, сформированный по выбранному алгоритму. Номинально это сообщение всегда будет шифроваться текущим шифром, который в стадии установления соединения будет NULL, и, следовательно, данное сообщение отображено на диаграмме как отправляемое в открытом виде. Получение данного сообщения неявно говорит клиенту о том, что сервер получил и смог обработать сообщение Finished этого клиента.

9. Finished — сервер (9): Это сообщение содержит все сообщения, отправленные и полученные во время протокола рукопожатия, за исключением сообщения Finished. Оно шифруется с помощью алгоритма шифрования объемных данных и включает MAC, о которых договорились стороны. Если клиент может расшифровать это сообщение, используя независимо вычисленный им сеансовый ключ, значит диалог был успешным. Если же нет, клиент прерывает соединение и выдаёт сообщение Alert и подходящий (хотя и не всегда конкретный) код ошибки.

10. Record Protocol (протокол записи): Последующие сообщения между сервером и клиентом шифруются с помощью алгоритма шифрования объемных данных и включают MAC, о которых договорились стороны.

Примечания:

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

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

Обзор сертификатов X.509 (SSL)

Оригинальный стандарт ITU-T X.509, в котором сертификаты получили своё несчастливое имя, — один из серии стандартов спецификации каталогов X.500. Использование сертификатов X.509 в Интернет стандартизировано IETF в RFC 5280, определяющем формат сертификата X.509, а также в RFC 4210, определяющем протокол управления сертификатами (Certificate Management Protocol, CMP), который используется для запросов на доступ и обработку сертификатов X.509 (есть также ряд дополнительных протоколов, используемых для обработки и проверки сертификатов). Наконец, в RFC 3739 определяется то, что называется квалифицированным сертификатом (Qualified Certificate), относящимся к Европейской директиве по электронным подписям (директива 1999/93/EC).

Для интересующихся: Стандарты каталога X.500 ITU-T определяли, помимо прочего, протокол DAP (Directory Access Protocol), который предназначался для поддержки злополучного почтового OSI-сервиса X.400. В IETF хотели получить сервис каталогов без всех этих OSI-наворотов и создали протокол LDAP (Lighweight Directory Access Protocol). Так что вся относящаяся к сертификатам X.509 техническая архитектура берёт своё начало из DAP/LDAP.

X.509 открывает совершенно новый и удивительный мир терминологии. В частности, для обозначения полей в сертификате в нём используется термин "отличительное имя" (Distinguished Name, DN). DN определены IETF в серии RFC по LDAP, конкретнее, в RFC 4514 (рус.). Также используются термины "абстрактная нотация синтаксиса 1" (Abstract Syntax Notation 1, ASN.1) и "идентификатор объекта" (Object Identifier, OID), описанные в серии стандартов X.680 ITU. Наконец, при кодировании используются "особые (или уникальные) правила кодирования" (Distinguished Encoding Rules, DER), описанные в X.690 ITU.

Также существует большое количество связанных с управлением сертификатами стандартов, помеченных как PKCS#X (где X — число), например, PKCS#10 определяет формат запроса на подпись сертификата (Certificate Signing Request, CSR). Они относятся к стандартам, определенным RSA Laboratories. Некоторые из этих стандартов были воспроизведены практически без изменений в качестве RFC, например, упомянутый выше PKCS#10 был опубликован как RFC 2986 (обновлён в RFC 5967). В дополнение к стандартам от IETF, RSA и ITU-T, X.509 был стандартизирован в ряде стран, а также некоторыми промышленными организациями. Те, кто следит за этим вопросом, а также те, кто занимается реализацией, обращают внимание на то, что подобная множественность стандартов может привести к серьезным проблемам в реализации и интерпретации. Вот довольно подробный, большой и пугающий набор заметок по реализации X.509 от Peter Gutmann.

Сертификат X.509 выполняет две различные функции:

1. Сертификат X.509 (в настоящее время X.509v3) служит контейнером для открытого ключа, который может быть использован для проверки или валидации конечного субъекта (end entity, EE), такого как веб-сайт или LDAP-сервер. Этот субъект определён в поле subject сертификата. Субъект в поле subject описывается в форме уникального или отличительного имени (Distinguished Name, DN), — широко используется в LDAP, —  состоящего из ряда относительных уникальных имён (Relative Distinguished Name, RDN), каждое из которых представляет собой содержащий данные элемент, называемый атрибутом (Attribute). В частности, атрибут CN (commonName), образующий RDN уникального имени, обычно содержит описание конечного субъекта, которому выдан сертификат. Примером CN может быть адрес веб-сайта, такой как CN=www.example.com. Полное DN в поле subject может содержать один или более из следующих RDN: CN= (commonName, общепринятое имя, наименование конечного субъекта, например, website или www.example.com), C= (страна), ST= (штат или область в составе страны), L= (местоположение, номинально определяет адрес, но используется в разных целях, за исключением сертификатов EV, где его предназначение строго определено), OU= (organizationalUnitName, название подразделения компании или какая-либо иная подструктура), O= (organizationName, обычно название компании).

2. Сертификат X.509 подписан цифровой подписью доверенной удостоверяющей организации (обычно называемой удостоверяющим центром (Certificate Authority) или просто CA), уникальное имя (DN) которой указано в поле issuer сертификата. Это делается, во-первых, для того, чтобы убедиться, что данный сертификат не был подделан, а во-вторых, для того, чтобы подтвердить (удостоверить), что данный открытый ключ для субъекта, указанного в поле subject на самом деле является открытым ключом для данного субъекта. Этот процесс доверия мы опишем далее. Подписывающая организация может быть удостоверяющим центром (Certification Authority, CA), регистрационный центром (Registration Authority, RA) или каким-то другим промежуточным центром (таким как подчинённый удостоверяющий центр (subordinate CA)), кроме того сертификат может быть самоподписанным. Примечание: Закрытый ключ, ассоциированный с открытым ключём в сертификате X.509 пользователя, всегда хранится у пользователя и никогда не разглашается подписывающей организации.

Отдельная структура X.509, называемая списком аннулированных (или отозванных) сертификатов (Certificate Revocation List, CRL, в настоящий момент CRLv2) предоставляет информацию о сертификатах, которые по тем или иным причинам были аннулированы или признаны недействительными. По сути, CRL представляют собой старомодный "пакетный" способ работы с аннулированными сертификатами. В них содержатся большие (порой даже очень большие) списки всех сертификатов, которые были отозваны. Если проверяемого (по серийному номеру) сертификата нет в списке CRL, предполагается, что он ещё действителен. У списков CRL есть множество проблем: они могут обновляться только периодически и только УЦ (издателем сертификатов), из-за большого размера CRL браузеры скачивают их (если вообще это делают) неохотно и нерегулярно. Короче говоря, это не очень удобный и эффективный способ. Для проверки текущего статуса конкретного сертификата (опять же, определяемого по серийному номеру) всё чаще и чаще используется онлайн-способ (OCSP), а спецификация SSL-сертификатов EV, вообще требует обязательного использования OCSP.

Большая часть информации в этом разделе сфокусирована на использовании X.509 для валидации коммуникаций сервера. X.509 может также использоваться и для других целей, таких как идентификация пользователей (включая цифровые подписи) и S/MIME, которые мы обязательно рассмотрим, когда (если) голова болеть перестанет.

Типы сертификатов X.509 и терминология

При обсуждении вопросов, связанных с сертификатами X.509 (SSL), используется несметное количество терминов. Иногда они применяются последовательно, но в основном — нет, что только добавляет неразберихи. Даже в RFC, посвящённым сертификатам, нет строго определения терминологии, пожалуй, лучше всего с этим обстоят дела в RFC 4210. Как правило, удостоверяющие центры (УЦ) предлагают несколько типов сертификатов. За исключением сертификатов EV и квалифицированных сертификатов, имеющих точное назначение и определение, все эти типы сертификатов, по большому счёту, — маркетинговая концепция, цель которой — предоставить выбор по цене/функциональности. Поэтому мы ограничимся лишь поверхностным обзором подобных типов сертификатов, в лучшем случае предоставляя немного технической терминологии. Наконец, не все УЦ одинаковы. Хотя большинство УЦ являются нарочито профессиональными организациями, которые регулярно проверяются или сертифицируются теми или иными национальными организациями, это не всегда так (на сайте УЦ ищите ссылки по аттестации, сертификации и аудиту и смотрите, что там). При покупке сертификата необходимо проявлять бдительность!

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

Удостоверяющий центр (УЦ, он же корневой УЦ, англ. Certificate Authority (CA) a.k.a. root CA): термин "удостоверяющий центр" определяется как субъект, подписывающий сертификаты, в которых выполнены следующие условия: поля issuer и subject совпадают, поле KeyUsage установлено в keyCertSign и/или в поле basicConstraints атрибут cA установлен в TRUE. Как правило, в цепочке сертификатов сертификат корневого УЦ является сертификатом самого верхнего уровня, однако RFC 4210 определяет, что корневым УЦ может быть любой издатель (issuer), сертификат которого получен конечным субъектом (например, браузером) в результате доверенного процесса получения. Поскольку окончательное решение о выдаче любого сертификата остаётся за этим УЦ, термины и условия любого промежуточного сертификата могут быть изменены данным субъектом.

Регистрационный центр (РЦ, он же регистрационный УЦ, англ. Registration Authority (RA) a.k.a. Registration CA): Регистрационный центр (RA) может потребоваться в определенных условиях для обработки специфических характеристик сертификата, например, РЦ может быть делегирован Национальным удостоверяющим центром для специализации на персональных сертификатах, а другой РЦ может специализироваться на сертификатах серверов. РЦ, если таковые вообще имеются, являются, по сути, неким средством для административного удобства. РЦ могут подписывать сертификаты (как подчинёные УЦ), но могут также, выполнив соответствующие проверки конечного субъекта, передавать запрос на подписание корневому УЦ.

Подчинённый центр (подчинённый УЦ, англ. Subordinate Authority a.k.a. Subordinate CA): Общий термин. Любой субъект, подписывающий сертификаты, но не являющийся корневым УЦ. Некоторые подчинённые УЦ - особенно те, которые работают под полным контролем владельца корневого УЦ - могут быть помечены как УЦ (будет присутствовать расширение BasicContraints и cA будет установлено в True). То есть, если РЦ подписывает сертификаты, то он делает это как подчинённый УЦ, и если он работает под контролем корневого УЦ, то он также может быть помечен, как УЦ.

Промежуточный центр (промежуточный УЦ, англ. Intermediate Authority a.k.a. Intermediate CA): Неточный термин, иногда используется для определения субъекта, создающего промежуточные сертификаты, и, таким образом, охватывает РЦ и подчинённые УЦ.

Кросс-сертификаты (они же сертификаты сцепления или мостовые сертификаты, англ. Cross certificates a.k.a. Chain or Bridge certificate): Кросс-сертификат представляет собой сертификат, в котором субъекты в полях subject и issuer не совпадают, но оба являются удостоверяющими центрами (присутствует расширение BasicConstraints и поле cA установлено в True). Как правило, такие сертификаты используются, когда УЦ изменил некоторые элементы свой политики издания сертифиткатов (новая дата истечения срока действия ключа или новый ключ), либо когда один УЦ был поглощён другим, и сертификаты, изданные поглощённым УЦ, привязываются к новому владельцу, чтобы можно было отказаться от использования ранее выданных корневых сертификатов. При использовании в данном контексте термин сертификат сцепления указывает на то, что была создана новая привязка, и иногда называется мостовым сертификатом (он привязывается к новому УЦ или выполняет функции моста к нему). Кросс-сертификаты могут быть установлены на сервере (как часть связки сертификатов - смотрите примечание в разделе Протокол TLS, сообщение Certificate), но при использовании для обеспечения обратной совместимости, например, при обработке EV-сертификата несовместимым с EV клиентом, кросс-сертификат устанавливается на клиенте. За исключением того, что поле cA установлено в True (что, откровенно говоря, мало что меняет) кросс-сертификат представляет собой обыкновенный промежуточный сертификат.

Промежуточные сертификаты (они же сертификаты сцепления, англ. Intermediate certificates a.k.a. Chain certificates): Неточный термин, применяемый к любому сертификату, не подписанному корневым УЦ. Промежуточные сертификаты формируют цепочку, в которой на пути от сертификата конечного субъекта до корневого сертификата может быть сколько угодно промежуточных сертификатов. Промежуточные сертификаты могут быть выпущены подчинёнными УЦ, РЦ или даже напрямую корневым УЦ (хотя технически их следует называть кросс-сертификатами) для различных целей: организации перехода, поглощения или даже просто для дифференциации брендов. В данном контексте термин сцепление бессмысленен (хотя звучит умно и помпезно), он просто указывает на то, что сертификат является частью какой-то цепочки.

Связка сертификатов (англ. Certificate Bundle): Общий термин, указывающий на то, что в один файл (обычно в формате PEM) объединены несколько сертификатов X.509. Связки сертификатов могут передаваться во время протокола рукопожатия TLS/SSL. Обычно связки сертификатов используются для административных целей во время некоторых изменений состояния УЦ, например, поглощения, изменения политики, ключа, даты истечения срока действия ключа и т.п.

Квалифицированные сертификаты (англ. Qualified certificates): Определённый в RFC 3739 термин "квалифицированные сертификаты" относится к персональным сертификатам (а не к сертификатам серверов или сертификатам конечного субъекта) и ссылается на Директиву Европейского союза об электронной подписи (1999/93/EC), сфокусированную на единообразном определении индивидуума в целях электронной подписи, авторизации или аутентификации. В частности, данное RFC позволяет содержать в поле subject в порядке очерёдности атрибуты commonName (CN=), givenName (GN=) или pseudonym=, также может присутствовать поле subjectDirectoryAttributes, содержащее какие-либо из атрибутов dateOfBirth=, placeOfBirth=, gender=, countryOfCitizenship= и countryOfResidence=. Наконец, в этом RFC определены два новых расширения biometricInfo и Qualified Certificate statements (qcStatements). Квалифицированный сертификат определяется по наличию расширения qcStatements со значением qcStatement-2. Большинство правительств конкретных стран добавили для включения в такие сертификаты ряд дополнительных полей. В некоторых случаях на то были реальные причины, в других — просто желание продемонстрировать свои амбиции и сделать невыносимой жизнь тех, кто занимается реализацией стандартов сертификатов.

Неквалифицированные сертификаты (англ. non-Qualified certificates): Вообще, так называют персональные сертификаты, не удовлетворяющие требованиям стандарта квалифицированных сертификатов. Издатели квалифицированных сертификатов также употребляют этот термин по отношению к другим сертификатам с намёком на то, что эти сертификаты более низкого качества.

Сертификат конечного субъекта, он же листовой сертификат (англ. End-Entity Certificate a.k.a Leaf Certificate): Тут всё непросто. Термин "конечный субъект" (в английском варианте могут использоваться как end-entity, так и end entity) изначально определяется в X.509, а затем в RFC 4949 и RFC 5280. Во всех случаях смысл в том, что сертификат конечного субъекта — это сертификат, в котором для защиты конечного субъекта, описанного в атрибуте CN= полей subject или subjectAltName, используется закрытый ключ (соответствующий открытому ключу, указанному в сертификате конечного субъекта). С другой стороны, иногда этот термин используется для указания на то, что закрытый ключ (соответствующий открытому ключу, указанному в сертификате конечного субъекта) не используется для подписи сертификатов, то есть, сертификат конечного субъекта не является промежуточным сертификатом, как правило, не является корневым (CA) сертификатом, и, следовательно, не используется в каком-либо процессе проверки подписи. Термин "листовой сертификат" используется для указания на то, что сертификат конечного субъекта, как правило, является последним сертификатом в цепочке. Сами решайте, помогают подобные термины понимать происходящее, или только мешают этому.

Мультихостовые сертификаты (англ. Multi-host certificates): Сертификат сервера обычно в поле subject содержит атрибут CN=hostname, например, CN=www.example.com. Имя хоста разрешается системой DNS, которая может выдавать для этого хоста несколько IP-адресов (если в DNS имеется несколько записей A или AAAA). В этом случае серверный сертификат X.509 (SSL) с одним и тем же именем хоста может быть реплицирован на все подобные хосты (очевидно, соответствующий закрытый ключ также должен быть реплицирован на каждый хост, что может представлять собой проблему при использовании аппаратных криптографических устройств, в этом случае некоторые УЦ с удовольствием продадут Вам дополнительные сертификаты (которые будут называться мультихостовыми) чтобы обойти эту проблему). Если же присутствует несколько имён хостов, таких как www.example.com, example.com или www1.example.com, в таком случае требуется специальных подход и специальные типы сертификатов, описанные ниже как мультидоменные сертификаты и сертификаты с возможностью подстановки.

Мультидоменные сертификаты (англ. Multi-domain certificates): Некоторые УЦ продают мультидоменные сертификаты, охватывающие несколько доменных имён, например, таких как www.example.com, example.com или даже www.example.net. Это достигается путём использования нескольких записей в поле subjectAltName и описывается далее. С технической точки зрения на этот процесс практически нет ограничений, например, в одном сертификате X.509 (SSL) могут поддерживаться www.example.com и www.example.net, но у большинства УЦ предусмотрены на это какие-либо коммерческие ограничения, которые, впрочем, обычно можно преодолеть путём дополнительных капиталовложений. Иногда для этих целей можно использовать описанные ниже сертификаты с возможностью подстановки, но имена хостов в таких сертификатах ограничены одним доменом.

Сертификаты с возможностью подстановки (англ. Wildcard certificates): Некоторые УЦ продают сертификаты с возможностью подстановки, в которых поле subject содержит CN=*.example.com (* — это шаблон подстановки). Такие сертификаты поддерживают любое имя хоста в составе домена, то есть *.example.com будет поддерживать www.example.com и mail.example.com, но не example.com и, очевидно, не example.net (для этих целей могут подойти описанные выше мультидоменные сертификаты).

Сертификаты EV (сертификаты расширенной валидации они же расширенные сертификаты, англ. EV (Extended Validation) Certificates a.k.a. Extended Certificates): Сертификаты EV отличаются наличием расширения CertificatePolicies, содержащего зарегистрированные OID в поле policyIdentifier. Подробнее сертификаты EV описаны ниже.

Сертификаты DV (сертификаты валидации домена, англ. DV (Domain Validation) Certificates): Некоторые УЦ выпускают то, что называется сертификатами валидации домена (DV). Этот термин не используется повсеместно. Подразумевается, что удостоверяющий центр подтверждает только тот факт, что лицо или организация, запросившая данный сертификат, является владельцем доменного имени. То есть значение CN= в полях subject или subjectAltName, например, www.example.com, может рассматриваться как верное, а вот информация об организации (C=, ST=, L=, OU= или O=) не должна рассматриваться как верная, и эти значения должны быть либо пустыми, либо содержать соответствующий текст, например, "not valid" ("неверно").

Сертификаты OV (сертификаты валидации организации, англ. OV (Organizational Validation) Certificates): Некоторые УЦ выпускают то, что называется сертификатами валидации организации (OV). Этот термин не используется повсеместно. Подразумевается, что удостоверяющий центр подтверждает тот факт, что лицо или организация, запросившая данный сертификат, является владельцем доменного имени, а также подтверждает предоставленные в сертификате сведения об организации. То есть значения CN=, C=, ST=, L=, OU= или O= в полях subject или subjectAltName могут рассматриваться как верные. Хотя на первый взгляд это выглядит весьма основательно, всё же такие сертификаты не дотягивают до уровня сертификатов EV, требующих дополнительных условий квалификации.

Внутридоменные сертификаты (англ. Domain-Only Certificates): Общий термин, обычно несёт негативную окраску, применяется к сертификатам, в которых процесс верификации конечного пользователя, с точки зрения тех, кто применяет данный термин, варьируется от поверхностного до вообще никакого.

Сертификаты защиты контента при цифровой передаче (Digital Transmission Content Protection, DTCP): Такие сертификаты выпускаются и управляются Администратором лицензирования цифровой передачи (Digital Transmission Licencing Administrator, DTLA — www.dtcp.com) и обычно используются Smart-телевизорами, медиа-плеерами и прочими подобными устройствами при проигрывании на них лицензионных материалов. Сертификаты DTCP не используют формат X.509, но они могут быть задействованы в протоколе рукопожатия TLS (RFC 7562). Далее в этом документе они не описываются.

Цепочки сертификатов X.509

Сертификаты X.509 могут формировать цепочки, то есть они могут быть подписаны одним или более промежуточными удостоверяющими центрами в иерархической манере, либо сертификат может быть просто подписан корневым УЦ напрямую. Концепция регистрационных центров (РЦ), выступающих в роли промежуточных подписывающих удостоверяющих центров, представлена в упомянутых выше RFC. Понятие "регистрационный центр (РЦ)" (иногда в стандартах EV именуемый "подчинённым УЦ"), вводится для описания организации, у которой на самом деле был приобретён сертификат X.509, например, лицензированного агента, сертификат которого подписан (возможно, также в результате иерархической цепочки подписания) удостоверяющим центром, представляющим собой УЦ самого верхнего уровня или корневой УЦ. По структуре чем-то похоже на операторов реестра DNS и регистраторов, если организация DNS Вам знакома. В RFC 4158 есть полезная, но крайне запутанная и неудобоваримая информация о том, как можно надёжно построить цепочку сертификатов с помощью пар полей subject и issuer, дополняя их, кроме всего прочего, полями SubjectKeyIdentifier и AuthorityKeyIdentifier.

Сертификат самого верхнего уровня в иерархии подписания называется корневым сертификатом, сертификатом УЦ или даже иногда корневым сертификатом УЦ. Корневые сертификаты получаются каким-либо доверенным способом (в случае браузеров они распространяются с программным обеспечением браузера и периодически обновляются) и при валидации цепочки сертификатов обычно называются якорями доверия. При получении от сервера в процессе рукопожатия TLS/SSL сертификата (или связки сертификатов) конечного субъекта, программа, получившая сертификат, должна проверить его и весь путь до корневого сертификата (сертификата УЦ), включая, при необходимости, все промежуточные сертификаты (которые, опять же, обычно распространяются с программным обеспечением браузера). Корневой сертификат (сертификат УЦ) распознаётся по наличию одинаковых значений в полях issuer и subject, по тому, что поле KeyUsage установлено в keyCertSign и/или в поле BasicConstraints атрибут cA установлен в TRUE. Процесс построения цепочки сертификатов описан в RFC 4158, валидация цепочки сертификатов описана в RFC 5280. Различные варианты подписания сертификатов показаны на рисунке 3:

Рисунок 3 — Цепочки сертификатов X.509

Использование сертификатов X.509

Издатель сертификата (issuer) идентифицируется с использованием формата Distinguished Name (DN, уникального имени), который в оригинале разрабатывался для представления расположения объекта в DIT (информационном дереве каталога) DAP или LDAP. DN не следует путать с сетевым адресом или URL/URI. Обычно DN имеет формат CN=Type of Certificate, OU=Certificate Division, O=Certificate Company name,C=Country (CN=, OU=, O=, C=), но может иметь и более простой формат OU=, O=, C=, или даже CN=, O=, C=, наконец (чтобы немного запутать ситуацию) он может иметь формат CN=, OU=, DC=, DC=. В общем, формат может быть разным — вариантов много. DN состоит из нескольких разделённых запятыми RDN (Relative Distinguished Names, относительных уникальных имён), то есть CN= или C= представляют собой RDN в составе DN. Сертификат X.509 не содержит URI для получения по сети каких либо сертификатов для образования цепочки, но он может содержать (в других полях) URI для получения CRL. Использующие сертификаты приложения, — к примеру, браузеры или почтовые клиенты, — должны заранее получить корневой сертификат, а если существует цепочка сертификатов, то и все промежуточные сертификаты, каким-либо способом, по сети или нет. Корневые сертификаты наиболее известных УЦ распространяются с браузерами (и доступны для соответствующих им почтовых клиентов), смотрите раздел "Работа с сертификатами в основных браузерах".

Примечание: Распространяемые с программным обеспечением большинства браузеров (и почтовых клиентов) корневые сертификаты добавляются в соответствии с критериями, определяемыми поставщиком браузера, и варьирующимися от "кто больше заплатит" до тотальной проверки легитимности УЦ и соответствия их другим требованиям.

При обращении приложения к сервису с поддержкой TLS/SSL, в процессе диалога рукопожатия TLS/SSL оно получает сертификат (или связку сертификатов) сервера. После этого приложение (например, браузер) выделит атрибут CN из DN в поле subject (и/или в поле subjectAltName, смотрите RFC 6125) для проверки субъекта (скажем, адреса веб-сервера, такого как www.example.com). Затем наше приложение будет использовать DN в поле issuer сертификата X.509 сервера для нахождения соответствующего корневого сертификата в своём локальном хранилище (и, если такового не обнаружено, генерации исключения — обычно в виде непонятного, пугающего пользователя диалога). Если найден валидный корневой сертификат, то тем самым подлинность предоставленного сервером сертификата считается установленной. В итоге (если всё прошло успешно) открытый ключ, содержащийся в сертификате X.509, считается безопасным (доверенным) и пригодным для проведения коммуникаций с указанным в поле subject субъектом.

Серверам обычно требуется только свой собственный сертификат (сертификаты) и не требуется корневых сертификатов — они просто посылают свои сертификаты клиенту, а валидации сертификатов не производят. Однако TLS/SSL позволяют проводить взаимную валидацию, в этом случае и сервер и клиент отправляют свои сертификаты. Если приложение требует, чтобы клиент предоставлял свой сертификат, то сервер должен будет произвести валидацию клиентского сертификата, для чего у него должны иметься все необходимые корневые и промежуточные сертификаты, полученные любым путём, например, по почте или с веб-сайтов удостоверяющих центров.

Рисунок 4 — Использование сертификатов X.509

Замечания по полям сертификата subject и subjectAltName

Сертификаты X.509 в организациях, предоставляющих услуги веб-хостинга

Владельцы веб-сайтов подвергаются значительному давлению по поводу внедрения шифрования на основе сертификатов X.509 (SSL). Источники этого давления обычно имеют благие намерения (но это не говорит о том, что они правы).

Когда владелец веб-сайта одновременно является и его оператором, такое внедрение не создаёт больших проблем. Владелец/оператор сайта просто должен определиться, является ли внедрение TLS экономически эффективным. С другой стороны, многие владельцы сайтов делегируют функции оператора сайта специалистам веб-хостинговых компаний (так называемые многопользовательские сайты). И тут может возникнуть более серьёзная проблема.

Так в чём же дело?

Проблема связана с выдачей сертификатов X.509, а также с владением закрытыми ключами, ассоциированными с этим сертификатом X.509. В частности, имеет место одна единственная (в большинстве случаев) транзакция (пункт 5 в последовательности обмена сообщениями протокола TLS), в которой требуется, чтобы у сервера был доступ к закрытому ключу соответствующего сертификата (напомним, что в асимметричной криптографии (с открытым и закрытым ключами) клиент шифрует сообщение с использованием открытого ключа, и только владелец закрытого ключа, — в данном случае сервер, — может расшифровать это сообщение).

Теперь представьте, что собственник example.com делегировал обслуживание веб-сайта с этим доменным именем веб-хостинговой организации, имеющей доменное имя example.net. Если браузер пользователя соединяется с TLS-сервисом на www.example.com, то он ожидает увидеть сертификат с именем www.example.com (то есть с именем того сайта, к которому он подключается). Если же он получит сертификат с именем www.example.net (доменное имя хостинговой организации), то будет немного расстроен (на самом деле он либо начнёт злорадно выдавать пользователю неприятные сообщения, либо подкрасит адресную строку угрожающим красным цветом).

Чтобы проблема не была такой острой, в RFC 6066 была введена SNI (Server Name Indication, индикация имени сервера), позволяющая клиенту (браузеру) явно указать в сообщении ServerHello, что он подключается к www.example.com, давая возможность нашему супер-умному серверу предоставлять ожидаемый сертификат (www.example.com). Победа! Браузер снова счастлив, ура!

Не так быстро.

Ни один нормальный удостоверяющий центр (CA) не выдаст сертификат для example.com какому-то там example.net. Только владелец домена (который должен тем или иным способом доказать своё право собственности) может получить сертификат на свой домен. Однако, как мы помним из пункта 5 последовательности обмена сообщениями протокола TLS, серверный хост должен иметь у себя не только сертификат, но и ассоциированный с ним закрытый ключ. Ой! Юристы уже радостно потирают руки! Ой-ой-ой!

В RFC 7711 предлагается решение, при котором пользователь (example.com) может (используя ресурсные записи DNS SRV) явно делегировать предоставление SSL-сертификата третьей стороны (в нашем случае example.net) для проверки подлинности своего сайта, путём указания на расположенную где-то на веб-хосте специально сформированную запись в формате JSON. Пользователю не нужно покупать безумно дорогой SSL-сертификат и, следовательно, не нужно предоставлять свой закрытый ключ хостинг-провайдеру. В теории, перед посещением веб-сайта пользователя наш браузер будет выполнять запрос DNS SRV, а затем, используя полученный URL, прочтёт запись делегирования (предположим, по логике нашего примера, в этой записи указано, что полномочия делегированы example.net). При получении этой информации, браузер с радостью примет сертификат от example.net при доступе к example.com. Наш браузер доволен, никаких неприятных сообщений и угрожающих цветов. Все счастливы, кроме, пожалуй, юристов.

Примечание: В этом же RFC опционально пользователю разрешается указать, что он намеренно предоставил своему хостинг-провайдеру свой сертификат X.509 (и, неявно, свой закрытый ключ).

У этой проблемы существует и другое возможное решение с использованием DNSSEC и DANE, когда-нибудь мы его тоже обязательно задокументируем. Только не надейтесь, что это будет скоро.

Дополнительные замечания по полям сертификата subject и subjectAltName

Протоколы, связанные с сертификатами (CMP, CMC/CMS, CRMF, SCVP, OCSP, HTTP)

Сертификат X.509 представляет собой структуру данных. Различные протоколы позволяют производить манипуляции с сертификатами через коммуникационную сеть. Такие операции с сертификатами X.509, как отправка запроса на подписание, получение подписанного сертификата и другие, определены, в частности, в протоколе управления сертификатами (Certificate Management Protocol, CMP, RFC 4210) и в PKCS #10 (RFC 2986), и описаны далее в этом руководстве.

Беглый обзор: Для манипуляций с сертификатами и списками отзыва сертификатов (Certificate Revocation Lists, CRL) определен ряд протоколов. Протокол управления сертификатами (Certificate Management Protocol, CMP, RFC 4210, обновлён в RFC 6712) предоставляет методы для манипуляции сертификатами (формат сообщений сертификатов (Certificate Request Message Format, CRMF) определён в RFC 4211). В RFC 4210 определено несколько коммуникационных методов (таких как HTTPS), которые могут быть использованы для транспортировки запросов сертификата по сети, но не дано явного определения транспортного протокола для обработки сертификатов (смотрите CMC/CMS ниже).

Протокол CMC/CMS (Certificate Management over CMS, управление сертификатами поверх CMS), определён в RFC 5272, RFC 5273, RFC 5274 и обновлён в RFC 6402, позволяет осуществлять безопасную транспортировку запросов сертификата от запрашивающей стороны к УЦ (включая любые промежуточные РЦ) и обратно. Формат сообщения может быть либо PKCS #10 (RFC 2896), либо CMRF (RFC 4211). Этот протокол следует называть CMC, но иногда его называют CMS. Технически, CMS — это Cryptographic Message Syntax (синтаксис криптографического сообщения), в котором описывается только формат конверта запроса и ответа (для PKCS #10 или CRMF). Данный протокол определяет ряд операций, которые могут быть выполнены над сертификатами, в том числе обновление якорей доверия (корневых сертификатов), поддерживаемых у запрашивающей сертификат стороны. Это большой и насыщенный (сложный) протокол.

Протокол онлайн-получения статуса сертификата (Online Certificate Status Protocol, OCSP, RFC 6960) — это протокол для онлайн-проверки подлинности сертификатов. RFC 6066 расширяет стандарт TLS чтобы клиент мог запрашивать OCSP-статус сертификата во время фазы протокола рукопожатия, а RFC 6961 определяет упрощённый формат 'certificate_request_v2', позволяющий снизить объёмы трафика сервера OCSP.

Протокол серверной валидации сертификатов (Server-Based Certificate Validation Protocol, SCVP, RFC 5055) позволяет делегировать недоверенному серверу некоторые клиентские функции, а именно построение и валидацию пути сертификации. Если же сервер SCVP является ещё и доверенным, то он может предоставлять дополнительную функциональность, например, проверку статуса сертификата (как OCSP) или получение промежуточных сертификатов (как CMP).

В RFC 4387 определены некоторые ограниченные манипуляции с сертификатами X.509, ключами и списками CRL по протоколу HTTP с использованием метода GET (как раз этот метод мы использовали, когда последний раз покупали сертификат X.509). RFC 4386 определяет использование DNS-записей SRV для обнаружения репозиториев сертификатов и сервисов OCSP.

Протокол управления сертификатами (Certificate Management Protocol, CMP)

Протокол управления сертификатами (CMP) определён в RFC 4210 (обновлён в RFC 6712), формат сообщений запроса сертификатов (Certificate Request Message Format, CRMF) определён в RFC 4211.

В дальнейшем описание будет расширено.

Протокол серверной валидации сертификатов (Server-Based Certificate Validation Protocol, SCVP)

В дальнейшем будет приведено описание. Варианты OCSP в значительной степени заменяют этот протокол.

Управление сертификатами поверх CMS (Certificate Management over CMS, CMC/CMS)

В дальнейшем будет приведено описание.

Протокол онлайн-получения статуса сертификата (Online Certificate Status Protocol, OCSP)

Протокол онлайн-получения статуса сертификата (OCSP) определён в RFC 6960, а переработанный, обеспечивающий высокую производительность формат сообщений определён в RFC 5019 (The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments (облегчённый профиль OCSP для крупномасштабных сред)). В этом формате существенно уменьшен размер OCSP-запросов для одного сертификата и исключено большинство необязательных (OPTIONAL) полей в запросах и ответах (смотрите примечание ниже). RFC 6960 (отменяющий действие RFC 2560 и RFC 6277) просто уточняет некоторые моменты в оригинальных RFC для достижения большей совместимости с RFC 5019, а также добавляет свои собственные, совершенно новые туманные места в спецификацию. В RFC 6961 определён новый формат 'certificate_request_v2', позволяющий серверам кэшировать (сохранять) ответы, а также позволяющий посылать в одном сообщении информацию о всех имеющих отношение к запросу сертификатах (включая промежуточные).

OCSP — это онлайн альтернатива спискам отзыва сертификатов (Certificate Revokation List, CRL). Если удостоверяющий центр поддерживает сервис OCSP, URI этого сервиса обычно указывается в поле AuthorityInfoAccess (AIA) сертификата (удостоверяющие центры, выпускающие сертификаты EV, обязаны поддерживать OSCP). Клиент отправляет запрос, опционально подписанный электронной подписью, идентифицирующий сертификат, который требуется проверить, и получает от сервера OCSP подписанный ответ, указывающий статус сертификата как действующий (good), отозванный (revoked) или неизвестный (unknown). В RFC разрешено передавать запросы и ответы посредством ряда различных транспортных протоколов (в частности, в качестве примеров упомянуты LDAP, SMTP и HTTP) с указанием конкретной транспортной схемы в URI поля AIA сертификата, подвергающегося проверке. Также RFC определяет формат сообщений HTTP (используются GET и POST) при транспортировке OCSP. Формат сообщений запроса и ответа:

# Формат запроса
OCSPRequest 
  TBSRequest
    version                      0 = v1
    requestorName                OPTIONAL
    requestList (один или несколько, в случае RFC 5019 - только один)
      reqCert
        hashAlgorithm            AlgorithmIdentifier
        issuerNameHash           Хэш DN издателя
        issuerKeyHash            Хэш открытого ключа издателя
        serialNumber             CertificateSerialNumber
        singleRequestExtensions  OPTIONAL
    requestExtensions            OPTIONAL
  optionalSignature              OPTIONAL

Примечания:

1. Подпись запроса OCSP является необязательной, и, если она присутствует, в поле requestorName должен быть указан субъект, подписавший сообщение. Очевидно, для проверки подписи у получателя сообщения должен быть открытый ключ субъекта, подписавшего сообщение (или его делегированного агента).

2. Поставщики сертификатов EV (Extended Validation) обязаны предоставлять сервис OCSP, для всех остальных типов сертификатов этот сервис является опциональным.

# Формат ответа
OCSPResponse
  responseStatus
    successful        0  -- ответ содержит корректный статус
    malformedRequest  1  -- неверный формат запроса
    internalError     2  -- внутренняя ошибка сервера издателя
    tryLater          3  -- повторите попытку позже
                         -- (4) не используется
    sigRequired       5  -- запрос должен быть подписан
    unauthorized      6  -- запрос неавторизован
  responseBytes       OPTIONAL
    responseType      OID (1.3.6.1.5.5.7.48.1.1 =BasicOCSPResponse)
      BasicOCSPResponse
       response       
        ResponseData
          version          0 - версия, по умолчанию v1
          responderID      ОДНО ИЗ ДВУХ:
            byName         1 - имя
            byKey          2 - хэш открытого ключа издателя
          producedAt       GeneralizedTime
          responses        
            certID         
              hashAlgorithm       AlgorithmIdentifier
              issuerNameHash      -- хэш DN издателя
              issuerKeyHash       -- хэш открытого ключа издателя
              serialNumber        CertificateSerialNumber
            certStatus       CertStatus
              good           0
              revoked        1
              unknown        2
            thisUpdate       GeneralizedTime
            nextUpdate       GeneralizedTime OPTIONAL
            singleExtensions OPTIONAL
          responseExtensions OPTIONAL
        signatureAlgorithm   AlgorithmIdentifier,
        signature            Хэш данных ответа
        certs                OPTIONAL

Примечания:

1. Статус good в поле certStatus согласно RFC означает "не отозван", но в полях расширения (Extensions) может быть доступна дополнительная информация.

2. Статус unauthorized в поле responseStatus указывает на то, что сервер, выдающий ответ, не имеет достоверной информации по этому сертификату.

3. В RFC 6960 определено несколько расширений для сообщений, кроме того, в них можно включать любые расширения CRL (RFC 2459).

4. Обычно ответ подписывается УЦ, издавшим сертификат, указанный в поле serialNumber, но протокол позволяет подписывать ответ делегированному удостоверяющему центру. В этом случае ответ должен включать сертификат (содержащий открытый ключ делегированного центра, подписавшего ответ) в поле certs, и этот сертификат должен быть подписан издателем сертификата, указанного в поле serialNumber.

5. RFC 5019 определяет усовершенствованный формат сообщений (полностью совместимый с полным форматом OCSP) путём исключения большинства необязательных (OPTIONAL) полей с целью снижения нагрузки на сеть при передаче сообщений. Нововведения в протоколе: поддержка OCSP поверх HTTP только с использованием методов GET и POST. Нововведения в запросах: запрос ограничивается единственным сертификатом (значение поля requestList будет 1), обходится без необязательного поля singleRequestExtensions, необязательных структур requestExtensions и optionalSignature (если запрос подписан, отвечающий сервер вправе проигнорировать подпись). Нововведения в ответах: путём принудительного ограничения на один сертификат в запросе, RFC 5019 уже уменьшает сложность (и размер) ответа, кроме того, исключено необязательное поле responseExtensions (но поле singleResponseExtensions может быть включено). Опять же, если ответ подписан делегированным УЦ, он должен включать сертификат (содержащий открытый ключ делегированного центра, подписавшего ответ) в поле certs, и этот сертификат должен быть подписан издателем сертификата, указанного в поле serialNumber.

Узкие места OCSP

OCSP разрабатывался как система реального времени (в противоположность пакетной природе классических списков CRL), так что теоретически клиенты могут проверить статус любого сертификата до его принятия и использования. В частности, при обработке сертификата EV любая реализация клиента (например, браузер) в буквальном смысле обязана выполнить OCSP-проверку чтобы реализовать концепцию безопасности EV. Это означает, к примеру, что в результате каждого обращения к сервису HTTPS может (а в случае EV должна) происходить дополнительная проверка УЦ посредством обращения к сервису OCSP. Поскольку всё больше сайтов реализуют благонамеренную, но, по существу, ошибочную политику использования HTTPS для всего подряд (вместо того, чтобы настроить более значимый и надёжный сервис DNSSEC), производительность серверов OCSP резко снижается и они просто встают на колени от своего рода DDoS-атаки (хоть и из благих побуждений).

RFC 6066 расширяет стандарт TLS, чтобы клиент мог запрашивать статус сертификата у сервера TLS (OCSPStatusRequest), тем самым, возможно, ещё более усугубляя проблему загрузки OCSP, упростив реализацию опроса OCSP и поощряя каждого клиента его выполнять. В RFC 6961 предпринята попытка решить проблему загрузки OCSP путём использования нового запроса TLS 'certificate_request_v2', который, предположительно, позволяет (хотя при опросе OCSP сервер не обязательно должен придерживаться такого поведения) кэшировать ответы OCSP на сервере (снижая тем самым загрузку OCSP из-за проверок достоверности в режиме реального времени) и посылать несколько сообщений о статусе сертификатов (включая все промежуточные сертификаты) в одном блоке. И наконец (мы на это надеемся, что это будет конец), поскольку многочисленные промежуточные сертификаты могут в сумме иметь серьёзный размер, в RFC 7924 определён метод, с помощью которого клиент может сообщить серверу, что у него уже есть все необходимые для проверки промежуточные сертификаты.

Формат сертификата X.509

В этом разделе в умопомрачительных (но не всеобъемлющих) подробностях описывается формат и назначение основных полей (технически называемых атрибутами) сертификата X.509. Этот формат определён в RFC 5280 (обновлён в RFC 6818).

Сертификат X.509 представляет собой структуру ASN.1, закодированную с помощью определённых в X.690 уникальных правил кодирования (Distinguished Encoding Rules, DER), и включающую в себя многочисленные ссылки на глобально уникальные идентификаторы объектов (Object Identifiers, OID).

Примечания:

1. В X.509 (и LDAP) многие используют бестолковую псевдоВенгерскую нотацию (или lowerCamelCase, если Вы предпочитаете этот термин). В общем случае стоит помнить, что плохие реализации X.509 чувствительны к регистру символов, хорошие — нет. Более того, все правила соответствия LDAP, относящиеся к манипулированию DN, являются нечувствительными к регистру; это означает, что имена атрибутов нечувствительны к регистру.

2. RFC 7250 определяет упрощённый формат сертификата для случаев, когда открытый ключ был получен в результате других доверенных процессов (возможно, офф-лайн). Этот минимальный формат сертификата использует только атрибут subjectPublicKeyInfo (и два его подполя). О том, что будет применяться данный минимальный формат сертификата, указывается в сообщениях ClientHello и ServerHello в ходе рукопожатия TLS/SSL.

Выводимый OpenSSL сертификат X.509 выглядит так (основные поля описаны ниже):

Certificate:
 Data:
  Version: 3 (0x2)
  Serial Number:
   bb:7c:54:9b:75:7b:28:9d
  Signature Algorithm: sha1WithRSAEncryption
  Issuer: C=MY, ST=STATE, O=CA COMPANY NAME, L=CITY, OU=X.509, CN=CA ROOT
  Validity
   Not Before: Apr 15 22:21:10 2008 GMT
   Not After : Mar 10 22:21:10 2011 GMT
  Subject: C=MY, ST=STATE, L=CITY, O=ONE INC, OU=IT, CN=www.example.com
  Subject Public Key Info:
   Public Key Algorithm: rsaEncryption
    RSA Public Key: (1024 bit)
     Modulus (1024 bit):
      00:ae:19:86:44:3c:dd...
      ...
      99:20:b8:f7:c0:9c:e8...
      38:c8:52:97:cc:76:c9...
   Exponent: 65537 (0x10001)
 X509v3 extensions:
  X509v3 Basic Constraints: 
   CA:FALSE
 Netscape Comment: 
  OpenSSL Generated Certificate
 X509v3 Subject Key Identifier: 
  EE:D9:4A:74:03:AC:FB...
 X509v3 Authority Key Identifier: 
  keyid:54:0D:DE:E3:37...

 Signature Algorithm: sha1WithRSAEncryption
  52:3d:bc:bd:3f:50:92...
  ...
  51:35:49:8d:c3:9a:bb...
  b8:74

Примечание: В приведённом сертификате строки, мало что дающие для понимания материала, были обрезаны или даже пропущены (места пропусков обозначены многоточиями).

Сертификат X.509 состоит из следующих полей (атрибутов):

# Разбиение на две строки показано исключительно для удобства
C=MY,ST=some state,L=some city,O=Expensive Certs inc,
 OU=X.509 certs,CN=very expensive certs
# Существуют различные интерпретации полей RDN,
# далее представлены общепринятые значения.
# C  = двухбуквенный код страны согласно ISO3166
# ST = штат или область (край)
# L  = местоположение, обычно - город
# O  = организация - название компании
# OU = подразделение организации, обычно - тип сертификата или бренд
# CN = общепринятое имя, обычно - наименование продукта или бренд

# Разбиение на две строки показано исключительно для удобства
C=MY,ST=another state,L=another city,O=my company,OU=certs,
 CN=www.example.com
# Существуют различные интерпретации полей RDN,
# далее представлены общепринятые значения.
# В случае персонального сертификата в этом поле могут встречаться
# GN=, SN= или pseudonym=
# C  = двухбуквенный код страны согласно ISO3166
# ST = штат или область (край)
# L  = местоположение, обычно - город
# O  = организация - название компании
# OU = подразделение организации, обычно - подразделение или наименование группы объектов
# CN = общепринятое имя, обычно - наименование конечного субъекта, например www.example.com

# Разбиение на две строки показано исключительно для удобства
C=MY,ST=some state,L=some city,O=Expensive Certs inc,
 OU=X.509 certs,CN=www.example.com

1.2.840.113549.1.1.1

AuthorityInfoAccess = AuthorityInfoAccessSyntax
# могут существовать несколько элементов AuthorityInfoAccessSyntax,
# каждый состоит из:
 accessMethod  = OID
# может принимать значения:
# 1.3.6.1.5.5.7.48.1 = ocsp
# accessLocation = URI сервиса OCSP УЦ
# для УЦ-издателя
# 1.3.6.1.5.5.7.48.2 = caIssuers
# используется только если сертификат подписан не корневым УЦ
# accessLocation = URI описания корневого УЦ

 accessLocation = URI (исключительно адрес электронной почты
                       или X.500 DirectoryString)

keyIdentifier             (0) KeyIdentifier
authorityCertIssuer       (1) GeneralNames
authorityCertSerialNumber (2) CertificateSerialNumber

digitalSignature (0)
nonRepudiation   (1)
keyEncipherment  (2)
dataEncipherment (3)
keyAgreement     (4)
keyCertSign      (5) # указывает на то, что это сертификат УЦ
cRLSign          (6)
encipherOnly     (7)
decipherOnly     (8)

serverAuth  (1) TLS-аутентификация сервера WWW
      (действительно с digitalSignature, keyEncipherment или keyAgreement)
clientAuth  (2) TLS-аутентификация клиента WWW
      (действительно с digitalSignature или keyAgreement)
codeSigning (3) Подписание доступного для скачивания исполняемого кода
      (действительно с digitalSignature)
emailProtection (4)  Защита электронной почты
      (действительно с digitalSignature, nonRepudiation, 
       и/или (keyEncipherment или keyAgreement))
timeStamping (8) Привязка хэша объекта ко времени
      (действительно с digitalSignature и/или nonRepudiation)
OCSPSigning (9) Подписание ответов OCSP
      (действительно с digitalSignature и/или nonRepudiation)

cA               TRUE | FALSE
pathLenConstraint   INTEGER

# (O) = OPTIONAL
distributionPoint  DistributionPointName (O)
# points to a structure defined below
reasons            ReasonFlags (O)
cRLIssuer          GeneralNames (O)
# DN издателя CRL, если он не совпадает с 
# издателем сертификата.
# Данное DN может использоваться в поисковых запросах LDAP

# DistributionPointName может быть ЛИБО
fullName                  GeneralNames 
# может содержать URI,
# например, http://crl.example.com,
# или название протокола, например, HTTP, LDAP, FTP и т.п.
# используемого для получения CRL
# ЛИБО
nameRelativeToCRLIssuer
# RDN, добавляемое к DN издателя для получения CRL

# ReasonFlags может принимать одно из следующих значений:
unused                  0
keyCompromise           1
cACompromise            2
affiliationChanged      3
superseded              4
cessationOfOperation    5
certificateHold         6
privilegeWithdrawn      7
aACompromise            8

policyIdentifier   CertPolicyId # OID
policyQualifiers  # разрешено несколько значений
                  # обычно представляет собой URI на текстовое 
                  # изложение политики или просто текст

otherName                  Пары type=, value=
                           включая имена Kerberos (RFC 4556):
                            oid = 1.3.6.1.5.2.2
                            kerberos-principal (IA5String)
                           ИЛИ
                           SRVName (RFC 4985):
                            oid = 1.3.6.1.5.5.7.8.7
                            srv-name (IA5String)
rfc822Name                 email me@example.com
dNSName                    DNS-имя host1.example.com
x400Address                Почтовый адрес X.400,
                           если Вы в курсе, что это
directoryName              Альтернативный DN
ediPartyName               Материалы EDI
uniformResourceIdentifier  URI ldap://ldap.example.com
iPAddress                  IP V4/V6 192.168.0.1
registeredID               OID

1.2.840.113549.1.1.5

Все поля, за исключением SignatureAlgorithm и SignatureValue закодированы с помощью правил кодирования ASN.1 DER (Distinguished Encoding Rules), определённых в стандарте X.690 ITU-T. Цифровая подпись охватывает все закодированные DER поля, кроме, очевидно, самой себя.

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

Замечания по полям сертификата subject и subjectAltName

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

Проверка доменного имени по сертификатам X.509

В RFC 6125 определяется набор правил, цель которых — уменьшить путаницу между клиентами, серверами и УЦ, выдающими сертификаты, по вопросу того, как следует описывать или как могут быть описаны конечные субъекты в атрибутах subject и subjectAltName. (В RFC 6186 описан способ обнаружения хоста электронной почты с помощью ресурсных записей SRV DNS, а в RFC 7817 разъясняются требования RFC 6125 в отношении протоколов, связанных с электронной почтой). Исторически конечные субъекты определялись в RDN CN= атрибута subject, и хотя это до сих пор поддерживается (в основном по историческим соображениям), в RFC 6125 предпочтительным названо использование атрибута subjectAltName, позволяющего обеспечить большую гибкость и ясность. RFC 6125 определяет четыре возможности для проверки конечной системы:

Примечание: Во всех случаях при использовании subjectAltName может присутствовать более одного типа имени. Кроме того, может быть определено более одного субъекта для каждого типа имени. Конечные субъекты, описанные во всех присутствующих типах, образуют совокупность конечных субъектов данного сертификата. В случае использования поля subject действие сертификата распространяется только на одного конечного субъекта, описанного в RDN CN= (хотя в этом случае также может присутствовать атрибут subjectAltName).

1. В поле subjectAltName содержится атрибут типа dNSName. В этом случае указанное имя представляет собой имя конечного субъекта, на которого распространяется действие данного сертификата.

   В RFC 7817 сказано, что для электронной почты в качестве конечного субъекта следует указывать либо доменную часть адреса электронной почты (RFC822), к примеру, для адреса user@example.com конечным субъектом будет example.com, и/или в качестве конечного субъекта может быть указано FQDN хоста, получающего электронную почту, например, mail.example.com.

2. В поле subject содержится едиственное значение атрибута CN, например, cn=hostname (могут также присутствовать другие RDN, но при проверке доменного имени они игнорируются). В этом случае hostname представляет собой имя конечного субъекта, на которого распространяется действие данного сертификата.

   В RFC 7817 сказано, что для электронной почты в качестве конечного субъекта следует указывать либо доменную часть адреса электронной почты (RFC822), к примеру, для адреса user@example.com конечным субъектом будет example.com, и/или в качестве конечного субъекта может быть указано FQDN хоста, получающего электронную почту, например, mail.example.com.

3. В поле subjectAltName содержится атрибут типа otherName, а значение type самого атрибута otherName установлено в SRV (oid = 1.3.6.1.5.5.7.8.7) (определено в RFC 4985).

   В RFC 6186 определён порядок использования ресурсных записей DNS SRV для нахождения сервисов, связанных с электронной почтой (формат довольно странный). Эти рекомендации используются в RFC 7817.

4. В поле subjectaltName содержится атрибут типа uniformResourceIdentifier. В этом случае тип сервиса определяется явно.

Списки отзыва сертификатов (Certificate Revocation Lists, CRL)

Списки отзыва сертификатов (CRL) — метод, с помощью которого сертификаты могут быть признаны недействительными до наступления даты, указанной в поле NotAfter сертификата. Обычно CRL выпускаются тем же УЦ, который выпустил и сам сертификат. CRL могут быть получены различными методами, например, посредством LDAP, HTTP или FTP. Формат CRL (в частности CRLv2, текущая версия) определён в RFC 5280, а затем обновлён в RFC 6818.

Теоретически, при получении сертификата от сервера, программное обеспечение, получившее сертификат, должно проверить, что этот сертификат отсутствует в CRL (не был отозван). Чтобы свести к минимуму возможность ошибочного приёма отозванного сертификата, каждый раз при получении сертификата от сервера должна быть получена последняя версия CRL. Поскольку CRL содержит список всех отозванных сертификатов какого-либо УЦ, он может быть внушительных размеров и создавать, таким образом, неприемлемую избыточность трафика при первоначальном соединении TLS/SSL. Кроме того, в зависимости от политики удостоверяющего центра, CRL могут обновляться каждый час, 12 часов, раз день и т.д. Суть в том, что полученные файлы CRL, даже если мы запрашиваем их снова и снова при каждом получении сертификата, всё равно могут содержать просроченные данные.

На практике получение CRL каждый раз при проверке сертификата выполняется довольно редко (если вообще выполняется), многие системы полагаются на кэши CRL, которые периодически обновляются. В RFC 5280 для описания частоты обновления CRL используется обтекаемый термин suitably-recent (достаточно свежие) . Онлайн версия списков отзыва, известная как Online Certificate Status Protocol (OCSP), определена в RFC 2560, переработана в RFC 5019 и обновлена в RFC 6277. Формат CRL:

userCertificate      CertificateSerialNumber
revocationDate       Time
crlEntryExtensions   Extensions OPTIONAL

1.2.840.113549.1.1.5

Процесс доверия — удостоверяющие центры и сертификаты X.509

Как было сказано выше, сертификат X.509 является доверенным источником открытого ключа субъекта, указанного в сертификате (обычно указывается в атрибуте CN поля subject или в дополнении subjectAltName). Доверие формируется во время процесса создания сертификата. В зависимости от УЦ, процесс получения сертификата X.509 будет различаться в деталях, но, в общем случае, он состоит из следующих шагов:

1. Первое (самого высокого уровня) звено в цепи доверия — это удостоверяющий центр (УЦ). УЦ считаются доверенными организациями либо потому, что они сами так заявляют, либо потому, что они удовлетворяют каким-либо стандартам. Самой признанной организацией в сфере стандартизации УЦ в Северной Америке является WebTrust, и большинство УЦ указывают в документации, что они подвергались ревизии аккредитованным аудитором WebTrust (хотя в последнее время всё чаще подобные проверки выполняют и другие крупные международные аудиторские конторы). Сам факт основания УЦ является первым шагом в создании линии доверия. В какой-то момент времени УЦ генерирует одну или несколько пар асимметричных ключей и с помощью закрытого ключа выпускает самоподписанный сертификат (поля issuer и subject данного сертификата X.509 совпадают и в расширении BasicConstraints cA установлен в TRUE). Этот сертификат является корневым сертификатом удостоверяющего центра, а закрытый ключ, парный к которому открытый ключ содержится в корневом сертификате, используется для подписания пользовательских сертификатов. Корневые сертификаты (или сертификаты УЦ) распространяются среди конечных пользователей посредством какого-либо доверенного процесса, чаще всего с инсталлятором браузера.

2. Пользователь, желающий получить сертификат, рассматривает продукты различных удостоверяющих центров (УЦ) и выбирает наиболее подходящий для него УЦ. Выбранному УЦ (или одному из его агентов — регистрационных центров (РЦ)) подаётся заявка на конкретный тип сертификата SSL (X.509). В зависимости от типа сертификата затребывается и (как правило) проверяется различная информация, такая как наименование бизнеса, регистрационный номер бизнеса или иная идентификационная информация. Опять же, в зависимости от типа сертификата, могут быть затребованы дополнительные подтверждения идентичности. В основном вся эта информация подвергается ручной обработке (хотя процесс может быть в большей или меньшей степени автоматизирован). В результате этих проверок устанавливается следующее звено в цепи доверия.

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

3. После выбора продукта SSL, предоставления необходимой идентификационной информации и проверки её удостоверяющим центром, пользователю предлагается сгенерировать набор асимметричных ключей и с помощью закрытого ключа подписать запрос на подписание сертификата (Certificate Signing Request, CSR), в котором, кроме прочей информации, будет содержаться открытый ключ из сгенерированной пары ключей. Формат CSR определён в RFC 2986 (перепубликация стандарта RSA, PKCS#10, обновлён в RFC 5967) и содержит следующие данные:

   Version	Version 0.
   Subject	DN, определяющее субъекта, который будет ассоциирован с сертификатом. В общем случае, в зависимости от политик УЦ, это должно быть то значение, которое будет помещено в поле subject возвращаемого сертификата X.509.
   SubjectPublicKeyInfo	Содержит два подполя (атрибута): algorithm (OID алгоритма шифрования с открытым ключом из списка, определённого в RFC 3279) и subjectPublicKey (открытый ключ субъекта в виде битовой строки). Пример OID алгоритма RSA (rsaEncryption): 1.2.840.113549.1.1.1
   Attributes	Необязательное поле. Может содержать несколько подполей (атрибутов), пока определены следующие: challengePassword (пароль для дополнительной защиты CSR — большинство УЦ настаивают, чтобы этот атрибут НЕ присутствовал) и unstructuredName (любой подходящий текст — опять же, обычно УЦ не требуют его наличия или игнорируют, если таковой имеется).
   SignatureAlgorithm	Алгоритм (идентифицируемый по OID), используемый для подписания CSR, и любые ассоциированные с ним параметры. Например, OID цифровой подписи RSA с SHA1 (sha1WithRSAEncryption): 1.2.840.113549.1.1.5 Примечания: CSR подписывается с помощью закрытого ключа из пары закрытого и открытого ключей, соответствующий открытый ключ помещается в поле SubjectPublicKeyInfo этого CSR. Расширения сертификата, которые будут присутствовать в итоговом сертификате, могут также указываться, если этот сертификат будет самоподписанным. Некоторые коммерческие УЦ поддерживают расширения.
   SignatureValue	Битовая строка, содержащая цифровую подпись.

   Процедура создания CSR описана далее.

4. CSR загружается на сервер УЦ (обычно по FTP или HTTP). УЦ использует данные из CSR и, возможно, другую информацию, полученную из заявки на сертификат SSL, для создания сертификата X.509 пользователя, обычно со сроком действия от 1 до 3 лет. Наконец, УЦ подписывает сертификат пользователя (поля SignatureAlgorithm и SignatureValue) используя закрытый ключ, парный к которому открытый ключ содержится в корневом сертификате УЦ. Сертификат X.509 тем или иным способом (FTP/HTTP/EMAIL) отправляется пользователю.

5. Таким образом, цикл доверия завершается цифровой подписью удостоверяющего центра. Цифровая подпись пользовательского сертификата может быть верифицирована только с помощью открытого ключа издателя (поле issuer), который содержится в корневом сертификате УЦ, получаемом путём какого-либо (доверенного) процесса (обычно с инсталлятором браузера).

При получении браузером сертификата от веб-сайта (во время протокола рукопожатия TLS/SSL) должен быть проверен весь путь вплоть до корневого сертификата (сертификата УЦ). На этом пути может быть один или несколько уровней сертификатов, в зависимости от поставщика сертификата. Корневые сертификаты (сертификаты УЦ), а также какие-либо необходимые промежуточные сертификаты, обычно распространяются в составе программного обеспечения основных браузеров. Распространяемые таким способом корневые сертификаты (сертификаты УЦ) часто называются якорями доверия — широко распространённый термин, используемый для описания любой базовой структуры или информации, полученной путём доверенного распространения, с помощью которой можно проверить/аутентифицировать полученную информацию. В RFC 5914 (и немного в RFC 5937) определено, каким образом могут быть организованы, использованы и обработаны такие якоря доверия в конкретных случаях применения сертификатов X.509/SSL.

Сертификаты EV

Сертификаты расширенной валидации (Extended Validation, EV) определены CA/Browser Forum и включают в себя сочетание продвинутых методов канцелярских проверок и технических процессов. Цель сертификатов EV — обеспечение повышенного доверия к конечным пользователям, хотя в стандартах прямо заявляется, что эти сертификаты не гарантируют, что владелец сертификата занимается заявленной деятельностью (бизнесом) — только то, что владелец действительно существует.

В браузерах, поддерживающих сертификаты EV, при защищённом соединении пользователь видит обычный значок замка, но при применении сертификата EV строка состояния подсвечивается зелёным цветом. В настоящий момент сертификаты EV поддерживают следующие браузеры: MSIE (только 7) и последние версии Konqueror, Firefox (v3+) и Opera(9.5+). Обычно сертификаты EV значительно дороже, нежели другие типы сертификатов. Характеристики стандарта издания сертификатов EV:

1. Удостоверяющий центр должен быть аттестован на соответствие EV и подвергаться ежегодной переаттестации.

2. При расширенной проверке пользователя, кроме всего прочего, требуется, чтобы УЦ убедился, что пользователь, подавший заявку, действительно является владельцем того доменного имени, аутентификацию которого он стремится получить!

3. Удостоверяющие центры следуют практикам, изложенным в RFC 3647, который имеет статус информационного (INFORMATIONAL), то есть все остальные могут его не придерживаться.

4. Стандартизируется использование и значение некоторых атрибутов DN в поле subject, а также добавляются несколько новых. В частности, следующие атрибуты определены как требуемые (REQUIRED) — эквивалент ключевого слова MUST из RFC в стандартах EV:

   1. O - organizationalName (OID 2.5.4.10). Полное юридическое название организации пользователя.
   2. businessCategory (OID 2.5.4.15). Определяет, какие категории сертификатов могут подойти, могут быть разделы 5b, 5c или 5d.
   3. C - Country - (OID 2.5.4.6), ST - stateOrProvinceName - (OID 2.5.4.8) и L - localityName - (OID 2.5.4.7). Значения всех этих атрибутов должны соответствовать легальной юрисдикции бизнес-субъекта (а не, скажем, расположению веб-сервера).
   4. serialNumber (OID 2.5.4.5). Регистрационный номер бизнеса.
   5. CN - CommonName - (OID 2.5.4.3). Доменное имя хоста, например, www.example.com.

5. Обязательное требование: предоставление EV-удостоверяющими центрами онлайновых (24x7) возможностей проверки статуса любого сертификата EV. Обычно это достигается путём использования Online Certificate Status Protocol (OCSP) (RFC 2560).

6. Обязательное требование: сертификаты EV могут выдаваться только для аутентификации серверов (по крайней мере пока), то есть в атрибуте CN= должно быть имя сервера, такое как www.example.com или mail.example.com.

7. Точное указание на то, что это именно сертификат EV, производится путём использования зарегистрированного OID (уникального для каждого УЦ) в поле CertificatePolicies.

Примеры — самоподписанные сертификаты

В этом разделе показано использование команд OpenSSL для выполнения задач, связанных с сертификатами X.509. Для иллюстрации всех функций работы с сертификатами он охватывает генерацию того, что в просторечии называется самоподписанными сертификатами. Термин "самоподписанные" требует небольшого разъяснения, поскольку у него два потенциальных значения.

Если подходить строго, то этот термин означает сертификат, в котором значения полей issuer и subject совпадают. В этом смысле все корневые сертификаты являются самоподписанными. Второе значение — то, когда пользователь становится сам себе удостоверяющим центром (УЦ), что является альтернативой покупке сертификата X.509 у официально признанных УЦ, таких как Verisign или Thawte (и других), которые уже являются доверенными (их корневые сертификаты (сертификаты УЦ) предустанавливаются на компьютер пользователя основными инструментами работы с сертификатами, например, браузерами). Полученный браузером с веб-сайта во время фазы протокола рукопожатия TLS/SSL сертификат пользователя (конечного субъекта), изданный одним из официально признанных УЦ, может быть отслежен (и, следовательно, аутентифицирован) браузером вплоть до удостоверяющего центра (УЦ) с использованием поля issuer полученного сертификата. Чтобы браузер не выводил сообщений об ошибках, должен быть предустановлен корневой сертификат УЦ (а также любые промежуточные сертификаты). Для определения установленных сертификатов используется термин якорь доверия. Корневые сертификаты большинства коммерческих УЦ и многих национальных УЦ распространяются и инсталлируются с программным обеспечением браузеров, таких как MSIE, Firefox, Opera и т.д.

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

Когда программное обеспечение с поддержкой TLS/SSL (браузер) впервые встречает самоподписанный сертификат и подразумевается, что у браузера нет копии соответствующего корневого сертификата, будет сгенерировано сообщение, спрашивающее пользователя, желает ли он принять сертификат. С другой стороны, самоподписанный корневой сертификат может быть предустановлен или импортирован на компьютер пользователя, в этом случае браузер не будет генерировать сообщения об ошибке.

Примечание по срокам действия сертификатов и размерам ключей: Большинство сертификатов, описанных в последующих подразделах, имеют срок действия от 1 до 3 лет. Однако, большинство коммерческих корневых сертификатов, поставляемых с браузерами, имеют сроки действия от 10 до 20 лет! Нет ничего страшного в использовании достаточно длительных сроков действия сертификатов, чтобы не беспокоиться об их постоянном перевыпуске. Текущая (2011 год) рекомендация по длине ключа RSA, — 2048 бит, — действительна до 2030 года (вследствие чего срок действия многих ныне действующих корневых сертификатов истекает около 2028 года, давая им запас времени в пару лет для увеличения размера ключа, прежде чем ключи размером 2048 бит не перестанут быть легитимными в 2030 году). Рекомендации RSA по силе и требуемым срокам действия ключей. Аналогичные рекомендации по размеру (2048 бит) и срокам действия (до 2030 года) ключей также содержатся в специальной публикации 800-57, часть 1, ревизия 2, таблица 4 Национального института стандартов и технологий США (National Institute of Standards and Technology, US NIST).

Обзор процесса

В приведённых далее последовательностях действий используются команды OpenSSL (тестировалось с OpenSSL 0.9.8n и 1.0.0e) для генерации самоподписанных сертификатов X.509, которые могут быть установлены и использованы серверными системами TLS/SSL, такими как веб, FTP, LDAP или почтовыми системами (агентами SMTP). Команды OpenSSL используют множество параметров, в том числе ответы по умолчанию, сроки действия и поля сертификатов, из файла openssl.cnf (в FreeBSD — /etc/ssl/openssl.cnf), и если Вы собираетесь работать с сертификатами всерьёз, стоит просмотреть и, по мере необходимости, отредактировать этот файл, чтобы потом меньше было печатать параметров в командной строке.

Примечание: Есть серьёзные опасения, что ошибки, допущенные при редактировании openssl.cnf или при экспериментах с CA.pl (полезный скриптовый файл), могут привести к падению небес на землю. Сделайте резервную копию обоих файлов, прежде чем начинать что-либо делать, тогда Вы в любой момент сможете вернуть Вашу систему в первоначальное состояние, если что-то пойдёт не так. Помните: всё что Вы делаете, Вы делаете на свой страх и риск.

Создаваемые при работе с сертификатами файлы будут содержать либо открытые ключи, которые обычно не требуют особенной защиты, либо закрытые ключи, которые необходимо хорошо защищать. Будут ли оба типа файлов храниться в одной структуре каталогов или нет — зависит от локальной политики безопасности. Многое также зависит от требований окружения. Как и с любым сложным программным обеспечением, существует огромное множество способов что-либо сделать, но из них лишь два-три могут оказаться действительно полезными методами (Really Useful Methods, RUM™).

Примечание по работе в FreeBSD: На свежеустановленной FreeBSD 8.1 в установке openssl по умолчанию (0.9.8n) отсутствует скрипт CA.pl. Если Вы запрашивали инсталляцию исходных кодов, то его можно найти в /usr/src/crypto/openssl/apps/CA.pl. Другой вариант — использовать систему портов (/usr/ports/security/openssl), а затем выполнить make patch (просто скачать и распаковать openssl, но не устанавливать его), после чего найти скрипт с помощью find ./ -name "CA.pl". Поскольку PERL в FreeBSD больше не устанавливается по умолчанию, его нужно установить самостоятельно.

1. Метод 1: Быстрое создание корневого сертификата и сертификата сервера.

2. Метод 2: Быстрое создание единого сертификата, который будет корневым сертификатом и сертификатом сервера.

3. Метод 3: Корневой сертификат УЦ и несколько сертификатов.

4. Метод 3A: Создание подчинённых УЦ, промежуточных сертификатов и кросс-сертификатов.

Метод 1: Корневой сертификат, сертификат сервера

Создаётся сертификат УЦ, то есть корневой сертификат, который можно импортировать в браузер в целях тестирования, а также один сертификат сервера, который может быть использован сервером, например, Apache. Для упрощения процесса используется стандартный скрипт OpenSSL CA.pl (для упрощения примеров мы переместили его в /etc/ssl, Вы же указывайте своё расположение).

Примечание: Для генерации сертификатов, которые можно было бы использовать с несколькими именами сервера, например, example.com, www.example.com или www.example.net требуется процесс, описанный ниже.

# По умолчанию используется алгоритм RSA с ключами 1024 бит (2011 год).
# О том как изменить значения по умолчанию смотрите в пункте 1 метода 3.
# Создаём директории и самоподписанный корневой сертификат УЦ:
cd /etc/ssl
./CA.pl -newca
# Запрашиваемая здесь последовательность атрибутов относится к DN УЦ.
# По умолчанию корневой сертификат создаётся в
# demoCA/cacert.pem 
# а закрытый ключ УЦ в
# demoCA/private/cakey.pem
# Срок действия cacert.pem - 3 года

./CA.pl -newreq
# Создаём запрос на подписание сертификата (CSR)
# Запрашиваемая последовательность атрибутов относится к DN сервера
# Важно лишь значение атрибута CN (CommonName),
# где следует указать имя веб-сервера или другого сервера,
# например, www.example.com, ldap.example.com или mail.example.com

./CA.pl -sign
# Подписываем CSR и оставляем сертификат в
# /usr/local/openssl/newcert.pem
# Срок действия newcert.pem - 1 год.
# Закрытый ключ в
# /usr/local/openssl/newkey.pem

# Удаляем парольную фразу из newkey.pem
# чтобы сервер не запрашивал пароль при загрузке
openssl rsa -in newkey.pem -out keyout.pem

# ВНИМАНИЕ: этот файл содержит закрытый ключ, и права только на чтение
# должны быть только у владельца этого файла

# Переместите и переименуйте файлы согласно требованиям сервера.
# Необходимы оба файла newcert.pem и keyout.pem.
# Пример для apache:
SSLCertificateFile /path/to/newcert.pem
SSLCertificateKeyFile /path/to/keyout.pem
# Пример для OpenLDAP:
TLSCACertificateFile /path/to/cacert.pem
TLSCertificateFile /path/to/newcert.pem
TLSCertificateKeyFile /path/to/keyout.pem

Дополнительные пояснения и примечания смотрите далее. Файл demoCA/cacert.pem, являющийся корневым сертификатом, может быть скопирован и импортирован в браузер.

Метод 2: Только сертификат сервера

Это самый простой (в одну команду) путь создания сертификата X.509, который можно будет использовать и как сертификат сервера, и как корневой сертификат (сертификат УЦ). Поскольку этот сертификат самоподписанный (и присутствует поле CA:True), он может быть импортирован в браузер или другое клиентское ПО как корневой сертификат (сертификат УЦ). Запрашиваемая последовательность атрибутов относится к DN того сервера, для которого генерируется сертификат. В частности, атрибут CN должен определять имя хоста сервиса, такое как www.example.com, а не имя хоста компьютера. То есть, если веб-сервис имеет адрес https://www.example.com, а выполняется на хосте webserver.example.com, следует использовать CN=www.example.com. Далее показан стандартный диалог OpenSSL, значения #обрамлённые_знаками_решётки# должны быть заменены на требуемые, например, #имя_сервера# следует заменить на действительное имя сервера, который подлежит аутентификации, скажем, www.exmple.com или ldap.example.com.

Примечание: Для генерации сертификатов, которые можно было бы использовать с несколькими именами сервера, например, example.com, www.example.com или www.example.net требуется процесс, описанный ниже.

cd /etc/ssl
openssl req -x509 -nodes -days 1059 -newkey rsa:2048 \
 -keyout testkey.pem -out testcert.pem

Generating a 2048 bit RSA private key
.....++++++
..................++++++
writing new private key to 'testkey.pem'
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:#код_вашей_страны#
State or Province Name (full name) [Some-State]:#название_вашего_субъекта_страны#
Locality Name (eg, city) []:#название_вашего_города#
Organization Name (eg, company) [Internet Widgets Pty Ltd]:#название_вашей_организации#
Organizational Unit Name (eg, section) []:#необязательное_поле#
Common Name (eg, YOUR name) []:#имя_сервера#
Email Address []:.

# Создаём сертификат testcert.pem
# и незашифрованный закрытый ключ testkey.pem
# которому необходимо немедленно дать права
# только на чтение только владельцу:
# chown user:group testkey.pem
# chmod 0400 testkey.pem

# Переместите и переименуйте файлы согласно требованиям сервера.
# Необходимы оба файла testcert.pem и testkey.pem.
# Пример для apache:
SSLCertificateFile /path/to/testcert.pem
SSLCertificateKeyFile /path/to/testkey.pem
# Пример для TLS-сервера OpenLDAP (slapd.conf)
TLSCertificateFile /path/to/testcert.pem
TLSCertificateKeyFile /path/to/testkey.pem
# Пример для TLS-клиента OpenLDAP (ldap.conf)
TLS_CACERT /path/to/testcert.pem

Примечание: Параметр -x509 используется для создания самоподписанного сертификата УЦ. -nodes подавляет диалог запроса парольной фразы. -days 1059 устанавливает срок действия сертификата: 2 года 329 дней.

<ляп> Читатели могут задаться вопросом, зачем здравомыслящему человеку может потребоваться создавать сертификат сроком действия 2 года 329 дней? Тому есть две причины. Во-первых, если можно так сделать, то почему бы и нет? Во-вторых, внимательные читатели могли заметить, что 3 года составляет 1095 дней а не 1059, которые были использованы в тестах. Если честно, при первоначальном запуске тестов мы перепутали 5 и 9 (по молодости лет, плохому зрению или глупости — решайте сами) и вместо того, чтобы перезапустить тесты с 1095 днями, мы оставили 1059 и придумали эту глупую отмазку. Наконец, поскольку предполагается, что текущие рекомендации по размеру ключей в 2048 бита будут действительны до 2030 года, можно вполне разумно задать это значение в -days 6205 (по состоянию на 2013 год): 17 лет с учётом високосных лет.</ляп>

Метод 3: Корневой сертификат УЦ и несколько сертификатов

Если Вы собираетесь генерировать несколько сертификатов, скажем, для использования во внутренней системе, этому стоит посвятить некоторое время и усилия. Мы пробовали несколько методов и этот, на наш взгляд, самый простой. В нём используется стандартный скрипт CA.pl для создания удостоверяющего центра, при этом инициализируются множество директорий и файлов, которые очень проблематично настроить другим способом, а затем используются команды openssl для генерации CSR и подписания сертификатов, поскольку таким способом достигается больший контроль над переменными и (относительно) меньший уровень проблем.

1. Размещение и предварительная подготовка. Необязательный этап, позволяющий печатать меньше параметров в командной строке. Решите, где Вы собираетесь построить свой репозиторий сертификатов. Для наглядности мы создадим его в /etc/ssl, и это размещение будет использоваться далее по тексту. Измените его в соответствии с Вашими потребностями. Переместите скрипт CA.pl (если Вы не можете его найти, используйте locate CA.pl) в /etc/ssl/CA.pl либо туда, где Вы собираетесь создавать репозиторий сертификатов. Мы также переименовали этот скрипт в ca.pl из-за патологического отвращения к клавише shift, но если Вы не разделяете наших взглядов, просто используйте CA.pl в примерах.

   Файлы ca.pl (или CA.pl) и /etc/ssl/openssl.cnf оказывают существенное влияние на работу как самого скрипта, так и команды openssl. Произведённые нами изменения показаны ниже, для удобства в файле CA.pl (ca.pl) приведены только изменённые строки:

   # ПРЕДУПРЕЖДЕНИЕ: Следует сделать и хранить копии первоначальных файлов
   #    CA.pl и openssl.cnf прежде чем вносить какие-либо изменения
   # Срок действия корневого сертификата - 10 лет, можете установить другой,
   # но большинство общедоступных УЦ предоставляют корневые сертификаты,
   # действительные до 2028
   $CADAYS="-days 3650";	# 10 лет
   # по умолчанию $CADAYS="-days 1059";	# 3 года
   
   # Изменяем директорию УЦ
   $CATOP="./ca";
   # по умолчанию $CATOP="./demoCA";
   # при изменении этой переменной требуются соответствующие изменения в openssl.cnf
   

   Чтобы упростить себе жизнь, мы сделали следующие изменения в /etc/ssl/openssl.cnf (опять же, приведены только изменённые строки):

   # ПРЕДУПРЕЖДЕНИЕ: Следует сделать и хранить копии первоначальных файлов
   #    CA.pl и openssl.cnf прежде чем вносить какие-либо изменения
   [ CA_default ]
   # изменение директории как в ca.pl
   dir = ./ca         # Тут будет всё
   # dir = ./demoCA   # по умолчанию
   
   # Параметр копирования расширений: используйте с осторожностью
   copy_extensions = copy
   # раскомментируйте эту директиву если требуется сертификат для нескольких имён DNS,
   # иначе оставьте закомментированной (по умолчанию)
   
   # Срок действия сертификата изменён на 3 года.
   # Можно опустить опцию -days
   default_days	= 1059 # 3 года
   # по умолчанию default_days	= 365 # 1 год
   
   [ policy_match ]
   # Добавление этой строки в предыдущий раздел
   # приведёт к добавлению атрибута L= в DN issuer и subject,
   # в противном случае этот атрибут будет опущен - на Ваш выбор
   localityName		= optional
   
   [req]
   default_bits = 2048 # текущая рекомендация на 2011-2030 годы
   # default_bits = 1024 # значение в оригинальном файле
   
   [ req_distinguished_name ]
   # Чтобы меньше печатать установите корректные значения _default.
   # Отредактируйте или добавьте в нужное место
   countryName_default		= MY 
   stateOrProvinceName_default	= STATE
   localityName_default		= CITY
   0.organizationName_default	= ONE INC
   organizationalUnitName_default	= IT
   
   

   Стоит проверить все остальные значения этого файла — вдруг Вы захотите что-то изменить.

2. Создание удостоверяющего центра. Первая команда создаёт корневой сертификат удостоверяющего центра (УЦ) и некоторые другие служебные файлы. Создаётся пара ключей — открытый и закрытый. Открытый ключ записывается в корневой сертификат /etc/ssl/ca/cacert.pem, закрытый ключ — в /etc/ssl/ca/private/cakey.pem. Формат файла по умолчанию — PEM. Запрашиваемые детали DN будут использованы для формирования полей issuer и subject этого корневого сертификата, а также для поля issuer всех последующих подписанных сертификатов, укажите их в соответствии со своими требованиями. Парольная фраза обязательна, она устанавливается для защиты закрытого ключа и будет запрашиваться при всех последующих подписаниях сертификатов, так что её стоит запомнить:

   cd /etc/ssl
   ./ca.pl -newca
   
   CA certificate filename (or enter to create) #ENTER
   
   Making CA certificate ...
   Generating a 2048 bit RSA private key
   .....++++++
   ..................++++++
   writing new private key to './ca/private/cakey.pem'
   Enter PEM pass phrase:
   Verifying - Enter PEM pass phrase:
   -----
   You are about to be asked to enter information that will be incorporated
   into your certificate request.
   What you are about to enter is what is called a Distinguished Name or a DN.
   There are quite a few fields but you can leave some blank
   For some fields there will be a default value,
   If you enter '.', the field will be left blank.
   -----
   Country Name (2 letter code) [MY]:
   State or Province Name (full name) [STATE]:
   Locality Name (eg, city) [CITY]:
   Organization Name (eg, company) [ONE INC]:CA COMPANY NAME
   Organizational Unit Name (eg, section) [IT]:X.509
   Common Name (eg, YOUR name) []:CA ROOT
   Email Address []:.
   
   Please enter the following 'extra' attributes
   to be sent with your certificate request
   A challenge password []:
   An optional company name []:
   Using configuration from /etc/ssl/openssl.cnf
   Enter pass phrase for ./ca/private/cakey.pem:
   Check that the request matches the signature
   Signature ok
   Certificate Details:
     Serial Number:
        bb:7c:54:9b:75:7b:28:9c
     Validity
        Not Before: Apr 15 21:07:36 2008 GMT
        Not After : Apr 13 21:07:36 2018 GMT
     Subject:
        countryName               = MY
        stateOrProvinceName       = STATE
        organizationName          = CA COMPANY NAME
        localityName              = CITY
        organizationalUnitName    = X.509
        commonName                = CA ROOT
     X509v3 extensions:
      X509v3 Subject Key Identifier: 
       54:0D:DE:E3:37:23:FF...
      X509v3 Authority Key Identifier: 
       keyid:54:0D:DE:E3:37...
       DirName:/C=MY/ST=STATE/O=CA COMPANY NAME/L=CITY/OU=X.509/CN=CA ROOT
       serial:BB:7C:54:9B:75:7B:28:9C
      X509v3 Basic Constraints: 
       CA:TRUE
   Certificate is to be certified until Apr 13 21:07:36 2018 GMT (3650 days)
   
   Write out database with 1 new entries
   Data Base Updated
   

   Примечание: В приведённом примере строки, мало что дающие для понимания материала, были обрезаны или даже пропущены (места пропусков обозначены многоточиями).

   Создаётся стандартная структура директорий:

   ca                   # cacert.pem (корневой сертификат)
                        # serial (отслеживание серийных номеров)
                        # crlnumber (серийные номера CRL)
                        # index.txt 
   ca/private/cakey.pem # закрытый ключ УЦ
   ca/newcerts          # копии всех созданных сертификатов
   ca/crl               # опциональное место размещения созданных CRL
   ca/certs             # опциональное место размещения созданных сертификатов
   

   Срок действия созданного корневого сертификата (ca/cacert.pem) — 10 лет (3650 дней) согласно отредактированному значению в файле ca.pl. Соответствующий закрытый ключ (ca/private/cakey.pem) защищён парольной фразой PEM, но всё равно его следует защищать установкой минимально возможных прав доступа (назначаемые по умолчанию права 0644 неоправданно высоки). Запрашиваемый Challenge Password — простой пароль, который может быть использован для защиты доступа к сертификатам, CSR и последующим сертификатам X.509. Большинство (если не все) коммерческие удостоверяющие центры не приветствуют установку этого пароля и сопутствующего опционального названия компании (Optional Company Name), и во всех примерах это поле оставляется незаполненным. Если Вы хотите отключить запрос этих значений, отредактируйте /etc/ssl/openssl.cnf:

   [ req_attributes ]
   # Закомментируйте указанные строки
   #challengePassword		= A challenge password
   #challengePassword_min		= 4
   #challengePassword_max		= 20
   
   #unstructuredName		= An optional company name
   

3. Создание запроса на подписание сертификата (CSR). Запрашиваемые в этом случае атрибуты DN будут относиться к полю subject итогового сертификата.

   Эта команда может использоваться и для создания запроса CSR (Certificate Signing Request) в коммерческий УЦ, а поскольку большинство УЦ не приветствуют паролей, просто нажмите ENTER при запросе A challenge password (о том, как совсем отключить эти запросы смотрите выше). Опциональное значение emailAddress также остаётся пустым, главным образом потому, что для сертификата сервера оно не имеет никакого значения, а также потому, что в большинстве запросов в коммерческие УЦ оно не заполняется.

   openssl req -nodes -new -newkey rsa:2048 \ 
   -keyout ca/private/cert1key.pem -out ca/certs/cert1csr.pem
   
   Generating a 2048 bit RSA private key
   ...................++++++
   ............++++++
   writing new private key to 'ca/private/cert1key.pem'
   -----
   You are about to be asked to enter information that will be incorporated
   into your certificate request.
   What you are about to enter is what is called a Distinguished Name or a DN.
   There are quite a few fields but you can leave some blank
   For some fields there will be a default value,
   If you enter '.', the field will be left blank.
   -----
   Country Name (2 letter code) [MY]:
   State or Province Name (full name) [STATE]:
   Locality Name (eg, city) [CITY]:
   Organization Name (eg, company) [ONE INC]:
   Organizational Unit Name (eg, section) [IT]:
   Common Name (eg, YOUR name) []:www.example.com
   Email Address []:.
   
   Please enter the following 'extra' attributes
   to be sent with your certificate request
   A challenge password []:
   An optional company name []:
   

   Эта команда создаёт новый запрос на подписание сертификата (в /etc/ssl/ca/certs/cert1csr.pem), который затем должен быть подписан с помощью закрытого ключа УЦ, и закрытый ключ (который, за счёт использования параметра -nodes, не будет защищён парольной фразой — ведь мы будем использовать его в серверном приложении) в /etc/ssl/ca/private/cert1key.pem. Значение CN (в примере — www.example.com) — это используемое приложением имя сервиса. Оно могло бы быть ldap.example.com, либо любым другим подходящим именем. Имейте также ввиду, что такой сертификат сработает при доступе на https://www.example.com, но если для доступа к тому же сервису используется https://example.com, то Вам перед созданием CSR нужно обязательно добавить атрибут сертификата subjectAltName с помощью описанной ниже процедуры (и использовать в секции VirtualHost настроек Apache директиву ServerAlias). Имя сервиса не следует путать именем хоста сервера. Так, если к веб-сервису обращаются как к https://www.example.com, а он выполняется на хосте webserver.example.com, в CN нужно использовать www.example.com.

Для просмотра запроса сертификата выполните:

openssl req -in ca/certs/cert1csr.pem - noout -text

Certificate Request:
 Data:
  Version: 0 (0x0)
  Subject: C=MY, ST=STATE, L=CITY, O=ONE INC, OU=IT, CN=www.example.com
  Subject Public Key Info:
  Public Key Algorithm: rsaEncryption
  RSA Public Key: (1024 bit)
   Modulus (1024 bit):
    00:ae:19:86:44:3c:dd...
    ...
    99:20:b8:f7:c0:9c:e8...
    38:c8:52:97:cc:76:c9...
   Exponent: 65537 (0x10001)
   Attributes:
     a0:00
 Signature Algorithm: sha1WithRSAEncryption
  79:f5:20:45:6c:ec:8e:ae...
  ...
  bd:61:cd:c5:89:7c:e0:0d...
  40:7d

Примечание: В приведённом примере строки, мало что дающие для понимания материала, были обрезаны или даже пропущены (места пропусков обозначены многоточиями).

4. Создание и подписание сертификата конечного пользователя. Эта команда принимает на входе CSR (ca/certs/cert1csr.pem) и создаёт сертификат конечного пользователя (конечного субъекта) (ca/certs/cert1.pem):

   openssl ca -policy policy_anything \
   -in ca/certs/cert1csr.pem -out ca/certs/cert1.pem
   
   Using configuration from /usr/local/openssl/openssl.cnf
   Enter pass phrase for ./ca/private/cakey.pem:
   Check that the request matches the signature
   Signature ok
   Certificate Details:
     Serial Number:
       bb:7c:54:9b:75:7b:28:9d
     Validity
       Not Before: Apr 15 22:21:10 2008 GMT
       Not After : Mar 10 22:21:10 2011 GMT
     Subject:
       countryName               = MY
       stateOrProvinceName       = STATE
       localityName              = CITY
       organizationName          = ONE INC
       organizationalUnitName    = IT
       commonName                = www.example.com
    X509v3 extensions:
     X509v3 Basic Constraints: 
      CA:FALSE
     Netscape Comment: 
      OpenSSL Generated Certificate
     X509v3 Subject Key Identifier: 
      EE:D9:4A:74:03:AC:FB:2C...
     X509v3 Authority Key Identifier: 
      keyid:54:0D:DE:E3:37:23...
   
   Certificate is to be certified until Mar 10 22:21:10 2011 GMT (1059 days)
   Sign the certificate? [y/n]:y
   
   1 out of 1 certificate requests certified, commit? [y/n]y
   Write out database with 1 new entries
   Data Base Updated
   

   Примечание: В приведённом примере строки, мало что дающие для понимания материала, были обрезаны или даже пропущены (места пропусков обозначены многоточиями).

   Поле issuer полученного в результате сертификата формируется из поля subject корневого сертификата (ca/cacert.pem), а поле subject нового сертификата — из CSR. Многие значения по умолчанию команда берёт из openssl.cnf: срок действия (default_days =), ключ подписания (private_key =) и DN издателя из корневого сертификата (certificate =). В зависимости от требований Вашей системы параметр -policy policy_anything может быть обязательным. Он указывает на определённую в файле openssl.cnf секцию policy_anything, которая позволяет задавать в DN поля subject сертификата значения атрибутов, отличные от соответствующих атрибутов в DN поля issuer. При отсутствии этого параметра по умолчанию используется -policy policy_match, накладывающее ограничения на значения RDN C=, ST= и O=.

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

   openssl x509 -in ca/certs/cert1.pem -noout -text
   
   Certificate:
    Data:
     Version: 3 (0x2)
     Serial Number:
      bb:7c:54:9b:75:7b:28:9d
     Signature Algorithm: sha1WithRSAEncryption
     Issuer: C=MY, ST=STATE, O=CA COMPANY NAME, L=CITY, OU=X.509, CN=CA ROOT
     Validity
      Not Before: Apr 15 22:21:10 2008 GMT
      Not After : Mar 10 22:21:10 2011 GMT
     Subject: C=MY, ST=STATE, L=CITY, O=ONE INC, OU=IT, CN=www.example.com
     Subject Public Key Info:
      Public Key Algorithm: rsaEncryption
      RSA Public Key: (1024 bit)
       Modulus (1024 bit):
        00:ae:19:86:44:3c:dd...
        ...
        99:20:b8:f7:c0:9c:e8...
        38:c8:52:97:cc:76:c9...
       Exponent: 65537 (0x10001)
    X509v3 extensions:
     X509v3 Basic Constraints: 
      CA:FALSE
     Netscape Comment: 
      OpenSSL Generated Certificate
     X509v3 Subject Key Identifier: 
      EE:D9:4A:74:03:AC:FB:2C...
     X509v3 Authority Key Identifier: 
      keyid:54:0D:DE:E3:37:23...
   
    Signature Algorithm: sha1WithRSAEncryption
     52:3d:bc:bd:3f:50:92...
     ...
     51:35:49:8d:c3:9a:bb...
     b8:74
   

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

   Полезные команды

   Проверка и просмотр сертификатов. Может случиться неприятность и произойти повреждение файлов. Чтобы убедиться в целостности сертификатов, используйте такие команды:

   openssl x509 -in certificate-name.pem -noout -text 
   # отображает сертификат целиком
   
   openssl x509 -in certificate-name.pem -noout -dates
   # выводит только даты начала и окончания срока действия 
   
   openssl x509 -in certificate-name.pem -noout -purpose
   # выводит список всех возможных целей применения сертификата
   
   openssl x509 -in certificate-name.pem -noout -purpose - dates
   # выводит срок действия и цели применения сертификата
   

5. Импорт самоподписанного корневого сертификата. Созданный на этапе 2 файл в формате PEM (ca/cacert.pem) может быть импортирован непосредственно в MSIE и Firefox, чтобы они не выдавали запросы о недоверенных сертификатах. Процедура импорта описана ниже.

Метод 3A: Создание подчинённых УЦ, промежуточных сертификатов и кросс-сертификатов

В методе 3 создаётся простая цепочка из двух сертификатов: сертификата конечного субъекта (сервера) и корневого сертификата УЦ. В методе 3A производится исследование того, что можно добавить к этой структуре (по тем или иным причинам). Мы создадим подчинённый УЦ, возможно, второй корневой УЦ, а также, основываясь на этой структуре, создадим всевозможные кросс-сертификаты и промежуточные сертификаты.

1. Основные настройки: Выполните этапы 1 и 2 метода 3. Создаётся просто структура директорий и наш первый корневой УЦ. Если Вы уже прошли все этапы метода 3, то ни одно из имён файлов, создаваемых далее не будет конфликтовать с уже созданными, так что Вы ничего не потеряете и Ваша система не нарушится. По завершении этого процесса будут созданы следующие директории и файлы:

   ca                   # cacert.pem (корневой сертификат)
                        # serial (отслеживание серийных номеров)
                        # crlnumber (серийные номера CRL)
                        # index.txt 
   ca/private/cakey.pem # закрытый ключ УЦ
   ca/newcerts          # копии всех созданных сертификатов
   ca/crl               # опциональное место размещения созданных CRL
   ca/certs             # опциональное место размещения созданных сертификатов
   

   Замечание по стратегии: Команда openssl берёт многие из своих расширенных параметров из конфигурационного файла (openssl.cnf). До этого момента мы предполагали, что изменения нужно производить именно в этом стандартном файле, поскольку он обычно используется при выполнении всех таких команд. Но для текущей задачи такой подход не подойдёт. Вместо этого мы рекомендуем скопировать стандартный конфигурационный файл (openssl.cnf), дать этому новому файлу подходящее имя (которое легко запомнить) и использовать аргумент -config filename для выбора, в зависимости от задачи, соответствующего конфигурационного файла. Это позволяет работать быстрее (со временем), не путаться (со временем) и использовать конфигурацию повторно (изначально).

2. Создаём подчинённый УЦ:

   Создаём новые директории, скажем, subca и subca/private (с теми же правами, что и ca/private). Этот шаг просто позволит поддерживать порядок (в своём роде):

   cd /etc/ssl
   mkdir ca/subca
   mkdir ca/subca/private
   # создаём необходимый пустой файл базы данных для издателя subca
   touch ca/subca/index.txt
   

   Редактируем openssl.cnf, создаём секцию [ sub_ca ], она может находиться в любом месте файла, но для определённости создадим её перед секцией [ user_certs ]. Различные параметры в этой секции будут использоваться для переопределения обычных параметров, используемых при подписании сертификата.

   # новая секция
   [ sub_ca ]
   basicConstraints=CA:TRUE
   # другой вариант:
   # basicConstraints= CA:TRUE,pathlen:0
   # pathlen:0 ограничивает subCA, чтобы он мог
   # подписывать только сертификаты конечных субъектов
   
   # необязательная строка тестового комментария
   # nsComment="Most Trusted Certificate in the World"
   nsComment="OpenSSL Generated Certificate"
   # следующие два параметра - обычные для всех некорневых сертификатов
   subjectKeyIdentifier=hash
   authorityKeyIdentifier=keyid,issuer
   
   # следующая строка лишь демонстрирует позицию секции sub_ca в файле
   [ user_cert ]
   

3. Создаём сертификат подчинённого УЦ:

   Создаём CSR для подчинённого УЦ и подписываем его с использованием корневого сертификата УЦ:

   # ПРИМЕЧАНИЕ: На этих этапах используется корневой УЦ, созданный на этапах 1 и 2 метода 3.
   
   # Создаём CSR для подчинённого УЦ
   openssl req -new -keyout ca/subca/private/subca1key.pem \
     -out ca/subca/subca1csr.pem
   Generating a 2048 bit RSA private key
   ...................++++++
   ............++++++
   writing new private key to 'ca/subca/private/subca1key.pem'
   Enter PEM pass phrase:
   Verifying - Enter PEM pass phrase:
   -----
   You are about to be asked to enter information that will be incorporated
   into your certificate request.
   What you are about to enter is what is called a Distinguished Name or a DN.
   There are quite a few fields but you can leave some blank
   For some fields there will be a default value,
   If you enter '.', the field will be left blank.
   -----
   Country Name (2 letter code) [MY]:
   State or Province Name (full name) [Some-State]:
   Locality Name (eg, city) [Some City]:
   Organization Name (eg, company) [My Company Name]:
   Organizational Unit Name (eg, section) []:Certs
   Common Name (eg, YOUR name) []:subCA1
   
   Please enter the following 'extra' attributes
   to be sent with your certificate request
   A challenge password []:
   An optional company name []:
   
   # Примечания:
   # 1. Значение Organizational Unit не так важно, несёт больше описательную нагрузку.
   # 2. Значение Common Name - имя (название), данное подчинённому УЦ. 
   
   # Теперь подпишем этот запрос с использованием ключа корневого УЦ.
   # Для установки определённых нами расширений используем -extensions sub_ca.
   openssl ca -policy policy_anything -in ca/subca/subca1csr.pem \
     -out ca/subca/subca1cert.pem -extensions sub_ca
   	
   # Выводим полученный сертификат:
   openssl x509 -in ca/subca/subca1cert.pem -noout -text
   Certificate:
    Data:
     Version: 3 (0x2)
     Serial Number:
        c6:bd:b2:ce:22:bc:4d:57
     Signature Algorithm: sha1WithRSAEncryption
     Issuer: C=MY, ST=Some-State, O=My company name, OU=Certs, CN=Root CA1
     Validity
      Not Before: Dec 9 20:40:18 2011 GMT
      Not After : Dec 6 20:40:18 2021 GMT
     Subject: C=MY, ST=Some-State, L=Some City, O=My company name, OU=Certs, CN=subCA1
     Subject Public Key Info:
      Public Key Algorithm: rsaEncryption
      RSA Public Key: (2048 bit)
       Modulus (2048 bit):
        00:a9:f3:02:01:c9...
        01:b6:27:c8:a0:9c...
        ...               
        f0:37:71:5d:e3:c7:3d:59:ff...
        55:87
       Exponent: 65537 (0x10001)
      X509v3 extensions:
       X509v3 Basic Constraints: 
        CA:TRUE
       X509v3 Key Usage: 
        Certificate Sign, CRL Sign
       Netscape Comment: 
        OpenSSL Generated Certificate
       X509v3 Subject Key Identifier: 
        58:47:30:77:3F:EF...
       X509v3 Authority Key Identifier: 
        keyid:FB:7B:FB:7B...
   
    Signature Algorithm: sha1WithRSAEncryption
     43:b5:e2:8d:4d:07:56...
     ...
     12:2c:a2:7c:eb:dc:45...
     e0:f3:2b:72
   

   Примечание: В приведённом примере строки, мало что дающие для понимания материала, были обрезаны или даже пропущены (места пропусков обозначены многоточиями).

   Четыре расширения X509v3 extensions, — следствие использования аргумента -extensions sub_ca, — переопределяют обычные характеристики сертификата. Если от корневого УЦ требуется подписать обычный сертификат конечного субъекта, просто опустите этот аргумент. Технически, получившийся в результате сертификат (ca/subca/subca1cert.pem) — это кросс-сертификат, поскольку и полученный сертификат, и сертификат издателя имеют поле basicConstraints, в котором cA установлено в True.

4. Подписание сертификата конечного субъекта подчинённым УЦ:

   Чтобы подписать сертификат конечного субъекта с использованием ключа подчинённого УЦ, нам сначала нужно скопировать файл openssl.cnf и переименовать его, скажем, в subca1.cnf. Теперь внесём изменения в subca1.cnf (эти изменения просто сообщат openssl где брать различные файлы, относящиеся к subCA, тогда как стандартный файл openssl.cnf продолжит ссылаться на информацию о корневом УЦ):

   [ CA_default ]
   # Показаны только те значения, которые были изменены.
   database	= $dir/subca/index.txt	# индексный файл базы данных.
   certificate	= $dir/subca/subca1cert.pem 	# сертификат subCA
   # Следующий параметр говорит о том, что сертификаты от обоих центров
   # (корневого и подчинённого) будут иметь сквозную (единую) нумерацию.
   # Чтобы изменить это, скопируйте ca/serial в ca/subca/serial
   # и модифицируйте параметр.
   serial		= $dir/serial 		# текущий серийный номер
   # Эти параметры задаются, если будут выпускаться отдельные CRL,
   # в противном случае оставьте их без изменений
   crl_dir		= $dir/subca/crl        # месторасположение подписанных crl
   crlnumber	= $dir/subca/crlnumber	# текущий номер crl
   
   # Закомментируйте, если собираетесь использовать CRL V1
   crl		= $dir/subca/crl.pem 		# текущий CRL
   
   private_key=$dir/subca/private/subca1key.pem # закрытый ключ subCA
   RANDFILE	= $dir/subca/private/.rand	# закрытый файл со случайным числом
   

   Теперь создадим CSR на сертификат конечного субъекта и подпишем его ключом subCA:

   # Создаём CSR:
   openssl req -new -nodes -keyout ca/private/user1key.pem \
     -out ca/certs/user1csr.pem
   # Подписываем его ключом subCA с использованием -config subca1.cnf:
   openssl ca -policy policy_anything -in ca/certs/user1csr.pem \
     -out ca/certs/user1cert.pem -config subca1.cnf
   # Выводим получившийся сертификат:
   openssl x509 -in ca/certs/user1cert.pem -noout -text
   Certificate:
    Data:
     Version: 3 (0x2)
     Serial Number:
      c6:bd:b2:ce:22:bc:4d:58
     Signature Algorithm: sha1WithRSAEncryption
     Issuer: C=MY, ST=Some-State, L=Some City, O=My company name, OU=Certs, CN=subCA1
     Validity
       Not Before: Dec 9 21:06:43 2011 GMT
       Not After : Dec 6 21:06:43 2021 GMT
     Subject: C=MY, ST=Some-State, L=Some City, O=My company name, OU=Server, CN=www.example.com
     Subject Public Key Info:
     Public Key Algorithm: rsaEncryption
      RSA Public Key: (2048 bit)
       Modulus (2048 bit):
        00:c3:f4:dc:07:08:30:3a...
        ...
        a8:45:fd:c5:d7:a4:04:82...
        af:dd
       Exponent: 65537 (0x10001)
     X509v3 extensions:
      X509v3 Basic Constraints: 
       CA:FALSE
      Netscape Comment: 
       OpenSSL Generated Certificate
      X509v3 Subject Key Identifier: 
       B1:5A:23:4E:C8:2B:FD:98...
      X509v3 Authority Key Identifier: 
       keyid:58:47:30:77:3F:EF...
   
    Signature Algorithm: sha1WithRSAEncryption
     50:4b:8e:50:8f:fa:f4:98...
     ...
     3d:97:52:28:1f:a6:9d:2e...
     ac:58:be:eb
   

   Примечание: В приведённом примере строки, мало что дающие для понимания материала, были обрезаны или даже пропущены (места пропусков обозначены многоточиями).

   В данном случае издатель сертификата — subCA1, а не root CA1, как было при подписании запроса на создание сертификата подчинённого УЦ. Чтобы разрешить проверку подлинности сертификата конечного субъекта по всей цепочке, в браузер должны быть импортированы ОБА сертификата: корневого УЦ (ca/cacert.pem) и подчинённого УЦ (ca/subca/subca1cert.pem).

5. Другие возможности:

   Используя подобную технику, можно создать второй корневой УЦ (root CA2), при этом, понятное дело, потребуется ещё одна копия openssl.cnf, либо второй подчинённый УЦ (subCA2), опять же, с уникальным конфигурационным файлом. Короче, любой каприз...

Сертификаты с несколькими именами сервера

Если сертификат предназначен для использования на хосте, у которого больше одного имени DNS, скажем, https://www.example.com, https://example.com или даже www.example.net, то вам нужно указать использование атрибута сертификата subjectAltName в запросе на подписание сертификата (CSR). Чтобы это сделать, отредактируйте файл openssl.cnf как показано ниже (приведены только изменённые строки):

# Сначала найдите секцию [CA_Default]
[CA_Default]
....
# Раскомментируйте или добавьте
copy_extensions = copy
# Это заставит функцию ca скопировать поля расширений из CSR.
# Эти манипуляции следует произвести на хосте, создающем
# сертификаты на основе CSR.

# Теперь найдите секцию [v3_req]
[v3_req]
...
# Добавьте следующую строку с нужными именами хостов:
subjectAltName = "DNS:www.example.com, DNS:example.com,DNS:example.net"
# Это следует сделать на хосте, который генерирует CSR.

При запуске команды на создание CSR добавьте к её аргументам -reqexts "v3_req" только в том случае, когда Вам нужно включить дополнительные поля subjectAltName. Хотя в приведённом примере показано добавление трёх имён, на практике можно добавить любое количество. Каждое включение имеет формат DNS:hostname.domain.name, несколько включений должны быть разделены запятыми, а все вместе они должны быть заключены в кавычки. Вот запрос на создание CSR из этапа 3 метода 3 с дополнительным аргументом:

openssl req -nodes -new -newkey rsa:2048 \ 
-keyout ca/private/cert1key.pem -out ca/certs/cert1csr.pem -reqexts "v3_req"

Если при создании CSR не указывался аргумент -reqexts, по этому CSR будет создан обычный сертификат с единственным именем сервера. Приведённый пример работает как дополнение рассмотренного выше метода 3 и представляет собой наиболее гибкий подход.

Примечание: Если Вы хотите выпустить несколько сертификатов с разным набором имён серверов в каждом, то лучшей стратегией будет простое копирование и переименование стандартного конфигурационного файла (openssl.cnf) во что-то более осмысленное, а затем использование аргумента -config filename для выбора каждого из файлов по мере необходимости. Количество подобных конфигурационных файлов может быть любым, просто помните их имена и предназначение.

Если Вы хотите создать сертификаты с несколькими именами сервера в методах 1 или 2, то в дополнение к приведённым выше правкам openssl.cnf добавьте это:

# Найдите секцию [req]
[req]
....
# Добавьте или раскомментируйте:
req_extensions = v3_req

При такой модификации атрибуты сертификата subjectAltName будут безусловно добавляться в каждый CSR.

Замечания по форматам файлов, связанных с SSL

В настоящее время существует множество форматов файлов, используемых для хранения сертификатов, ключей и других данных, связанных с X.509/SSL. Иногда расширения таких файлов дают представление об их содержимом, иногда — нет. Прежде чем углубляться в детали, прочтите этот краткий обзор:

1. Все связанные с SSL объекты (сертификаты, ключи и прочие) изначально используют кодировку DER. DER — это бинарная (8 бит) кодировка. Это, кроме всего прочего, означает, что пересылать такие данные по электронной почте нельзя. PEM (Privacy Enhanced Mail) — это метод простого перекодирования (с использованием base64) первоначальных форматов DER в нечто такое, что может быть отправлено по электронной почте или передано по другим коммуникационным системам.

2. Некоторые стандарты PKCS#X, в частности, PKCS#7 (и его CMS-эквивалент от IETF RFC 5652), PKCS#12 и PKCS#8, представляют собой контейнеры (закодированные в формат DER), используемые для определения нескольких объектов в одном и том же файле. Если файл содержит один объект, скажем, сертификат или CRL, то такому объекту контейнер не требуется (хотя, опционально, он может быть и заключён в контейнер).

3. По своей сути, единичный ключ выглядит как один объект, и потому контейнер ему не требуется. Однако, помимо самого ключа, требуется также информация об алгоритме его использования (а также другие параметры), следовательно, для единичного ключа всё-таки требуется контейнер для определения составляющих объектов этого ключа (в данном случае PKCS#8). И наоборот, сертификат X.509v3 содержит много различной информации, и потому может показаться, что для него требуется контейнер. Но сертификат X.509v3 сам по себе является контейнером. Поэтому, если в файле содержится только единичный сертификат, то он не нуждается в контейнере (например, файлы с расширениями .cer или .crt). Однако, когда в одном файле содержится сертификат и закрытый ключ (файлы с расширениями .p12/.pkx), то в этом случае присутствуют как минимум два объекта, требующие определения, и потому здесь контейнер необходим (в данном случае PKCS#12).

4. Многие форматы из стандартов PKCS#X представляют собой контейнеры (закодированные в DER), содержимое которых по своей природе предназначено для передачи посредством какой-либо системы связи, например, запросы на подписание сертификата (CSR). В таких случаях сформированные данные, независимо от расширения файла, в конечном итоге кодируются в PEM.

5. Во многих случаях содержимое файла определяется контекстом ситуации, а не расширением файла. Так, если ожидается, что файл должен содержать только сертификат (без закрытого ключа), то он может иметь расширения как .pem, так и .crt, и даже .cer.

6. В качестве простейшего теста откройте файл, независимо от его расширения, в текстовом редакторе. Если там какая-то абракадабра, значит он закодирован в DER. Если Вы можете прочитать '-----BEGIN' — это PEM.

Формат PEM

В качестве формата по умолчанию (основного формата) OpenSSL поддерживает формат почты повышенной конфиденциальности Privacy Enhanced Mail (PEM). Изначальный формат сертификатов X.509, как, впрочем, и всех остальных объектов, связанных с SSL, — ASN.1 DER (бинарный формат). PEM кодирует бинарный блок DER в base64 (RFC 3548), при этом создаётся текстовая версия (подмножество набора символов ASCII/IA5) которая может, кроме всего прочего, пересылаться почтовыми системами. Закодированные в PEM объекты включают заголовочную и завершающую строки, каждая из которых начинается и заканчивается ровно пятью дефисами и представляет собой пригодное для чтения людьми описание того содержимого в формате base64, которое заключено между этими строками. Файлы PEM выглядят примерно так:

-----BEGIN CERTIFICATE-----
MIIDHDCCAoWgAwIBAgIJALt8VJ...
...
Cfh/ea7F1El1Ym1Zj2v3wLhRl1...
NH5lEmZybl+m2frlkjUv9KAvxc...
IFgovdU8YPMDds=
-----END CERTIFICATE-----

BLAH BLAH BLAH 

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,6EF6203EF1A9533A

r7LMq15wr1OOmMsD84KyNo+5yY...
El3/msvQ98BkaMihajEn5f2UxO...
...
f6uoSk8HBZLItWTxqRuBRVb8jq...
hdp9hvvdja9XIrAPGQJ0u2QVw==
-----END RSA PRIVATE KEY-----

Примечание: В приведённом примере строки, мало что дающие для понимания материала, были обрезаны или даже пропущены (места пропусков обозначены многоточиями).

Текст BEGIN CERTIFICATE и END CERTIFICATE из примера может принимать различные значения, описывающие функциональность и формат материала, содержащегося между строками-ограничителями. В любом файле PEM может быть более одного элемента (каждый из которых ограничен последовательностью -----BEGIN -----END), а также этот файл может содержать другую информацию до, после и между такими элементами, но не внутри ограничителей. Формат PEM определён в RFC 1421 для использования с S/MIME (RFC 3850).

Ключевые слова, используемые в элементах BEGIN формата PEM

В RFC 7468 определено несколько ключевых слов (или меток), которые могут встречаться в файлах, закодированных в PEM, в элементах -----BEGIN и -----END (но, как это ни удивительно, не определён репозиторий IANA для этих ключевых слов). Кроме того, заголовочный файл pem.h из пакета OpenSSL (версии 1.0.2d) содержит другие ключевые слова (некоторые из которых явно упразднены в RFC 7468, некоторые могут быть неявно упразднёнными — смотрите примечания ниже). В таблице ниже приведены ключевые слова, собранные из двух источников и снабжённые соответствующими описаниями и комментариями.

Примечание: В закодированных в PEM файлах данные ключевые слова должны присутствовать в обоих элементах BEGIN и END. Для краткости строки -----BEGIN и ----END не показаны, то есть, если в таблице приведено ключевое слово CERTIFICATE, то в PEM-файле оно будет присутствовать дважды: в -----BEGIN CERTIFICATE----- и в -----END CERTIFICATE-----.

Имена файлов

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

Связки сертификатов

Номинально, ответственность за проверку полученного от сервера сертификата конечного субъекта несёт клиент. При этом всё чаще требуется проверять ещё и промежуточные сертификаты и/или кросс-сертификаты. Поэтому, если раньше сертификаты распространялись по одному, то теперь в практику входит распространение нескольких сертификатов — мультисертификатов (multi-certificate). Подобные мультисертификаты обычно называются связками сертификатов (certificate bundles), связками сертификатов УЦ (ca-bundles) или цепочками сертификатов (certificate chains). Регулярное обновление миллионов клиентов выдвигает серьёзные требования к логистике, поэтому всё более популярным становится распространение новых промежуточных сертификатов или кросс-сертификатов (и даже корневых сертификатов) через сервер. Существует три основных метода создания связок сертификатов:

1. С помощью структуры PKCS#7 (или RFC 5652). Обычно итоговый файл имеет расширение .p7b (поддерживается браузерами MSIE и Chrome для импорта мультисертификатов). Файлы с таким расширением никогда не содержат закрытого ключа.

2. С помощью структуры PKCS#12 (RFC 7292), представляющей собой суперконтейнер для PKCS#7 и PKCS#8. Итоговый файл может иметь расширения .p12 или .pkx (поддерживается браузерами MSIE и Chrome для импорта мультисертификатов). По соглашению, файл с расширением .pkx содержит и сертификат (PKCS#7), и закрытый ключ (PKCS#8); файл с расширением .p12 может как содержать, так и не содержать закрытого ключа. Для веб-серверов IIS требуются файлы с расширением .pfx (хотя также поддерживаются файлы с расширением .p12).

3. Объединение в определенном порядке закодированных в PEM сертификатов. Поскольку PEM-файлы с сертификатами (ключевое слово PEM CERTIFICATE) представляют собой текстовые файлы, их можно объединить друг с другом вручную с помощью текстового редактора или такой команды unix:

   cat intermediate2.crt intermediate1.crt root.crt > ca.pem
   # Порядок указания сертификатов отражает выполняемую клиентом
   # последовательность проверки: сертификат сервера,
   # промежуточные/кросс-сертификаты и, наконец, корневой сертификат.
   # Полученный в результате файл (в данном случае ca.pem) будет
   # использоваться в директиве Apache2 SSLCACertificateFile.
   

   Подобное склеивание файлов в формате PEM нашло широкое применение из-за его поддержки в Apache. В таких связках сертификатов никогда не присутствуют закрытые ключи.

Команды OpenSSL для конвертации, извлечения и манипуляций с сертификатами и ключами

В этом разделе показаны некоторые команды OpenSSL для выполнения различных манипуляций. В качестве исходного в OpenSSL используется формат PEM.

# конвертация PKCS12 > Извлечение сертификата PEM-формате
openssl pkcs12 -clcerts -nokeys -in cert.p12 -out usercert.pem 
openssl pkcs12 -clcerts -nokeys -in cert.p12 -out usercert.crt 
# извлекается только сертификат

openssl pkcs12 -nocerts -in cert.p12 -out userkey.pem
openssl pkcs12 -nocerts -in cert.p12 -out userkey.key
# извлекается только ключ

# конвертация PEM > PKCS12 (.p12 или .pkx)
# В результате получается файл в DER (бинарном) формате с расширением .p12 или .pfx
openssl pkcs12 -export -out cert.p12 -inkey ./userkey.pem -in ./usercert.pem
openssl pkcs12 -export -out cert.pkx -inkey ./userkey.pem -in ./usercert.pem
#ПРИМЕЧАНИЕ: в обоих приведённых случаях будет запрашиваться парольная фраза, чтобы её не задавать
# просто нажмите Enter на запрос пароля и его верификации, либо используйте следующую команду
openssl pkcs12 -export -out cert.p12 -inkey ./userkey.pem -in ./usercert.pem - nodes -passout pass:
# закодированные в PEM сертификат и ключ конвертируются в формат PKCS#12 (закодирован в DER)

Таблица соответствия стандартов PKCS#X и RFC

В этом разделе даны перекрёстные ссылки с широко используемых стандартов PKCS на их RFC-эквиваленты.

Работа с сертификатами в основных браузерах

Сертификаты могут быть импортированы в некоторые системы с помощью процедур, описанных в этом разделе. Периодически эта информация может изменяться. Для браузеров приводится версия браузера, чтобы показать, для какой именно версии приведённый метод является актуальным. Описывается импорт корневого или промежуточного сертификатов (в случае Chrome и MSIE должны быть выбраны соответствующие вкладки "Промежуточные центры сертификации" (Intermediate) или "Доверенные корневые центры сертификации" (Trusted Root)). Только Firefox напрямую принимает файлы с расширением .pem. Для MSIE и Chrome любые файлы с корневыми сертификатами, созданные с помощью описанных выше методов 1, 2, 3 или 3A, имеющие расширение .pem, можно просто переименовать из ca/cacert.pem в ca/cacert.cer или ca/cacert.crt по Вашему выбору.

MSIE (11): MSIE принимает файлы с расширением .cer, .crt, .p7b, .pfx, .p12 (возможно, и другие). MSIE -> Меню "Сервис" (Tools) -> "Свойства обозревателя" (Internet Options) -> Вкладка "Содержание" (Content) -> Кнопка "Сертификаты" (Certificates) -> Выберите соответствующее хранилище сертификатов -> Кнопка "Импорт" (Import), а затем выполните запросы мастера импорта.

Альтернативный метод для систем Windows 7+: использовать Консоль управления (Microsoft Management Console, MMC) с установленной оснасткой "Сертификаты" (Certificate). Перейдите к соответствующему хранилищу сертификатов -> Меню "Действие" (Actions) -> "Все задачи" (All tasks) -> "Импорт" (Import), а затем выполните запросы мастера импорта (принимает файлы с расширением .cer, .crt, .p7b, .pfx, .p12 (возможно, и другие)).

В окружении AD сертификаты также можно распространить с помощью объектов групповых политик (Group Policy Object, GPO). Загрузите "Администрирование" (Administrative Tools) -> "Управление групповой политикой" (Group Policy Manager) -> Раскройте пункт "Домены" (Domains) -> Щёлкните правой кнопкой мыши на "Default Domain Policy" и выберите "Изменить" (Edit) -> Раскройте пункт "Конфигурация компьютера" (Computer configuration) -> Раскройте пункт "Политики"->Раскройте пункт "Конфигурация Windows" (Windows Settings)->Раскройте пункт "Параметры безопасности" (Security Settings)->Раскройте пункт "Политики открытого ключа" (Public Key Settings)->Щёлкните правой кнопкой мыши на "Доверенные корневые центры сертификации" (Trusted Root Certificate Authorities)->Выберите "Импорт" (Import), а затем выполните запросы мастера импорта.

Firefox (41.x.x) Firefox принимает файлы с расширением .pem, .cer, .crt, .der или .p7b. Выберите меню "Инструменты" (Tools) -> "Настройки" (Options) -> "Дополнительные" (Advanced) -> Вкладка "Сертификаты" (Certificates) -> "Просмотр сертификатов" (View Certificates) -> Нажмите кнопку "Импортировать" (Import) и выберите файл.

Chrome (46.x.x.x) Chrome принимает файлы с расширением .cer, .crt, .p7b, .pfx, .p12 suffix (возможно, и другие). Выберите "Настройки" (Settings) -> Нажмите ссылку "Показать дополнительные настройки" (Enable Advanced Settings) -> Перейдите к разделу HTTPS/SSL -> Кнопка "Настроить сертификаты" (Manage Certificates) -> Выберите соответствующую вкладку -> Кнопка "Импорт" (Import), а затем выполните запросы мастера импорта.

RFC по теме

Список RFC, относящихся к TLS, сертификатам X.509 и PKI. Большинство из них упоминается в тексте этого документа. Список не полный, но мы обновляем его по мере обновления текста или при публикации подходящего RFC. Так что в конечном счёте он станет исчерпывающим.

Изменения страницы

Дата последнего изменения указана внизу страницы.

1. 25 января 2017 г.: В таблице соответствия стандартов PKCS#X и RFC обновлена ссылка на RFC для PKCS#5, добавлена информация по PKCS#1 со ссылкой на RFC. В список RFC добавлены RFC 8017 и 8018.
2. 16 сентября 2016: Исправлена опечатка в аббревиатуре CRMF. Добавлено примечание о введённом в RFC 7918 "фальстарте", позволяющем клиенту начинать передачу сообщения сразу после отправки 'Finished', не дожидаясь получения 'Finished' от сервера. В список RFC добавлены RFC 7918 и 7935.
3. 28 июля 2016 г.: Обновлён список RFC. Новый раздел об использовании полей subject и subjectAltName в сертификатах.
4. 13 июля 2016 г.: Добавлены недостающие гиперссылки.
5. 13 февраля 2016 г.: Обновлён список RFC, исправлены некорректные гиперссылки. Новый раздел об использовании сертификатов в окружении (многопользовательском) хостинг-провайдеров.
6. 2 ноября 2015 г.: Добавлена информация по связанным с TLS/SSL/сертификатами именам файлов, форматам и PKCS-контейнерам. Обновлена информация по импорту сертификатов в Chrome, Windows, MSIE и Firefox.
7. 28 октября 2015 г.: Обновлён список RFC. Добавлено определение сертификата конечного субъекта.
8. 23 октября 2015 г.: Обновлён список RFC. Добавлено примечание по расширению, позволяющему дополнять нулями размер сообщения ClientHello. Добавлено примечание по определённому в RFC 7633 расширению типа " Pivate Internet", позволяющее включать в сертификат расширения функционала TLS, что помогает в предотвращении атак. В описание расширений сертификата добавлены OID, чтобы можно было различить стандартные расширения X.509 (из пространства 2.5.29) и расширения "Private Internet" (из пространства 1.3.6.1.5.5.7.1). Текст примеров сокращён (в интересах пользователей с небольшими экранами).
9. 29 сентября 2015 г.: Обновлён список RFC. В описание протоколов TLS/SSL добавлено примечание по Extended Master Secret.
10. 14 июля 2015 г: Обновлён список RFC. Добавлено примечание об отмене SSL v3.0.
11. 10 июля 2015 г: Обновлён список RFC. Добавлено примечание о сертификатах Data Transmission Content Protection (DTCP) и их использовании в протоколе рукопожатия TLS (как определено в RFC 7562).
12. 30 мая 2015 г.: Обновлён список RFC. Добавлено примечание об определённом в RFC 7507 "наборе шифров" TLS_FALLBACK_SCSV.
13. 15 марта 2015 г.: Обновлён список RFC.
14. 5 января 2015 г.: Исправлена битая ссылка на раздел "Цепочки сертификатов X.509", исправлено неверное указание поля subjectPublicKeyInfo. Исправлена опечатка в описании поля subjectAltName для правильной идентификации использования атрибута dNSName.
15. 4 июля 2014 г.: Примечания об упрощённом формате сертификата, определённом в RFC 7250, в описаниях сообщений ClientHello, ServerHello, формата сертификата X.509 и атрибута SubjectPublicKeyInfo. Обновлён список RFC.
16. 21 января 2014 г.: Примечание в описании сообщения ClientHello о расширении Server Name Indication (SNI). Обновлён список RFC.
17. 22 декабря 2013 г.: Обновлён список RFC.
18. 18 декабря 2013 г.: Обновлён список RFC.
19. Ноябрь 2013 г.: Страница переделана в HTML5
20. Ноябрь 2013 г.: Порядок терминов на странице изменён с SSL/TLS на TLS/SSL для отображения современных тенденций.
21. Ноябрь 2013 г.: Обновлён рисунок 2.
22. Октябрь 2013 г.: В список RFC добавлены RFC 7027 и 7030. Обновлён текст, касающийся ECC.

Проблемы, комментарии, предположения, исправления (включая битые ссылки) или есть что добавить? Пожалуйста, выкроите время в потоке занятой жизни, чтобы написать нам, вебмастеру или в службу поддержки. Оставшийся день Вы проведёте с чувством удовлетворения.

Нашли ошибку в переводе? Сообщите переводчикам!