Setting up a CA with OpenSSL

Procedure

To setup a CA with OpenSSL:
  1. Create a RSA private key in a PEM file:
    $ openssl genrsa -out rootCA1.key.pem -aes256 \
    -passout pass:ca1passwd

    The command creates the private key with the default size of 2048 bits and writes it encrypted in PEM format to the file "rootCA1.key.pem". The option "-aes256" tells the command to encrypt the private key using AES256 encryption. The encryption is based on the given password "ca1passwd".

    The output PEM file can be parsed using the following command. As the private key is encrypted, the password for the content in the input file must be provided:
    $ openssl rsa -in rootCA1.key.pem -passin pass:ca1passwd -text -noout
    RSA Private-Key: (2048 bit, 2 primes)
    modulus: ...
    publicExponent: 65537 (0x10001)
    privateExponent: ...
    prime1: ...
    prime2: ...
    exponent1: ...
    exponent2: ...
    coefficient: ...
    $

    where the "..." stand for blocks of binary data in hex format that is undecipherable without much deeper knowledge of the algorithm internals for RSA keys.

  2. Using the CA's private key, create a self-signed root CA certificate in a PEM file:
    $ mydn="/C=US/ST=Florida/L=Anytown/O=Acme Software Inc./OU=Database CA/"
    $ mydn=${mydn}"CN=Database CA Root1/emailAddress=dba_ca1@acme.info"
    $ openssl req -new -x509 -key rootCA1.key.pem -passin pass:ca1passwd \
    > -subj "${mydn}" -days 365 -out rootCA1.cert.pem

    The command "openssl req" uses the previously generated private key to create a self-signed certificate and writes it to the output file "rootCA1.cert.pem". Because the private key in the key input file is encrypted, the password for the key input file must be provided. The validity of the certificate is one year beginning with the creation. The option "-x509" causes the command to create a self-signed certificate rather than a certificate request.

    The option "-subj ..." specifies the distinguished subject name of the certificate owner. As this is a self-signed certificate, the issuer name automatically is the same as the subject name. For convenience, the longish subject name is given as the variable "${mydn}", defined by the previous two shell commands. A distinguished name consists of several fields like country, state, location, organization, organizational unit, common name, etc. The format is a '/' that starts each field, followed by the field specifier, '=', and the field value string. "/C=US" therefore means field "country" has the value "US". Note that the individual fields have a maximum length. E.g. the country field can only have two characters for the 2-letter country code.

    The following command can be used to parse the certificate in the PEM file and output its content:

      $ openssl x509 -in rootCA1.cert.pem -text -noout 
      Certificate:
          Data:
              Version: 3 (0x2)
              Serial Number: ...
              Signature Algorithm: sha256WithRSAEncryption
              Issuer: C = US, ST = Florida, L = Anytown, O = Acme Software Inc.,
                      OU = Database CA, CN = Database CA Root1,
                      emailAddress = dba_ca1@acme.info
              Validity
                  Not Before: Jun  2 08:50:33 2021 GMT
                  Not After : Jun  2 08:50:33 2022 GMT
              Subject: C = US, ST = Florida, L = Anytown, O = Acme Software Inc.,
                       OU = Database CA, CN = Database CA Root1,
                       emailAddress = dba_ca1@acme.info
              Subject Public Key Info:
                  Public Key Algorithm: rsaEncryption
                      RSA Public-Key: (2048 bit)
                      Modulus: ...
                      Exponent: 65537 (0x10001)
              X509v3 extensions:
                  X509v3 Subject Key Identifier:
                      10:6B:B1:E1:C9:D9:9A:7F:B4:FF:9C:16:77:DD:56:9E:A1:58:6C:01
                  X509v3 Authority Key Identifier:
                      keyid:
                      10:6B:B1:E1:C9:D9:9A:7F:B4:FF:9C:16:77:DD:56:9E:A1:58:6C:01
    
                  X509v3 Basic Constraints: critical
                      CA:TRUE
          Signature Algorithm: sha256WithRSAEncryption
               ...
      $
    
    Note:
    • As a root CA certificate, it is self-signed. Therefore, subject name and issuer name are the same. For the same reason, the X509 version 3 extensions Subject Key Identifier and Authority Key Identifier also are the same.

    • The Signature Algorithm is "sha256WithRSAEncryption". A signature algorithm of lower quality, like "sha1WithRSAEncryption", may not be accepted by newer versions of crypto libraries. With "openssl", "sha256WithRSAEncryption" normally is chosen by default. If for some reason the "openssl" command created a certificate with a lower quality signature algorithm, it may be better to include the option "-sha256" in the creation command to ensure compatibility with different crypto libraries, especially for newer versions.

    • The X509 version 3 extension Basic Constraints is present and has the attribute values critical and CA:TRUE. While the attribute critical is not so important, the attribute CA:TRUE is. Because this certificate is intended to be a (root) CA certificate, the extension attribute CA:TRUE is required by some crypto libraries, especially with newer versions. If the extension and attribute are missing, then the certificate later may not be considered a valid CA certificate. This is a typical cause for a client side authentication error during the TLS handshake. The error message can be something like "no CA certificate found", or similar.

    The private key and corresponding certificate are all that is needed for a functioning CA. The objects are stored in separate PEM files, which may be a bit cumbersome for safekeeping, but the PEM format is most convenient for issuing and signing user certificates for database servers. The private key is encrypted in its PEM file and therefore sufficiently protected. It is possible to store both, the private key and the certificate, in a password protected PKCS #12 keystore, but the protection would not be better than in the encrypted PEM file. Instead, the key and certificate would need to be extracted again into PEM files in order to use them for issuing and signing user certificates.