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

    javahome

  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”

    keystore

  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.

Test:

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

studi

studi2

stu4

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

stud7

Troubleshooting:

Errors can be check with log from studio as below:

errlog

errlog2

You can open each error to get more details.

 

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 (10.253.80.9) it is internally redirected to original IP (10.249.28.20) 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.

studio1

You can also verify the same by querying M_HOST_INFORMATION.

studio2

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

stud3

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.

settono

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.

afterc