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 marcbecker 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:
High level steps described in this example:
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 serge.xs2tests-wdf.sap.corp, so I set the SAN to include both *. serge.xs2tests-wdf.sap.corp and serge.xs2tests-wdf.sap.corp. By using the wildcard in the SAN the certificate will apply for webide.serge.xs2tests-wdf.sap.corp, xsa-admin.serge.xs2tests-wdf.sap.corp, etc. While serge.xs2tests-wdf.sap.corp will apply for the basic route.
Example:
DNS=*.serge.xs2tests-wdf.sap.corp:serge.xs2tests-wdf.sap.corp, CN= serge.xs2tests-wdf.sap.corp, O=SAP, C=DE
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 export.serge.xs2tests-wdf.sap.corp.p12
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.
Command:
ld9993:/hana/shared/W95/sec # openssl pkcs12 -in export.serge.xs2tests-wdf.sap.corp.p12 -out export.serge.xs2tests-wdf.sap.corp.pem -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:
-----BEGIN PRIVATE KEY-----
Exported Private Key
-----END PRIVATE KEY-----
Example chain.pem:
-----BEGIN CERTIFICATE-----
Server certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Intermediate/Signing certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Root certificate
-----END 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).
Example:
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 serge.xs2tests-wdf.sap.corp -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.
This blog is a supplement to two other blogs related to SAP HANA XS Advanced (XSA) failover configuration:
- SAP HANA 2.0 XS Advanced: a host auto-failover installation/configuration example
- SAP HANA2 XS Advanced – a failover installation/configuration example with HANA System Replication
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:
- https://support.google.com/chrome/a/answer/7391219?hl=en
- https://www.thesslstore.com/blog/security-changes-in-chrome-58/
- https://www.entrustdatacard.com/knowledgebase/chrome-58-security-features
- 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 serge.xs2tests-wdf.sap.corp, then my certificate would be *. serge.xs2tests-wdf.sap.corp. Examples of the secured routes would be webide.serge.xs2tests-wdf.sap.corp, xsa-cockpit.serge.xs2tests-wdf.sap.corp, etc. However, the basic route serge.xs2tests-wdf.sap.corp cannot be secured because of the wildcard in the CN. With SAN based certificates the basic route serge.xs2tests-wdf.sap.corp can be created and secured. Note that the creation of the basic route is not common.
High level steps described in this example:
- in the SAP Web Dispatcher generate a wildcard certificate request, get it signed by your Certificate Authority of choice, import the certificate chain
- from the command line export the certificate in p12 format, convert it to pem format and prepare the certificate files for XSA import
- 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 serge.xs2tests-wdf.sap.corp, so I set the SAN to include both *. serge.xs2tests-wdf.sap.corp and serge.xs2tests-wdf.sap.corp. By using the wildcard in the SAN the certificate will apply for webide.serge.xs2tests-wdf.sap.corp, xsa-admin.serge.xs2tests-wdf.sap.corp, etc. While serge.xs2tests-wdf.sap.corp will apply for the basic route.
Example:
DNS=*.serge.xs2tests-wdf.sap.corp:serge.xs2tests-wdf.sap.corp, CN= serge.xs2tests-wdf.sap.corp, O=SAP, C=DE
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 export.serge.xs2tests-wdf.sap.corp.p12
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.
Command:
ld9993:/hana/shared/W95/sec # openssl pkcs12 -in export.serge.xs2tests-wdf.sap.corp.p12 -out export.serge.xs2tests-wdf.sap.corp.pem -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:
-----BEGIN PRIVATE KEY-----
Exported Private Key
-----END PRIVATE KEY-----
Example chain.pem:
-----BEGIN CERTIFICATE-----
Server certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Intermediate/Signing certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Root certificate
-----END 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).
Example:
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 serge.xs2tests-wdf.sap.corp -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.
- SAP Managed Tags:
