8

Я хочу создать цепочку сертификатов с самоподписанным «корневым» ЦС наверху, который подписывает вспомогательные ЦС, которые затем могут подписывать сертификаты клиента и сервера. При настройке openssl.cnf я заметил параметр keyUsage , который, очевидно, должен быть установлен в соответствии с тем, для чего предполагается использовать ключ. Хотя значения параметров задокументированы, я не могу найти никакой информации о том, какие из них использовать при определенных обстоятельствах.

Что означают значения keyUsage и что я должен использовать в следующих ситуациях?

  • Самоподписанный корневой CA
  • Промежуточный ЦС (который может подписывать другие ЦС)
  • Промежуточный ЦС (который не может подписать другие ЦС)
  • Сертификаты не CA

Кроме того, другие расширения должны быть определены с определенными значениями, такими как nsCertType?

|источник

2 ответа2

16

Центры сертификации и промежуточные центры сертификации

Самоподписанный CA

  • keyUsage: cRLSign , digitalSignature , keyCertSign
    • Не должно содержать никаких других KU или EKU

  • Профиль V3:

    [ v3_ca ]
basicConstraints        = critical, CA:TRUE
subjectKeyIdentifier    = hash
authorityKeyIdentifier  = keyid:always, issuer:always
keyUsage                = critical, cRLSign, digitalSignature, keyCertSign
subjectAltName          = @alt_ca

Средний CA

  • keyUsage: cRLSign , digitalSignature , keyCertSign
    • Не должно содержать никаких других KU или EKU

  • Профиль V3:

    [ v3_ica ]
basicConstraints        = critical, CA:TRUE, pathlen:1
subjectKeyIdentifier    = hash
authorityKeyIdentifier  = keyid:always, issuer:always
keyUsage                = critical, cRLSign, digitalSignature, keyCertSign
subjectAltName          = @alt_ica
    • Где pathlen: равно количеству CA /ICA, которые он может подписать
    • Не может подписать другие CA /ICA, если pathlen: установлен в 0

Сертификаты не CA

VPN-сервер

  • keyUsage: nonRepudiation , digitalSignature , keyEncipherment , keyAgreement

  • Профиль V3:

    [ v3_vpn_server ]
basicConstraints        = critical, CA:FALSE
subjectKeyIdentifier    = hash
authorityKeyIdentifier  = keyid:always, issuer:always
keyUsage                = critical, nonRepudiation, digitalSignature, keyEncipherment, keyAgreement 
extendedKeyUsage        = critical, serverAuth
subjectAltName          = @alt_vpn_server

VPN-клиент

  • keyUsage: nonRepudiation , digitalSignature , keyEncipherment

  • Профиль V3:

    [ v3_vpn_client ]
basicConstraints        = critical, CA:FALSE
subjectKeyIdentifier    = hash
authorityKeyIdentifier  = keyid:always, issuer:always
keyUsage                = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage        = critical, clientAuth
subjectAltName          = @alt_vpn_client

keyUsage

ТОЛЬКО СА

keyCertSign

  • Тематический открытый ключ используется для проверки подписей на сертификатах
  • Это расширение должно использоваться только для сертификатов CA

cRLSign

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

digitalSignature

  • Сертификат может быть использован для применения цифровой подписи
    • Цифровые подписи часто используются для аутентификации объекта и аутентификации источника данных с целостностью

nonRepudiation

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

keyEncipherment

  • Сертификат может быть использован для шифрования симметричного ключа, который затем передается в целевой
    • Цель расшифровывает ключ, впоследствии используя его для шифрования и дешифрования данных между объектами

dataEncipherment

  • Сертификат может быть использован для шифрования и дешифрования фактических данных приложения

keyAgreement

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

encipherOnly

  • Открытый ключ используется только для шифрования данных при выполнении согласования ключей
    • Req. КУ: keyAgreement

decipherOnly

  • Открытый ключ используется только для дешифрования данных при выполнении согласования ключей
    • Req. КУ: keyAgreement

RFC 2549 [4.2.1.3]

id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 }

  • Битовая строка является шестнадцатеричной

    KeyUsage ::= BIT STRING {
    digitalSignature    (0),
    nonRepudiation      (1),
    keyEncipherment     (2),
    dataEncipherment    (3),
    keyAgreement        (4),
    keyCertSign         (5),
    cRLSign             (6),
    encipherOnly        (7),
    decipherOnly        (8)
}

extendedKeyUsage

serverAuth

  • Все VPN-серверы должны быть подписаны с этим подарком EKU
    • SSL/TLS Web/VPN Server аутентификация EKU, отличающая сервер, на котором клиенты могут аутентифицироваться
    • Это заменяет параметры nscertype (ns в nscertype означает NetScape [браузер])
    • Req. KU: digitalSignature , keyEncipherment или keyAgreement

clientAuth

  • Все клиенты VPN должны быть подписаны с этим подарком EKU
    • SSL/TLS Web/VPN Client аутентификация EKU, отличающая клиента только как клиента
    • Req. KU: digitalSignature и / или keyAgreement

codeSigning

  • Подписание кода
    • Req. KU: digitalSignature , nonRepudiation и / или keyEncipherment или keyAgreement

emailProtection

  • Защита электронной почты через S/MIME, позволяет отправлять и получать зашифрованные письма
    • Req. KU: digitalSignature , keyEncipherment или keyAgreement

timeStamping

  • Доверенная временная метка
    • Req. KU: digitalSignature , nonRepudiation

OCSPSigning

  • Подписание OCSP
    • Req. KU: digitalSignature , nonRepudiation

msCodeInd

  • Индивидуальная подпись кода Microsoft (authenticode)
    • Req. KU: digitalSignature , keyEncipherment или keyAgreement

msCodeCom

  • Подписание коммерческого кода Microsoft (authenticode)
    • Req. KU: digitalSignature , keyEncipherment или keyAgreement

mcCTLSign

  • Подписание списка доверия Microsoft
    • Req. KU: digitalSignature , nonRepudiation

msEFS

  • Подпись зашифрованной файловой системы Microsoft
    • Req. KU: digitalSignature , keyEncipherment или keyAgreement

!!! НЕ ДОЛЖЕН ИСПОЛЬЗОВАТЬСЯ !!!

ipsecEndSystem, ipsecTunnel и ipsecUser

  • Назначенная в 1999 году семантика этих значений никогда не была четко определена
  • RFC 4945: использование этих трех значений EKU устарело и явно не рекомендуется в данной спецификации [ 5.1.3.12 ]

ipsecIKE

  • IPSec Интернет-обмен ключами
    • Я считаю, что это в той же лодке, как три выше
    • Необходимо провести исследование, чтобы определить, не следует ли больше использовать этот EKU.
  • clientAuth может использоваться в сертификате клиента IPSec VPN

RFC 5280 [4.2.1.12]

anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 }

  • id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }

    • id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }

      • Аутентификация сервера TLS
      • KU биты для:
        digitalSignature, keyEncipherment или keyAgreement

    • id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 }

      • Аутентификация клиента TLS
      • KU биты для:
        digitalSignature и / или keyAgreement

    • id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 }

      • Подписание загружаемого исполняемого кода
      • KU биты для:
        digitalSignature

    • id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 }

      • Защита электронной почты
      • KU биты для:
        digitalSignature, nonRepudiation и / или keyEncipherment или keyAgreement

    • id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 }

      • Привязка хеша объекта ко времени
      • KU биты для:
        digitalSignature и / или nonRepudiation

    • id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 }

      • Подписание ответов OCSP
      • KU биты для:
        digitalSignature и / или nonRepudiation

|источник
9

Любой сертификат CA, независимо от того, является ли он корневым или промежуточным, должен иметь расширение keyCertSign . Если вы хотите подписать список отзыва (CRL) также с помощью сертификата CA (вы, как правило, этого хотите), то вам также необходимо добавить cRLSign . Любых других ключей можно и нужно избегать для сертификатов CA.

Список значений, принятых openssl, документирован здесь.

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

Обратите внимание, что помимо классических keyUsages, есть также extendedKeyUsage (EKU), которое не ограничено предопределенными значениями в RFC, но теоретически может содержать любой OID, который вам нравится. Известные значения относятся, например, к сертификатам для подписи меток времени или ответов OCSP.

Вам не нужно использовать nsCertType . Они, вместе со всеми другими расширениями ns *, определены Netscape давным-давно и больше не должны использоваться. Вы, вероятно, не найдете никакого программного обеспечения, все еще использующего их.

А для других расширений единственное, что абсолютно необходимо, - это расширение basicConstraints которое имеет логический флаг CA который вы должны установить соответствующим образом. Также рекомендуется использовать расширения authorKeyIdentifier и subjectkeyIdentifier.

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .