Some applications may require a higher security level for the communication between a client and a DBACCESS server. Therefore the DBACCESS server offers the option to use socalled "Secure Connections" by using SSL.
There are the following options regarding SSL usage (see. initialization file):
- The server could be cofigured without SSL usage, that means it uses unsecure connections only
(hence called a NoSSL server). - The server could be configured using SSL only, that means it uses secure connections only
(hence called a SSL server). - The server could be configured to accept both secure and unsecure connections (it will always choose a secure connection if the client doesn't request explicitly a secure or unsecure connection)
(hence called SSL/NoSSL server).
The DBACCESS server needs a server certificate (see initialization file) for negotiations about encrytion algorithms with a client when a secure connection is requested (both partners must be able to use a common encryption algorithm).
You can order a certificate from official certificate authorities (by providing a certificate and a Certificate Signing Request (CSR)); those official certificates will be kept on the official authority side and could be accessed by an appropriate URL by web access or they could be stored in files on the server side.
Or you can generate a self signed certificate by using the BS2000 procedure make.cert which is contained in the library $TSOS.SYSSPR.TCP-IP-AP.0nn.
Usage of this procedure is described in manual "interNet Services User Guide".
Please note that there are two parts of a certificate: The certificate file itself and a file with the private key for the encryption (should not be public available). Both parts are required for configuration of an SSL or NoSSL/SSL server (see initialization file).
When connecting to a DBACCESS server, a client could request
- an unsecure connection
- a secure connection
- a secure connection if the server offers secure connections or an unsecure connection otherwise (prefer secure)
See readme-file of the corresponding client (JDBC, ADO.Net, PHP/PDO).
Then the following matrix shows the type of the connection between client and server:
Server Type Client Request | NoSSL | SSL | SSL/NoSSL |
|---|---|---|---|
| unsecure | unsecure | error | unsecure |
| secure | error | secure | secure |
| prefer secure | unsecure | secure | secure |
Encryption and Decryption could be very expensive in terms of CPU both on client and server; especially creating a secure connection is much more expensive (in terms of CPU and network traffic) than creating an unsecure connection.
Hence we recommend to use connection pooling for secure connections, if connection pooling is available for the client interface. In SESAM/SQL connection pooling is only available for JDBC clients (s. readme file of the JDBC client).