Restriction: This topic applies only when the Enterprise Server feature is enabled.
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.
Remember: Attackers who penetrate your network can make use of development and test systems to escalate their attacks.
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.