OpenSSL CA keyUsage extension

Solution 1:

Any CA certificate, no matter if it's a root or an intermediate, must have the keyCertSign extension. If you want to sign a revocation list (CRL) with the CA certificate as well (you usually do want that), than you have to add cRLSign as well. Any other keyUsages can and should be avoided for CA certificates.

The list of values accepted by openssl is documented here.

For end-entity certificates you can use any of the other keyUsages as documented by openssl, just make sure you do not include the CA-extensions mentioned above. From a security perspective, you should not use more keyUsages then neccesary (especially it is advised to use seperate certificates for signing and encryption), but that is not a strict requirement.

Note that apart from the classic keyUsages, there is also the extendedKeyUsage (EKU) extension, which is not limited to predefined values in the RFC but can theoretically hold any OID you like. Known values are for instance for certificates to sign timestamps or OCSP responses.

You don't need to use nsCertType. Those, along with all the other ns* extensions, where defined by Netscape ages ago and should not be used anymore. You probably won't find any software around still using them.

A for other extensions, the only thing that is absoluetely required is the basicConstraints extension which has a boolean CA flag which you must set accordingly. The authorityKeyIdentifier and subjectkeyIdentifier extensions are also highly recommended.

Solution 2:

Prebuilt openssl.cnf and an example of how to use
- Info, with commands required beginning on Line 430

Certificate Authorities & Intermediate CAs

Self-signed CA

keyUsage: cRLSign, digitalSignature, keyCertSign
- Should not contain any other KUs or EKUs

V3 Profile:

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

Intermediate CA

keyUsage: cRLSign, digitalSignature, keyCertSign
- Should not contain any other KUs or EKUs

V3 Profile:

  [ 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: is equal to the number of CAs/ICAs it can sign
Can not sign other CAs/ICAs if pathlen: is set to 0

Non-CA Certificates

VPN Server

keyUsage: nonRepudiation, digitalSignature, keyEncipherment, keyAgreement

V3 Profile:

  [ 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 Client

keyUsage: nonRepudiation, digitalSignature, keyEncipherment

V3 Profile:

  [ 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 ONLY

keyCertSign

Subject public key is used to verify signatures on certificates
This extension must only be used for CA certificates

cRLSign

Subject public key is to verify signatures on revocation information, such as a CRL
This extension must only be used for CA certificates

digitalSignature

Certificate may be used to apply a digital signature
- Digital signatures are often used for entity authentication & data origin authentication with integrity

nonRepudiation

Certificate may be used to sign data as above but the certificate public key may be used to provide non-repudiation services
- This prevents the signing entity from falsely denying some action

keyEncipherment

Certificate may be used to encrypt a symmetric key which is then transferred to the target
- Target decrypts key, subsequently using it to encrypt & decrypt data between the entities

dataEncipherment

Certificate may be used to encrypt & decrypt actual application data

keyAgreement

Certificate enables use of a key agreement protocol to establish a symmetric key with a target
Symmetric key may then be used to encrypt & decrypt data sent between the entities

encipherOnly

Public key used only for enciphering data while performing key agreement
- Req. KU: keyAgreement

decipherOnly

Public key used only for deciphering data while performing key agreement
- Req. KU: keyAgreement

RFC 5280 [4.2.1.3]

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

Bitstring is hexadecimal

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

extendedKeyUsage

serverAuth

All VPN servers should be signed with this EKU present
- SSL/TLS Web/VPN Server authentication EKU, distinguishing a server which clients can authenticate against
- This supersedes nscertype options (ns in nscertype stands for NetScape [browser])
- Req. KU: digitalSignature, keyEncipherment or keyAgreement

clientAuth

All VPN clients must be signed with this EKU present
- SSL/TLS Web/VPN Client authentication EKU distinguishing a client as a client only
- Req. KU: digitalSignature and/or keyAgreement

codeSigning

Code Signing
- Req. KU: digitalSignature, nonRepudiation, and/or keyEncipherment or keyAgreement

emailProtection

Email Protection via S/MIME, allows you to send and receive encrypted emails
- Req. KU: digitalSignature, keyEncipherment or keyAgreement

timeStamping

Trusted Timestamping
- Req. KU: digitalSignature, nonRepudiation

OCSPSigning

OCSP Signing
- Req. KU: digitalSignature, nonRepudiation

msCodeInd

Microsoft Individual Code Signing (authenticode)
- Req. KU: digitalSignature, keyEncipherment or keyAgreement

msCodeCom

Microsoft Commerical Code Signing (authenticode)
- Req. KU: digitalSignature, keyEncipherment or keyAgreement

mcCTLSign

Microsoft Trust List Signing
- Req. KU: digitalSignature, nonRepudiation

msEFS

Microsoft Encrypted File System Signing
- Req. KU: digitalSignature, keyEncipherment or keyAgreement

!!! SHOULD NOT BE UTILIZED !!!

ipsecEndSystem, ipsecTunnel, & ipsecUser

Assigned in 1999, the semantics of these values were never clearly defined
RFC 4945: The use of these three EKU values is obsolete and explicitly deprecated by this specification [5.1.3.12]

ipsecIKE

IPSec Internet Key Exchange
I believe this is in the same boat as the three above
- Research needs to be performed to determine if this EKU should also no longer be utilized
clientAuth can be utilized in an IPSec VPN client cert

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 server authentication
    - KU bits for:
      digitalSignature, keyEncipherment or keyAgreement
- id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 }
  - TLS client authentication
    - KU bits for:
      digitalSignature and/or keyAgreement
- id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 }
  - Signing of downloadable executable code
    - KU bits for:
      digitalSignature
- id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 }
  - Email protection
    - KU bits for:
      digitalSignature, nonRepudiation, and/or keyEncipherment or keyAgreement
- id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 }
  - Binding the hash of an object to a time
    - KU bits for:
      digitalSignature and/or nonRepudiation
- id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 }
  - Signing OCSP responses
    - KU bits for:
      digitalSignature and/or nonRepudiation

OpenSSL CA keyUsage extension

Solution 1:

Solution 2:

Certificate Authorities & Intermediate CAs

Self-signed CA

Intermediate CA

Non-CA Certificates

VPN Server

VPN Client

keyUsage

CA ONLY

RFC 5280 [4.2.1.3]

extendedKeyUsage

!!! SHOULD NOT BE UTILIZED !!!

RFC 5280 [4.2.1.12]

Related

Recent Posts