53

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?

Improve this question
0

2 Answers 2

Reset to default
32

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.

Improve this answer
4
  • 1
    OpenVPN 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.
    – Robin McCorkell
    Commented Apr 7, 2014 at 12:48
  • Also, how would keyUsage apply for non-CA certs? I edited the question to include it.
    – Robin McCorkell
    Commented Apr 7, 2014 at 12:54
  • @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
    Commented Sep 7, 2017 at 1:04
  • 4
    The openssl documentation does have a list of values, but unfortunately absolutely zero explanation of what they mean (and is therefore effectively useless).
    – Jan Hudec
    Commented Jul 27, 2020 at 15:23
130

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: digitalSignature, keyEncipherment, keyAgreement
  • V3 Profile: 
    [ v3_vpn_server ]
basicConstraints        = critical, CA:FALSE
subjectKeyIdentifier    = hash
authorityKeyIdentifier  = keyid:always, issuer:always
keyUsage                = critical, digitalSignature, keyEncipherment, keyAgreement 
extendedKeyUsage        = critical, serverAuth
subjectAltName          = @alt_vpn_server

VPN Client

  • keyUsage: digitalSignature, keyEncipherment
  • V3 Profile: 
    [ v3_vpn_client ]
basicConstraints        = critical, CA:FALSE
subjectKeyIdentifier    = hash
authorityKeyIdentifier  = keyid:always, issuer:always
keyUsage                = critical, 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

Improve this answer
4
  • 1
    When 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
    Commented Jan 9, 2018 at 15:35
  • 2
    It'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
    Commented Jan 17, 2018 at 15:10
  • @JW0914 for example Bacula uses the same cert for both server and client connections - I had to create a certificate that had keyUsage set to ns server and ns client at the same time. It did not work without this.
    – Edheldil
    Commented Aug 28, 2020 at 22:35
  • @Edheldil Netscape [browser] EKUs should not be used and if Bacula is still using them, that instance likely needs updating - correct EKUs are serverAuth and clientAuth. Using the same cert for a server and client is a security risk and not advised, as doing so enables an MITM attack to occur. If you are using the most current Bacula version, you may want to email tech support and ask how that's secure, requesting a detailed explanation.
    – JW0914
    Commented Aug 28, 2020 at 22:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .