Skip to Content

Hi everyone,

My name is Daniel Gray and I’m a Product Support Engineer. I work in SAP’s Vancouver office and I support the growing database technology known as HANA.

The goal of this blog is to provide an overview of various SSL configurations in HANA. There are already a number of guides that detail how to configure SSL on HANA; I hope these posts will help you understand why each step is necessary. This is a series I will be adding to in the future; I’m currently planning on covering single and multi-node HANA systems with and without certificate authorities, and internal communication in multi-node systems.

Prerequisites

As these posts are related to SSL and HANA, I won’t give an in-depth explanation of the mechanics behind SSL. If you are new to SSL the following resource helped greatly when I started learning SSL:

http://security.stackexchange.com/questions/56389/ssl-certificate-framework-101-how-does-the-browser-actually-verify-the-validity

Configurations

SSL protocols provide methods for establishing encrypted connections and verifying the identity of an entity (client, server, etc). Verifying the identity of a communication partner, however, isn’t mandatory. Many clients will allow you to establish connections with untrusted parties. For the following posts I will assume that our clients will reject untrusted servers.

Configuring clients to reject untrusted connections depends on the client itself. For HANA Studio, this option is found in Systems view -> right click the system connection <SID> (<DBUSER>) -> Properties -> Database User Logon -> Additional Properties tab -> Validate the SSL certificate checkbox.

/wp-content/uploads/2015/01/validate_cert_631674.png

Additionally, in the following examples I’ll assume that clients already trust certificates (i.e. the trust store contains the root certificate) signed by common CAs such as Verisign and DigiCert.

Should you encounter a term you’re not familiar with, please refer to the glossary at the bottom of this page.

  • SSL and single-node HANA systems
  • SSL and distributed (multi-node) HANA systems <under construction>
  • SSL and internal communication in distributed systems <under construction>

Glossary

  • Certificate Authority (CA): An entity, such as DigiCert, that verifies the identity of another entity, such as Facebook.
  • Public key: The key used to encrypt messages/decrypt signatures in asymmetric cryptography.
  • Public key certificate: A digital certificate that contains, and identifies the owner of, a public key; this is distributed publicly.
  • Private key: The key used to decrypt messages and sign objects in asymmetric cryptography; this is kept private.
  • Root certificate: A public key certificate that identifies the root CA. Root certificates from common CAs are generally distributed with clients (e.g. web browsers).
  • Certificate Signing Request (CSR): Contains the information required to generate a signed certificate.
  • Common Name (CN): Contained in public key certificates and identifies the host the certificate belongs to. The CN of a certificate must match the FQDN the client is connecting to.
  • Fully Qualified Domain Name (FQDN): A name that uniquely identifies a host on the internet.
  • Key store: A file that contains the information necessary for an entity to authenticate itself to others. Contains the server’s private key, signed server certificate, and intermediate certificates if necessary.
  • Trust store: A file that contains the information of trusted entities. Generally contains root certificates of CAs.
To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Guillaume Bruyneel

    Hello Daniel,

    I am currently searching information on How to enable SSL with HANA SPS09 in Multitenant.

    Your blog is very interesting, so i would like to get in contact with you, if you like ?

    Best regards

    Guillaume Bruyneel

    (0) 
    1. Jennifer Gray Post author

      Hi Guillaume,

      Configuring SSL for a multitenant database is the same process as a single-container database; place necessary crypto binary in LIB_SECURITY_DIR and create the necessary key and trust stores in ~/.ssl .

      If you’d like different setting for different tenants you can specify this with the various settings in global.ini -> [communication]. This includes System level, (Tenant) Database level, and host-level configuration.

      Hope this helps,

      Daniel Gray

      (0) 
      1. Gregory Misiorek

        Hi Daniel,

        i have already asked the first question elsewhere on SCN, but got no response so far:

        1. if i’m NOT working on SAP internal system, where can i get the SAPNetCA_G2.cer file?
        2. is it possible that i don’t need that file after all for SSL to work?

        thank you,


        greg

        (0) 
        1. Jennifer Gray Post author

          Hi Gregory,

          1)

          Marcin Kowalczyk is using SAP as a Certificate Authority (CA). After obtaining his signed certificate he obtains the root certificate (SAPNetCA_G2.cer) which is required to later import the signed certificate into his key store(s) (SAPSSLS.pse & sapsrv.pse).

          That said, since you don’t wish to use SAP as a CA you will have to have your server’s cert request…

          A) signed by a well-known CA. You will have to obtain the root certificate and any intermediate certificates in order to add your signed server certificate to the key store with sapgenpse

          OR

          B) signed by your own root certificate and imported into the servers key store using sapgenpse. Then you will need to distribute that root certificate to clients’ trust stores in order for connections to be trusted.

          2)

          At the very least you will need a signed certificate of some kind to establish an encrypted connection (whether it’s self-signed, signed by a CA, etc. doesn’t matter). If you choose not to have your server cert signed by a CA, you will have to distribute the certificate of whatever key did sign your server cert, or be vulnerable to man-in-the-middle attacks.

          Best regards,

          Daniel

          (0) 

Leave a Reply