OpenSSL CA keyUsage extension

  • 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


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.

Tags:

Ssl

Openssl

Certificate

Recent Posts