I want to set up a chain of certificates, with a self signed 'root' CA at the top that signs sub CAs, which can then sign client and server certificates. When setting up openssl.cnf, I noticed a keyUsage parameter, which apparently needs to be set to whatever the key is supposed to be used for. While the parameter values are documented, I can't find any information about which ones to use in certain circumstances.

What do the keyUsage values mean, and what should I use in the following situations?

• Self signed root CA
• Intermediate CA (that can sign other CAs)
• Intermediate CA (that cannot sign other CAs)
• Non-CA certificates

Also, do other extensions need to be specified with certain values, such as nsCertType?

2 Answers

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.

^{Custom openssl.cnf (info) and how to use, with commands required beginning on Line 430}

Certificate Authorities & Intermediate CAs

Self-signed CA

• keyUsage: cRLSign, digitalSignature, keyCertSign
  ^{(Should not contain any other KUs and no 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 and no EKUs)}
• V3 Profile:

  [ v3_ica ]
  basicConstraints = critical, CA:TRUE, pathlen:0
  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
    ^{(if pathlen is not specified/number set, it can sign an infinite/specified number of CAs/ICAs)}

Non-CA Certificates

VPN/Web 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

^{CAs/ICAs should not have any EKUs specified}

serverAuth

• All VPN/Web servers should be signed with this EKU present
  ^{(this supersedes nscertype options, as ns in nscertype stands for NetScape [browser])}
  • SSL/TLS VPN/Web Server authentication EKU, distinguishing a server which clients can authenticate against
  • 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