OpenSSL CA keyUsage extension

15

13

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?

Xenopathic

Posted 2014-04-07T10:23:32.317

Reputation: 746

Answers

12

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.

mat

Posted 2014-04-07T10:23:32.317

Reputation: 467

@Xenopathic nc-cert-type really should no longer be used in OpenVPN, as the "ns" stands for NetScape, as in the now defunct NetScape Browser. The option remote-cert-eku "TLS Web Server Authentication" should be used, provided the server cert was generated with EKU serverAuth and the client cert(s) generated with EKU clientAuth. One can also specify remote-cert-ku <hex value>, where <hex value> is the hex value of KUs assigned. – JW0914 – 2017-09-07T01:04:18.213

1OpenVPN has the ns-cert-type option, set by default in Arch's example client.conf, which looks for nsCertType. Interesting how it is still used in some places. – Xenopathic – 2014-04-07T12:48:15.983

Also, how would keyUsage apply for non-CA certs? I edited the question to include it. – Xenopathic – 2014-04-07T12:54:14.667

34

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

JW0914

Posted 2014-04-07T10:23:32.317

Reputation: 2 135

1When you say "SSL/TLS Web/VPN Client authentication EKU distinguishing a client as a client only" means is not possible to have a just one certificate that works to both server and client? – Rodney Salcedo – 2018-01-09T15:35:44.993

1It's possible to add both EKUs, however there shouldn't be any reason to do so, as I'm not aware of any server daemon that can act as both a client and a server at the same time, off the same config (or vice versa). – JW0914 – 2018-01-17T15:10:15.753

Asked: 2014-04-07T10:23:32.317

Viewed: 44 408 times

Active: 2019-11-19T13:40:33.500