OpenSSL CA расширение keyUsage

Question

OpenSSL CA расширение keyUsage

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

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

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

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

50

ssl certificate openssl

Источник

Xenopathic 07 апр '14 в 10:23

2 ответа

Решение

Готовый openssl.cnf
- Информация, с необходимыми командами, начинающимися в строке 430

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

Самоподписанный 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. KU: keyAgreement

decipherOnly

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

RFC 5280 [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 варианты (нс в 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

116

Источник

JW0914 07 сен '17 в 02:05

Другие вопросы по тегам ssl certificate openssl

mat 07 апр '14 в 11:55 2014-04-07 11:55 · Accepted Answer · 2014-04-07 11:55

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

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

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

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

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

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