Setting up secure SSL connections between an SAP application server and a Db2 database has become relatively easy with IBM Db2 10.5 FP10 or higher. But still there are some non-obvious pitfalls that can cause some frustration when you set up SSL for the first time. In the following, I have compiled some of the most frequent pitfalls that you may run into and how you can avoid them.
The main steps for setting up SSL
Before we get into the possible pitfalls, let me summarize the main steps for setting up SSL for an SAP application server and a Db2 database instance:
- Generate the key database files for the Db2 server and generate a stash file for the password:
gsk8capicmd_64 -keydb -create -db "sapdb2<dbsid>_ssl_comm.kdb" -pw "mysecretpassword" -stash
- As user root, add an SSL port for your Db2 instance to the /etc/services
- For certificates signed by a certificate authority (CA-signed), send a certificate request, such as:
gsk8capicmd_64 -certreq -create -db "sapdb2<sid>_ssl_comm.kdb" -pw "<yoursecretpassword>" -size 2048 -label "db2<sid>_cert" -dn "CN=foo.bar.your.domain, O=MyOrg,OU=MyDep,L=MyLocation,ST=ON,C=CA", -file "db2<sid>_certRequestNew"
- Copy the certificate files to a client directory.
- Update the SSL parameters in the database manager configuration to point to the key database files and to a new SSL service name and port.
- Update the DB2COMM variable to DB2COMM=SSL.
- Restart the Db2 instance and SAP application server.
For all the details, there's a paper available on SAP Community that guides you through the whole procedure:
Setting up Secure SSL Connections Between SAP Application Server ABAP and an IBM Db2 Database
Now, this looks pretty straightforward. However, as said before, there are still some pitfalls that you may want to avoid.
Pitfall 1: A certificate request without a 2048-bit key
The first pitfall might occur when you generate a certificate request. Such a request might look like this:
gsk8capicmd_64 -certreq -create -db "sapdb2<sid>_ssl_comm.kdb" -pw "<yoursecretpassword>" -size 2048 -label "db2<sid>_cert" -dn "CN=foo.bar.your.domain, O=MyOrg,OU=MyDep,L=MyLocation,ST=ON,C=CA", -file "db2<sid>_certRequestNew"
Do you notice the
-size 2048 parameter? It's necessary because it ensures that the public key submitted with the certificate request has a 2048-bit key length. Many certificate authorities only issue certificates with a key length of 2048-bit for security reasons.
Pitfall 2: The certificate files get mixed up
The next pitfall might await you when you get the certificate files back from the certificate authority: There are three files, and it's easy to mix them up. Make sure that you get information which file contains the root certificate, which file contains the root infrastructure certificate, and which file is the signed certificate for the server.
Pitfall 3: The root certificate is not owned by <sid>adm
Make sure that the root certificate for the client is owned by <sid>adm and has the permission 644:
chown <sid>adm.sapsys /usr/sap/<SAPSID>/SYS/global/SSL_client/<FILE WITH ROOT CERTIFICATE>
This is a tricky pitfall. If the root certificate is not owned by <sid>adm or if the permissions are not as they should be, the resulting error messages might be hard to interpret.
Pitfall 3: The registry variable DB2COMM is switched to SSL and TCP/IP
Switch the registry variable DB2COMM to SSL only:
db2set DB2COMM=SSL
Note: Only this setting will enable the server to receive SSL connections only and to reject TCP/IP connections. Don't add TCIP to the settings, as this will enable both the TCP/IP and the SSL protocol. And this would defeat the purpose, wouldn't it?
Pitfall 4: The certificate has expired
As a default, a self-signed certificate expires after one year. With the parameter -expire, you can set the expiration to a different date. You can display the expiration date using the following command:
gsk8capicmd_64 -cert -details -db "sapdb2<dbsid>_ssl_comm.kdb" -pw "sslpassw0rd" -label "sap_db2<dbsid>_<virtual_hostname>_ssl_comm_<consecutive_number>"
Take a careful note of its expiration date: After the certificate has expired, a connect to the database is no longer possible. If you haven't updated the certificate in time, the following symptoms indicate that the certificate has expired:
- In trans.log or in the work process traces, you can find error SQL30081N with reason code 420 - The partner closed the socket before the protocol completed.
- In db2diag.log, you can find error DIA3604E - The SSL function "gsk_secure_soc_init" failed with the return code "14" in "sqlccSSLSocketSetup".
Finally, let me add a few tips and tricks:
How to update an expiring certificate
The following technote from IBM describes how to recreate a certificate signing request for updating an expiring certificate using IBM's GSKit:
https://www.ibm.com/support/pages/how-update-expiring-certificate-gskit
How to delete certificates from a keystore
You've made a mistake and would like to delete the certificates from the keystore again? Here's how:
gsk8capicmd_64 -cert -delete -db "sapdb2<sid>_ssl_comm.kdb" -pw "<yoursecretpassword>" -label RootCert
gsk8capicmd_64 -cert -delete -db "sapdb2<sid>_ssl_comm.kdb" -pw "<yoursecretpassword>" -label RootCACert
gsk8capicmd_64 -cert -delete -db "sapdb2<sid>_ssl_comm.kdb" -pw "<yoursecretpassword>" -label db2<sid>_cert
I hope the tips help you with setting up your SSL connections quickly. Any feedback on this is welcome!
