SSL with SAP HANA Studio

As continution to the previous blog Prepare SAP HANA for SSL, I am writing this blog to use SSL with SAP HANA Studio.

Even if do not want to use SSL with studio, this procedure can be used at leset to test SSL that has been configured on the SAP HANA server.

  1. Copy the root and server certificates (PEM) created during configuration of SSL to the client machine (Where Studio is installed).copd
  2. Check the java keystore path from studio properties:instdet


  3. Create Keystore and import required Root Certificate
    Open command prompt and naviagate to $java.home/bin.Execute command:

    keytool -genkey -alias mykeystore -keyalg RSA -keystore .keystore -keysize 2048 -dName “CN=Firstname Lastname, OU=HANA, O=SAP, C=DE”


  4. Import the Root Certificate to the .keystore container.
    Note: You cannot use certificates in P7b format.testpafg

You are now ready to connect to SAP HANA server via HANA studio using SSL.


I am attaching additinal steps/screenshots from the errors so that it will be easy for others to troubleshoot similar issues:




Once added you will see a small lock on the system indicating that the connection is going via SSL.



Errors can be check with log from studio as below:



You can open each error to get more details.


FAIL: process hdbdaemon HDB Daemon not running

Note: These series of blogs related to error is only to give an idea about troubleshooting aspects of SAP HANA and not a definitive guide for error resolution.

When starting HANA database, I ran into below error:

hdbdaemon error

I ran into this error right after I tried to configure SSL on the HANA machine.

Checked the log nameserverxx.trc under /usr/sap/<SID>/<SID<<InstanceNO>/<HOST./trace/ and found below error:


Clear that the issue is caused by wrong SSL settings.

Realized that one of the parameter settings for SSL has been missed (SAP Note 2561693).

Set the value of ssl to off in global.ini file and restated the HANA database to fix the issue.

SAP Note:

2561693 – HANA Database fail to start due to SSL error

2142432 – SAP HANA does not start after a failed attempt to rename the HANA SID

2665811 – The stop and restart function of HANA studio is disabled even HANA is running

2431472 – Daemon status on a HANA system shows “Running but status info unavailable”

2125839 – Process hdbdaemon HDB Daemon not running – Address already in use

2472793 – HANA process hdbdaemon HDB Daemon not running

2231571 – [448] recovery could not be completed, [110092] Recovery failed in nameserver startup during recovery of MDC tenant

Use of Virtual/Secondary host name with SAP HANA

There are scenarios where you do not connect to SAP HANA database instance directly via Host IP address or Physical hostname but via a Virtual IP or NAT address.

The main connection between NAT and the IP is established via DNS or a local entry in local host file.

But internally SAP HANA tries to make a connection to the Tenant DB using physical IP by default. Same has been depicted below with an example of SAP HANA Studio.

If you check the properties of a tenant database from studio you will see the following:

Even though you connect to DB using NAT IP ( it is internally redirected to original IP ( to make additional connections.

In this case when you try to make connection to a tenant database via webdispatcher or sql clients you will not be able to communicate to tenant DB.


You can also verify the same by querying M_HOST_INFORMATION.


This behaviour is controlled by parameter “public_hostname_resolution” under global.ini.


To change the behaviour you will have to change the parameter to “no” so that system is not forced anymore to use IP address of the Network interface. Instead you can map the hostname to required IP address as required.


Note: This change does not required a DB restart.

Now you can map the hostname with required IP address on client machine to connect to the database:

Changes can be observed again with studio again.




Stop Sybase ASE – Linux

If you want to shutdown backup server also, make sure too shut it down first, as you will not be able to login to isql if you shutdown main server first.

Login to isql to shudown the ASE database and issue command “shutdown”


Then you can shutdown the ASE database instance.


You can opt to kill the processes (For example: If you dont have password to login to isql). But this is not the most safer way. Please use this option only if you are not able to login to isql.


Dont use -9 option. This might not allow uncommited DB transactions to rool back in a proper way.