Setting up a home-grown certificate authority (CA)

While it seams easier to set up keystores for TLS communications without involving a CA, this is not always the case. Especially in an environment with a dynamic database server landscape, properly maintaining the keystores for the database clients with all the self-signed certificates can become a permanent headache. On the other hand, using certificates from a public CA (instead of only selfsigned certificates) entails the overhead of dealing with the public CA and the associated costs. Therefore, setting up a "home-grown" CA can be a valid compromise. As long as all communication partners (e.g. within a company intranet) agree to trust their own CA, there may be little reason to use a publicly trusted CA. Instead, the complete control over one's own CA and the absence of costs are strong advantages.

Setting up a home-grown CA is not very difficult. All that this CA needs is a private key and the corresponding certificate that contains the public key. In the scenario of a home-grown CA, there is little use for any intermediate CAs. Therefore, the certificate of the CA is the root CA certificate, which actually is a self-signed certificate. A self-signed root CA certificate is created in the same way as a self-signed server certificate. For convenience (and security), the CA's private key and root CA certificate probably should be stored in its own keystore, just for the CA.

With the CA in place, the procedure for obtaining a user certificate for a database server pretty much is the same as it would be with a public CA. First, a private key needs to be generated for the server. Instead of using this private key to create a self-signed certificate, it is used to create a certificate request. This certificate request already contains most of the certificate content, including the public key that matches the server's private key. The certificate request is given to the CA. The CA uses the certificate request together with its own private key to create and sign the user certificate. The created user certificate is handed back to the database server. Now, the database server's keystore can be created with the server's private key and this user certificate.

In this case, the certificate is for a database server, it therefore also is called server certificate. But for the CA itself, there is no difference between a user certificate for a server or a user certificate for a client. They are just user certificates (as opposed to CA certificates). The CA may also hand its own CA certificate to the server, as any client will need this CA certificate to authenticate the server. In the home-grown CA environment, the administrator can directly distribute the CA certificate to the database clients. Or even better, create a keystore for the database clients that contains just this CA certificate and distribute this ready-to-use keystore to all the database clients.

Compared to using self-signed server certificates the overhead of the CA's keystore has been added. But at the same time, the keystores of the clients have been simplified. In fact, all clients can just use a copy of the same keystore. However, the real advantage of using a (home-grown) CA shows in a dynamic database server landscape: Adding or removing database servers does not require any change in the keystores of the database clients. All that is needed for a new database server is done on the server side: create a new private key, a new certificate request, have the CA create and sign the user certificate for the new database server using its own existing private key, then create the database server's keystore.