Let’s Encrypt [Part II]

Let’s Encrypt [Part II]

Using “Let’s Encrypt” certificates with SAP/HANA web dispatcher and XSA on an Azure deployment for SSL communication.

Note: this is the second part of the blog. Missed the first part? Read it here.

____________________________________________________

IF WE BREAKDOWN THE SCRIPT:

The first part of the script is setting up the environment variables so that every tool is run from the correct place. If you want to reuse the script these can be adapted to your local setup.

The next part will request the new certificates from Letsencrypt using the acme tool. Since in our case the validation is against the azure DNS, the necessary variables should be provided so the tool can identify itself with Azure DNS and apply the necessary setup for validation by Letsencrypt.

The first part of the script will generate the certificate to be used by SAP/HANA web dispatcher. The final result is a SAPSSLS.pse that contains the certificate info for HTTPS validation by the web browser.

First I copy the acme certificate-generated information to the central $SECUDIR/acme directory. Then I delete the existing $SECUDIR/SAPSSLS.pse.

Next, a pkcs12 file is prepared from the acme generated files that can later be used as a valid format by the SAPGENPSE tool. Openssl is used as a tool for generating the p12 file. If the OpenSSL tool is not yet available on the system, install it using the installer software (dependent on the Linux distribution).

Finally using the SAPGENPSE tool delivered during the sap installation, the HANA.p12 file generated in the previous step will be signed with the root (isgrootx1.cer) and intermediate (x3.cer) certificate downloaded from the Let’s Encrypt site. The result is a new SAPSSLS.pse file that can be used by the web dispatcher for trust validation.

The next part will restart the web dispatcher in order to activate the new certificate.

Now that the certificate is applied to the web dispatcher we can focus on the next part that will prepare and upload the certificate for use and SSL communication by the XSA environment.  Again the acme generated files concerning the XSA environment are copied to the $SECUDIR/acme folder.

This time the domain certificate together with the root and intermediate certificates are concatenated to a new file and afterward converted to a topk8 format using again the OpenSSLhana tool.

Using the xs tool, the domain.pk8 file can now be applied to the XSA environment. The last step will display the result of applying the certificate in the XSA environment.

Calling XSA application from the web browser should give a trusted lock sign as a result of a validated certificate.

The above script is now scheduled in cron by SAP system administration user to run on the first of every month at 1.00 in the morning. This way the certificate is guaranteed to be always valid.

$crontab -e

In a next article, I will explain how a similar setup was done for the BW4HANA application server.

Blog by Pascal De Poorter