Your CA Certificate, Key and Password

The Demo CA follows the best practices for modern CAs. That includes using two levels of CA certificates. There is a root certificate, which is self-signed. The root is used to sign an intermediate certificate, and then entity (client and server) certificates issued by the CA are signed by the intermediate.

Using this structure in Demo CA mimics public CAs and many internal organizational CAs, and lets Enterprise Server administrators see how certificate chains are configured. A certificate chain is the full collection of certificates from the entity to the root. When one participant (client or server) in a TLS conversation receives a certificate from the other side, part of the process it uses to verify the certificate involves reconstructing the full chain from the entity certificate to a trusted root. The sender might send just its entity certificate, but good practice is to include any intermediate certificates in the chain, and possibly even the root itself to assist in problem resolution. On the receiving side, including not just the root but the intermediate as well in the collection of trusted certificates (also called trust anchors) can improve interoperability.

Each certificate is associated with a private key, which can be in a separate file, or in the case of some file formats, such as PKCS#12 (.p12), included in the same file as the certificate. The private key is needed to use the certificate to sign a message or prove identity; it is not needed by the recipient to verify identity. So for example, when you configure an enterprise server listener to use a server certificate, you will need the private key for that certificate as well; but when configuring the Demo CA root and intermediate certificates as trusted, you do not need their keys.

Private keys are typically protected using passphrases. The Demo CA scripts will prompt you for passphrases as it creates and uses private keys. It is important to keep these passphrases secure if you use any Demo CA certificates for security, even to secure an enterprise server instance on development or test systems.

When the Demo CA scripts have been run, certificates and the private keys for entity certificates can be found in the entities directory tree. There you will find:

• A directory named CAs, which will contain the following:
  • CARootECCert.pem, the Demo CA root certificate in PEM format, including a text representation of the certificate contents. The "EC" indicates this is an ECC, or Elliptic Curve Cryptography, certificate.
  • CARootECCert.p7b, the root certificate in PKCS#7 format, which is used by some software for importing certificates.
  • EC_CAint.pem, the intermediate CA certificate.
  • EC_CAcollection.pem, the root and intermediate certificates in a single file. This is typically the file you will want to use when you need to specify a trust store for verifying Demo CA certificates, for example, if you are configuring an enterprise server listener to accept client certificates.
  • EC_CAcollection.p7b, the same in PKCS#7 format. This is suitable for importing into the Windows Certificate Manager, for example.
• A directory named typically for the system where you ran Demo CA. If you run the CreateNewUserCerts script more than once, there should be one directory here for each Common Name (CN) you provided to the script. This directory typically includes the following:
  • Certificate Signing Request files, with an extension of .csr. These are used to request a certificate from the CA.
  • clientcert_*. these are various flavors of the "machine" client certificate and its private key, which can be used by a client program to identify itself to the server using the hostname of the system where you ran Demo CA. Besides the .pem and .p7b formats described above, you will see a .p12 (PKCS#12) file. PKCS#12 contains both the certificate chain and key, so it is useful for importing into systems that have a certificate import function, such as the Windows Certificate Manager. You can also use a PKCS#12 file with Enterprise Server by specifying the .p12 file for both the certificate and key file.
  • clientusercert_*. these are similar to the clientcert files, but identify the client as a person rather than a machine. Specifically, they use the operating system username of the user who ran the Demo CA scripts. Some applications which allow or require client certificates want to receive client certificates that identify the client machine; others want certificates that identify the client user. So Demo CA generates both.
  • srvcert_*. these are the server certificate and private key generated by Demo CA. They identify the machine where Demo CA was run, by its fully-qualified domain name and also by any alternative names or IP addresses supplied by the Demo CA user when prompted by the script.

The other directories created by Demo CA hold the files needed by the CA. There is one for the root CA certificate, and one for the intermediate. You can examine these if you wish, but their contents are not needed when configuring Enterprise Server for TLS.

If you use Demo CA for any purpose other than short-term experimentation, Micro Focus recommends backing up its contents to avoid disruption.