I will describe here how I did to set up HTTPS with a free SSL certificate issued by Let’s Encrypt. We will use Porunov Java ACME Client (PJAC): a Java CLI management agent designed for manual certificate management utilizing the Automatic Certificate Management Environment (ACME) protocol (example here: https://github.com/porunov/acme_client/wiki/Get-a-wildcard-certificate).
- Have your private keypairs and CSR ready
- Order request to Let’s Encrypt and prove your domain’s ownership
- Update SAP Gateway truststore
Use OpenSSL command lines or another GUI tool for keystores.
I am really bad at remembering openssl commands and options. Instead I feel more comfortable with tools like xca (https://hohnstaedt.de/xca) to generate key pairs, CSR and to display certificates.
Let’s start with generating 2 key pairs: one for Let’s Encrypt account and another one for the actual server (note I have used 4096 bits keys).
Next, we will generate a CSR for the server key pair. The important field is Subject Alternative Name in case of wildcard certificate.
The 2 key pairs and CSR must be exported so we can use them in PJAC command lines.
Let’s Encrypt is our Certification Authority.
java -jar ~/Downloads/acme_client.jar --command register -a ./xxx.io-letsencrypt-account.pem --with-agreement-update --email @.com --log-dir .
Then request order:
java -jar ~/Downloads/acme_client.jar --command order-certificate -a ./xxx.io-letsencrypt-account.pem -w ./pjac/workdir/ -c ./xxx.io.csr --challenge-type DNS01 --dns-digests-dir ./pjac/digests/ --log-dir .
Files are created in digests folder, we will use them to update our domain.
The previous commands have created two files in output folder pjac/digests (parameter –dns-digest-dir). We have now to update our domain’s CNAME using the generated strings so to prove we actually are in control of our domain (the so called DNS challenge).
Two TXT DNS records must be created, one for each of the digest file:
This can require some minutes to propagate. The next step of verification will depend on actual completion of this update.
java -jar ~/Downloads/acme_client.jar --command verify-domains -a ./xxx.io-letsencrypt-account.pem -w ./pjac/workdir/ -c ./xxx.io.csr --challenge-type DNS01
If everything is alright, our domain is now authorized and we should be able to generate and download certificate:
java -jar ~/Downloads/acme_client.jar --command generate-certificate -a ./xxx.io-letsencrypt-account.pem -w ./pjac/workdir/ -c ./xxx.io.csr --cert-dir ./pjac/certdir/ --log-dir .
We are done with the certificates, they are available in pjac/certdir:
cert.pem chain.pem fullchain.pem
If we import then in our xca keystore the full chain certificate, this is what we should see:
Note that Let’s Encrypt delivers 90-days-valid certificates only: this is on purpose as the philosophy is to improve security by renewing certificates more often, and in an automated way.
Change SSL server’s certificate of our ABAP AS
The following explanation may not be that useful in practical case: most of the time your SAP Gateway will be behind a web dispatcher, high availability load balancer or any kind of reverse proxy and your SSL certificate will be set up in this internet front facing server only.
Anyway, the interesting point is that the following shows that we don’t need to bother with sapgenpse any more and we can manage our keystore independently using openssl for instance.
Now that our signed certificate is loaded into our xca keystore, let’s export it together with its private key in PKCS12 format in order to use it in our ABAP AS. You have to set and remember the export password.
We can head to STRUST in ABAP AS to update our certificate. STRUST is not really the easiest and most understandable transaction, so here are my hints:
- left tree view shows all expected or actual PSEs
- right pane shows the selected PSE (the one you have selected in left tree)
- in left tree, “File” is not really a PSE but a tool to load external PSE
- Switch to “Change mode” and double-click on “File” in the left pane
- In the “Open” popup, select the .p12 file we have exported earlier from xca, then provide the password we set during export
- SAP will complain about missing certificate in the chain. They must be downloaded from https://letsencrypt.org/certificates/, you will need to download “Let’s Encrypt Authority X3 (IdenTrust cross-signed)” and “DST Root CA X3”. Import them one by one as requested by popup message.
- Once loaded, right pane shows the certificate signed by Let’s Encrypt
- Now in top left menu File > Save as, choose SSL server DFAULT
We are done, in left pane SSL server standard > System wide : light should be green, and a double-click on your system should show the new certificate.
Depending of your version of Netweaver, your newly uploaded certificate may be active right away or you may need to restart your server in ICM.
Try to connect to your server (Fiori launchpad) and check the green lock in the toolbar: if you display details of the certificate, you should find your expected certificate as signed by Let’s Encrypt:
Every 3 months you will need to renew your certificate: this means you repeat steps from “Request order from Let’s encrypt”.
With Let’s encrypt, this is now easy to get free certificates that you can use in your own custom environment (like your own S/4 in your home cloud). This is especially convenient whenever you want to expose some API and consume it from an external application, as you will not face the security warnings about your self-signed certificates any more.