Using only self-signed certificates

This is the simplest setup for TLS communications. The server only needs a private key and the corresponding self-signed certificate that contains the public key of the key pair. The client only needs an exact copy of the server's self-signed certificate. No CA certificate is needed. Therefore, it is not necessary to request a certificate from a public CA and pay for it, nor is it necessary to set up a home-grown CA to issue certificates for the server. The client receives the copy of the self-signed certificate from a trusted source, probably some system administrator for the in-house database environment. With that, such a setup is quite valid from a security point of view. And it is simple to implement, at least as long as clients connect to just one single SSL server.

However, as such a simple database environment grows over time and more database servers get added, things become more complex. A client that connects to more than one database server needs an exact copy of each individual server's self-signed certificate. Managing the database clients' keystores gets more complicated, as the keystores contain multiple self-signed certificates, probably with different expiration dates. If one of the certificates expires, it may be necessary to re-create the complete keystore, combining the still valid certificates with the new replacement for the one expired certificate. The same is necessary when a new database server gets added to the environment. Every database client that should connect to this new database server needs its existing keystore to be re-created by adding the new self-signed certificate of the new database server. In a rather dynamic environment, this can become an ongoing and quite tiresome task.

One "simple solution" in such an environment would be to give each database server the same selfsigned certificate with the same private key. That way, all database clients only need a copy of this one self-signed certificate and can use it to authenticate all database servers alike when connecting to them. The private key in such a scenario would no longer be very private. Most probably, any responsible security administrator will veto such an approach. A second "simple solution" might be to give each database client the same keystore with all the self-signed certificates of all the database servers, regardless of whether an individual database client needs all of them or not. Still, changes in the database server landscape require updating of all database client keystores.

Using a CA is far easier in a dynamic environment with more frequent changes in the database server landscape,