Creating the keystore for a database client

About this task

The database client needs the CA certificate (chain) in order to authenticate the database server during the TLS handshake. Based on the examples above, the database server's user certificate was issued and signed by a home-grown CA. Therefore, the database client needs the CA certificate of this CA. As the CA used its root CA certificate to sign the database server's user certificate, there are no intermediate CAs involved. When authenticating the database server, the OneDB chain of certificates therefore is very simple. It consists only of the database server's user certificate and the CA's root CA certificate. The database client receives the database server's user certificate during the TLS handshake, and therefore only needs the root CA certificate in its own keystore. With that, just the PEM file with the root CA certificate is needed to create the database client's keystore.

Procedure

Create the keystore using the root CA certificate:

$ openssl pkcs12 -export -nokeys -in rootCA1.cert.pem \
> -caname rootCA1 -passout pass:c1passwd -out client1.p12

The command reads the root CA certificate from the input file "rootCA1.cert.pem" and creates the keystore in output file "client1.p12". This keystore is protected by password "c1passwd". The option "-nokeys" tells the command that no private key is to be read (or expected) from the input file.

The option "-caname rootCA1" provides "rootCA1" as value for the friendly name attribute of the SafeBag container, that holds the certificate in the keystore. As there is only this single (root) CA certificate in the input file, only a single "-caname ..." option is needed in the command. Even though the keystore contains only a single certificate, it is necessary to specify the "-caname ..." option with a friendly name attribute value. Omitting the option results in a SafeBag without the friendly name attribute and the certificate being ignored during the TLS handshake. This then causes an authentication failure during the TLS handshake, because no suitable CA certificate was found in the keystore.

(As for the database client only CA certificate(s) are needed, the keystore neither contains a private key nor a user certificate that would correspond to a private key. It is therefore not necessary to create a private key and corresponding user certificate for the database client. This also implies that all certificates in the database client's keystore are CA certificates, where at least one of them should be a root CA certificate.)

The content of the new keystore in file "client1.p12" can be parsed and examined with the following command:

$ openssl pkcs12 -in client1.p12 -passin pass:c1passwd -nodes -info
MAC: sha1, Iteration 2048
MAC length: 20, salt length: 8
PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048
Certificate bag
Bag Attributes
    friendlyName: rootCA1
subject=C = US, ST = Florida, L = Anytown, O = Acme Software Inc.,
        OU = Database CA, CN = Database CA Root1,
        emailAddress = dba_ca1@acme.info
issuer=C = US, ST = Florida, L = Anytown, O = Acme Software Inc.,
       OU = Database CA, CN = Database CA Root1,
       emailAddress = dba_ca1@acme.info
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

Now, the keystores for database server and database client have been created. The given examples are for a simple scenario where a home-grown CA is used to issue and sign the certificates for all database servers. For this, the home-grown CA uses a single self-signed root CA certificate. Therefore, database clients that have just this one root CA certificate in their keystore can connect to all database servers. The certificate chain used by the database client during the TLS handshake to authenticate the database server is trivial: it consists only of the database server's user certificate (received from the server during the TLS handshake) and the root CA certificate found in the database client's keystore.