Skip to Content
Technical Articles
Author's profile photo Serge Muts

SAP HANA2 XS Advanced Failover – Certificates using Subject Alternative Names

To provide secure communication this blog will show the steps to install a signed certificate chain. There are multiple ways to do this. But first, a special thanks to Marc Becker for providing a ton of insights and making this blog possible!

This blog is a supplement to two other blogs related to SAP HANA XS Advanced (XSA) failover configuration:

The referenced blogs use wildcard certificates based on the Common Name (CN) attribute. However, this blog will show a newer option by using SubjectAltNames (SAN) instead. SubjectAltNames have some benefits:

  • As of Google Chrome 58, it will no longer support the Common Name field on your SSL/TLS certificates. For background information see these external links:
  • XSA provides the capability to create routes (xs create-route <SPACE> <DOMAIN>). When using certificates based solely on the wildcard CN, you can only secure routes that resolve the wildcard. For example, if my XSA domain is, then my certificate would be *. Examples of the secured routes would be,, etc. However, the basic route cannot be secured because of the wildcard in the CN. With SAN based certificates the basic route can be created and secured. Note that the creation of the basic route is not common.

High level steps described in this example:

  1. in the SAP Web Dispatcher generate a wildcard certificate request, get it signed by your Certificate Authority of choice, import the certificate chain
  2. from the command line export the certificate in p12 format, convert it to pem format and prepare the certificate files for XSA import
  3. in the XSA environment, import the certificate files and restart XSA


Step 1:

Note: In this example we’ll use the SAP Web Dispatcher Administration URL to generate the CSR. If you prefer to use openssl instead, there is an example in the help link.

Login to the SAP Web Dispatcher Administration URL and go to PSE Management. Next select SAPSSLS.pse and “Recreate PSE”. The syntax to (re)create a PSE with SAN is explained in SAP Note 2502649


In my example, my XSA domain name was set to, so I set the SAN to include both *. and By using the wildcard in the SAN the certificate will apply for,, etc. While will apply for the basic route.



Click create and the result is:

The next step is to create the CA request and have it signed by your CA. Make sure to have the full chain available for import including the root CA and intermediate signing certificates.

The result:

Step 2:

From the command line export the certificate in p12 format, convert it to pem format and prepare the certificate files for XSA import

Login to the Failover Web Dispatcher server as the <sid>adm user (or whichever user is the Linux owner of the Web Dispatcher directories/files). Change to the $SECUDIR directory, in my instance /hana/shared/W95/sec.

Export the certificate chain we just imported in .p12 format. Make sure to set a compliant password and have it available for the import step we’ll execute later. Command:

ld9993:/hana/shared/W95/sec # /hana/shared/W95/sapgenpse export_p12 -p /hana/shared/W95/sec/SAPSSLS.pse

The next step is to convert the exported .p12 file to .pem format. There are several websites that can do this for you, however using openssl installed locally is a more secure option.


ld9993:/hana/shared/W95/sec # openssl pkcs12 -in -out -nodes

Please be aware that using the -nodes option exports the private key unencrypted. Hence cleanup of any files containing the unencrypted private key should be performed after completing the setup.

The next step is to take parts of the .pem file and create certificate files importable by XSA.

Use your favorite editor to create 2 new files, one will contain the private key and the other the certificate chain. In earlier version of XSA you had to make sure the lines for “bad attributes”, “subject”, and “issuer” are not part of the new files. As of XSA version 1.0.82 this is not necessary any longer.

In the private key file copy the “PRIVATE KEY” section, including begin and end line from the .pem file.

In the chain file copy the certificates, including begin and end line from the .pem file.

Example pkey.pem:


Exported Private Key


Example chain.pem:


Server certificate



Intermediate/Signing certificate



Root certificate


Once the files are created, secure copy (e.g. scp) both files to the Primary (or Master) XSA host as the <sid>adm user of the XSA Primary (Master) HANA instance. As the target directory, you can select $SECUDIR, which defaults to /usr/sap/<SID>/HDB<##>/<hostname>/sec (example /usr/sap/SR1/HDB19/PRIMARY/sec).


Step 3:

Next, we can import the certificates, note that a restart of XSA will be required. Make sure you are logged in as the <sid>adm user, issue command “xs-admin-login” (or “xs login”) and enter the XSA_ADMIN password.

The command syntax to set the certificate in XSA is:

xs set-certificate <XSA domain> -k <private keyfile> -c <chain file>

In my example:

xs set-certificate -k /usr/sap/SR1/HDB19/<hostname>/sec/pkey.pem -c /usr/sap/SR1/HDB19/<hostname>/sec/chain.pem

As mentioned before, next XSA needs to be restarted. A quick way to do this is to reuse the existing putty session since we are already logged into XSA. Simply type “XSA restart”:

Once XSA has restarted, open a new browser and retest the api url. Now the browser security status should show the lock to signal that the connection is secure:

When you inspect the certificate details you will see the SAN’s:

This concludes the steps to use SAP HANA2 XS Advanced Failover Certificates using SubjectAltNames.


Assigned Tags

      Be the first to leave a comment
      You must be Logged on to comment or reply to a post.