Extracting certificates for the database client from the database server's keystore
When using a CA to issue and sign the user certificate for a database server, then the
database client needs the CA certificate (or the chain of CA certificates if intermediate CAs
are involved) to authenticate the database server during the TLS handshake. If the CA
certificate(s) are already in the database server's keystore (and the PEM files of the
certificate(s) perhaps not at hand), it may be the easiest to extract the CA certificates from
the database server's keystore and then use the extracted certificates(s) to create the database
client's keystore. For the extraction, a command like the following can be
used:
$ openssl pkcs12 -in server1.p12 -passin pass:s1passwd \
> -cacerts -nokeys -out server1.cacerts.pem
However, in an environment where the database server uses a self-signed certificate and no CA
is involved, things are slightly different. In this case, the database client needs the
self-signed certificate of the database server to use it like a CA certificate during the TLS
handshake. But from the viewpoint of the database server, this self-signed certificate is not a
CA certificate, instead it is the database server's own user certificate. Therefore, to extract
the self-signed certificate from the database server's keystore, the option "-clcerts" should be
used instead of the option "-cacerts". The command therefore would look like the
following:
$ openssl pkcs12 -in server2.p12 -passin pass:s2passwd \
> -clcerts -nokeys -out server2.selfsignedcert.pem
Assuming a keystore for database server 2 that contains the database server's private key and the corresponding self-signed certificate, the command extracts this self-signed certificate and stores it in the PEM output file "server2.selfsignedcert.pem".
When creating the client keystore, the command "openssl pkcs12 -export ..." in both cases, for a self-signed certificate as well as CA certificate(s), needs the appropriate "-caname ..." option. In the database client's perspective, both certificates are CA certificates and are to be loaded without a corresponding private key.