Network encryption and authentication
Derby Server and Administration Guide
48
Network encryption and authentication with SSL/TLS
By default, all Derby network traffic is unencrypted, with the exception of user names and
user passwords which may be encrypted separately (See
). There
is also no network layer access control mechanism. For deployment scenarios where
these are possible security issues, Derby Network Server supports network security with
Secure Socket Layer/Transport Layer Security (SSL/TLS).
With SSL/TLS, the client/server communication protocol is encrypted and both the client
and the server may independently of each other require certificate based authentication
of the other part.
It is assumed that the reader is somewhat familiar with SSL, key pairs and certificates.
This documentation is also based on the Java Development Kit (JDK) and its
keytool
application.
For the remainder of this section, the term SSL is used for SSL/TLS and the term peer
is used for the other part of the communication (The server's peer is the client and vice
versa).
SSL for Derby (both for client and for server) operates in three possible modes:
off
The default, no SSL encryption
basic
SSL encryption, no peer authentication
peerAuthentication
SSL encryption and peer authentication
Peer authentication may be set either on the server or on the client or on both. Peer
authentication means that the other side of the SSL connection is authenticated based on
a trusted certificate installed locally.
Alternatively, a Certification Authority (CA) certificate may be installed locally and the
peer has a certificate signed by that authority. How to achieve this is not descibed in this
document. Consult your Java environment documentation for details on this.
Attention: If a plaintext client tries to communicate with an SSL server or an SSL client
tries to communicate with a plaintext server, the plaintext side of the communication will
see the SSL communication as noise and report protocol errors.
Key and certificate handling
For SSL operation, the server always needs a key pair. If the server runs in peer
authentication mode (the server authenticates the clients), then each client needs its own
key pair. In general, if one end of the communication wants to authenticate its partner,
then the first end needs to install a certificate generated by the partner.
The key pair is located in a file which is called a key store and the JDK's SSL
provider needs the system properties
javax.net.ssl.keyStore
and
javax.net.ssl.keyStorePassword
to access the key store.
The certificates of trusted parties are installed in a file called a trust store. The JDK's
SSL provider needs the system properties
javax.net.ssl.trustStore
and
javax.net.ssl.trustStorePassword
to access the trust store.
Key pair generation
Key pairs are generated with
keytool -genkey
. The simplest way to generate a key
pair is to do the following:
keytool -genkey <alias> -keystore <keystore>
