OpenSSL CA keyUsage拡張
証明書のチェーンをセットアップします。サブCAに署名する自己署名の「ルート」CAを上部に配置すると、サブCAに署名し、クライアントとサーバーの証明書に署名できます。セットアップ時openssl.cnf、keyUsageパラメータに気付きました。これは明らかに、キーが使用されることになっているものに設定する必要があります。パラメーター値は文書化されていますが、特定の状況でどのパラメーターを使用するかについての情報が見つかりません。
keyUsage値は何を意味し、次の状況で何を使用すればよいですか？
- 自己署名ルートCA
- 中間CA（他のCAに署名できる）
- 中間CA（他のCAに署名できない）
- 非CA証明書
また、nsCertTypeなど、他の拡張機能を特定の値で指定する必要がありますか？
CA証明書は、それがルートであるか中間であるかに関係なく、keyCertSign拡張子が必要です。 CA証明書を使用して失効リスト（CRL）にも署名したい場合（通常はそれが必要です）、cRLSignも追加する必要があります。その他のkeyUsagesは、CA証明書では回避でき、回避する必要があります。
Opensslが受け入れる値のリストは ここに記載 です。
エンドエンティティ証明書の場合、opensslで文書化されている他の任意のkeyUsagesを使用できます。上記のCA拡張機能を含めないようにしてください。セキュリティの観点からは、必要以上にkeyUsagesを使用しないでください（特に、署名と暗号化には別の証明書を使用することをお勧めします）が、これは厳密な要件ではありません。
従来のkeyUsagesとは別に、extendedKeyUsage（EKU）拡張機能もあることに注意してください。これは、RFCの事前定義値に限定されず、理論的には任意のOIDを保持できます既知の値は、たとえば、証明書がタイムスタンプまたはOCSP応答に署名するためのものです。
nsCertTypeを使用する必要はありません。これらは、他のすべてのns *拡張機能とともに、古くからNetscapeによって定義されており、今後は使用しないでください。おそらくそれらをまだ使用しているソフトウェアはありません。
他の拡張機能の場合、絶対に必要なのはbasicConstraints拡張機能だけで、それに応じて設定する必要があるブールCAフラグがあります。 authorKeyIdentifierおよびsubjectkeyIdentifier拡張も強く推奨されます。
- ビルド済みopenssl.cnf
- Info 、必要なコマンドは430行目から
認証局と中間CA
自己署名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- Where
pathlen:は、署名できるCA/ICAの数と同じです pathlen:が0に設定されている場合、他のCA/ICAに署名できません
- Where
非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
CAのみ
keyCertSign
- サブジェクト公開鍵は、証明書の署名を検証するために使用されます
- この拡張子はCA証明書にのみ使用する必要があります
cRLSign
- サブジェクト公開鍵は、CRLなどの失効情報の署名を検証するためのものです
- この拡張子はCA証明書にのみ使用する必要があります
digitalSignature
- 証明書を使用してデジタル署名を適用できます
- デジタル署名は、エンティティ認証と整合性のあるデータオリジン認証によく使用されます
nonRepudiation
- 証明書を使用して上記のようにデータに署名できますが、証明書の公開鍵を使用して否認防止サービスを提供できます
- これにより、署名エンティティが何らかのアクションを誤って拒否するのを防ぎます
keyEncipherment
- 証明書を使用して対称キーを暗号化し、それをターゲットに転送することができます
- ターゲットはキーを復号化し、続いてそれを使用してエンティティ間のデータを暗号化および復号化します
dataEncipherment
- 証明書は、実際のアプリケーションデータを暗号化および復号化するために使用できます
keyAgreement
- 証明書により、鍵合意プロトコルを使用して、ターゲットとの対称鍵を確立できます
- 次に、対称鍵を使用して、エンティティ間で送信されるデータを暗号化および復号化できます
encipherOnly
- 鍵合意の実行中にデータを暗号化するためにのみ使用される公開鍵
- 必須KU：
keyAgreement
- 必須KU：
decipherOnly
- 鍵合意の実行中にデータを解読するためだけに使用される公開鍵
- 必須KU：
keyAgreement
- 必須KU：
RFC 5280 [4.2.1.3]
id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 }
ビット文字列は16進数です
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サーバー認証EKU、クライアントが認証できるサーバーを区別
- これは
nscertypeオプション（nsinnscertypeNetScape [ブラウザ]の略） - 必須KU：
digitalSignature、keyEnciphermentまたはkeyAgreement
clientAuth
- すべてのVPNクライアントは、このEKUが存在する状態で署名されている必要があります
- SSL/TLS Web/VPNクライアント認証EKUは、クライアントをクライアントのみとして区別します
- 必須KU：
digitalSignatureおよび/またはkeyAgreement
codeSigning
- コード署名
- 必須KU：
digitalSignature、nonRepudiation、および/またはkeyEnciphermentまたはkeyAgreement
- 必須KU：
emailProtection
- S/MIMEによるメール保護により、暗号化されたメールを送受信できます
- 必須KU：
digitalSignature、keyEnciphermentまたはkeyAgreement
- 必須KU：
timeStamping
- 信頼できるタイムスタンプ
- 必須KU：
digitalSignature、nonRepudiation
- 必須KU：
OCSPSigning
- OCSP署名
- 必須KU：
digitalSignature、nonRepudiation
- 必須KU：
msCodeInd
- Microsoft個別コード署名（authenticode）
- 必須KU：
digitalSignature、keyEnciphermentまたはkeyAgreement
- 必須KU：
msCodeCom
- Microsoft Commerical Code Signing（authenticode）
- 必須KU：
digitalSignature、keyEnciphermentまたはkeyAgreement
- 必須KU：
mcCTLSign
- Microsoft信頼リスト署名
- 必須KU：
digitalSignature、nonRepudiation
- 必須KU：
msEFS
- Microsoft暗号化ファイルシステムの署名
- 必須KU：
digitalSignature、keyEnciphermentまたはkeyAgreement
- 必須KU：
!!!活用しないでください!!!
ipsecEndSystem、ipsecTunnel、＆ipsecUser
- 1999年に割り当てられたこれらの値のセマンティクスは、明確に定義されたことはありません
- RFC 4945：これら3つのEKU値の使用は廃止され、この仕様によって明示的に非推奨になっています[5.1.3.12]
ipsecIKE
- IPSecインターネットキー交換
- これは上の3つと同じボートにあると思います
- この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