RFC: 2246
Оригинал: The TLS Protocol Version 1.0
Другие версии: RFC 4346
Категория: Предложенный стандарт
Дата публикации:
Авторы: ,
Перевод: Семенов Юрий Алексеевич

7.4.2. Сертификат сервера

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

Тип сертификата должен соответствовать выбранному алгоритму обмена ключами шифров, обычно это сертификат X.509v3. Он должен содержать ключ, который соответствует методу обмена ключами. Если не специфицировано обратного, алгоритм подписи для сертификата должен быть тем же, что и алгоритм для ключа сертификата. Если не специфицировано обратного, общедоступный ключ может иметь любую длину.

  • Алгоритм обмена ключами
  • Тип сертификата ключа
  • RSA
  • Общедоступный ключ RSA; сертификат должен допускать использование ключа для шифрования.
  • RSA_EXPORT
  • Общедоступный ключ RSA с длиной больше чем 512 бит, который может быть использован для подписи, или ключ длиной 512 бит или короче, который может быть использован для шифрования или подписи.
  • DHE_DSS
  • Общедоступный ключ DSS.
  • DHE_DSS_EXPORT
  • Общедоступный ключ DSS.
  • DHE_RSA
  • Общедоступный ключ RSA, который может использоваться для подписи.
  • DHE_RSA_EXPORT
  • Общедоступный ключ RSA, который может использоваться для подписи.
  • DH_DSS
  • Ключ Diffie-Hellman. Алгоритмом, используемым для подписи сертификата, должен быть DSS.
  • DH_RSA
  • Ключ Diffie-Hellman. Алгоритмом, используемым для подписи сертификата, должен быть RSA.

Все сертификатные профайлы, ключи и криптографические форматы определены рабочей группой IETF PKIX [RFC2459]. Когда присутствует расширение использования ключа, бит digitalSignature должен быть установлен для ключа выбранного для подписи, как это описано выше, а бит keyEncipherment должен присутствовать, чтобы разрешить шифрование, как это описано выше. Бит keyAgreement должен быть установлен для сертификатов Diffie-Hellman.

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

Структура этого сообщения:

opaque ASN.1Cert<1..2^24-1>;

struct {
    ASN.1Cert certificate_list<0..2^24-1>;
} Certificate;
  • certificate_list
  • Это последовательность (цепочка) сертификатов X.509v3. Сертификат отправителя должен быть записан в списке первым. Каждый следующий сертификат должен непосредственно сертифицировать предшествующий сертификат. Так как верификация сертификата требует, чтобы корневые ключи распределялись независимо, самоподписывающий сертификат, который специфицирует корневой источник сертификата, может быть опционно удален из цепочки, в предположении, что партнер должен уже иметь его, чтобы проверить его в любом случае.

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

2007 - 2018 © Русские переводы RFC, IETF, ISOC.