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.