Skip to Content
Technical Articles
Author's profile photo Bartosz Jarkowski

Your SAP on Azure – Part 16 – Easy TLS/SSL with SAP Data Hub and Let’s Encrypt

I always enjoy attending community events because that’s a good chance to learn something new. A few days ago I joined the first Azure Midlands Community meetup and when Microsoft MVP Marco De Sanctis presented how easy it is to manage TLS/SSL certificates in the Kubernetes cluster I thought I need to test with my SAP Data Hub installation and share it with you!

To access SAP Data Hub deployed on Azure Kubernetes Service you need to expose the System Management to the internet or local network using an Ingress controller. If you follow the official documentation or my blog about installing the SAP Data Hub there is a small script that lets you create a self-signed certificate and upload it to the vsystem-tls-certs secret. But that’s not the best approach as users can’t verify the website owner and you get this ugly welcome screen!

There is another approach. You can request and import a trusted certificate. This way your website is secure and you can see a small green lock on the address bar. But each certificate will eventually expire and you need to remember to replace it. Oh, and I almost forgot – you need to pay for the certificate!

But there is a third approach possible. Most probably you’re already familiar with Let’s Encrypt. They offer TLS/SSL certificates for free and today I will show you how to enable the automatic deployment to SAP Data Hub cluster.

(source: https://docs.cert-manager.io/)

My assumption is that you have already installed the SAP Data Hub and exposed the System Management to the internet using an Ingress service. If you’re not there yet, please refer to the installation guide or my post and continue with this guide when you can access the website.

INSTALL CERT MANAGER

We will use helm to install the cert-manager on AKS cluster. It’s a Kubernetes service that provisions certificates from Let’s Encrypt and automatically deploys them to a configured secret. The cert-manager is using custom resources that are not available on the Kubernetes by default, so we start with the creation of Custom Resource Definitions (CRDs) in a new namespace:

kubectl create namespace cert-manager
kubectl apply -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.7/deploy/manifests/00-crds.yaml

I label the cert-manager namespace to disable the resource validation

kubectl label namespace cert-manager certmanager.k8s.io/disable-validation=true

The cert-manager is contained in custom repository so we need to add it to helm and run the update:

helm repo add jetstack https://charts.jetstack.io
helm repo update

Finally we can install the service:

helm install \
  --name cert-manager \
  --namespace cert-manager \
  --version v0.7.2 \
  jetstack/cert-manager

To verify the installation you can display the pods running in the cert-manager namespace:

CONFIGURE CERTIFICATE ISSUER

The Issuer is one of the custom resources that we have already imported to our Kubernetes cluster and it specifies the certificate authority that will generate TLS certificates for us. Create the following manifest and type your e-mail address in the email field:

apiVersion: certmanager.k8s.io/v1alpha1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    # The ACME server URL
    server: https://acme-v02.api.letsencrypt.org/directory
    # Email address used for ACME registration
    email: <E-MAIL ADDRESS>
    # Name of a secret used to store the ACME account private key
    privateKeySecretRef:
      name: letsencrypt-prod
    # Enable the HTTP-01 challenge provider
    http01: {}

Create the issuer based on the manifest file:

kubectl create -f prod-issuer.yaml -n cert-manager

CONFIGURE THE INGRESS SERVICE

The last step is to modify the ingress script delivered by SAP to add an annotation that this service should be included in the certificate deployment process. Don’t forget to update your domain names as well.

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
 name: vsystem
 annotations:
   kubernetes.io/ingress.class: nginx
   certmanager.k8s.io/cluster-issuer: letsencrypt-prod
   nginx.ingress.kubernetes.io/secure-backends: "true"
   nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
   nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
   nginx.ingress.kubernetes.io/proxy-body-size: "500m"
   nginx.ingress.kubernetes.io/proxy-connect-timeout: "30"
   nginx.ingress.kubernetes.io/proxy-read-timeout: "1800"
   nginx.ingress.kubernetes.io/proxy-send-timeout: "1800"
   nginx.ingress.kubernetes.io/proxy-buffer-size: "16k"
spec:
 tls:
 - hosts:
   - domain.name
   secretName: vsystem-tls-certs
 rules:
 - host: domain.name
   http:
     paths:
     - path: /
       backend:
         serviceName: vsystem
         servicePort: 8797

Apply the new settings using:

kubectl apply -f vsystem-ingress.yaml -n <namespace>

Let’s have a closer look to what happened inside the new ingress:

kubectl describe ing vsystem -n datahub

In the events section you will see that the certificate was successfully created:

You can also have a look at the Certificate resource. As you can see bellow I initially had a problem with the letsencrypt-prod issuer and that’s mentioned in the event section. In my case, the problem was with an incorrect e-mail address set in the prod-issuer.yaml file.

kubectl describe certificate vsystem-tls-certs -ndatahub

TESTING

Let’s go back to the SAP Data Hub and refresh the screen. This time there was no information about Potential Security Risks, but instead, we have a login screen and a green lock in the address bar!

Assigned tags

      6 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Ian Henry
      Ian Henry

      Thanks for sharing Bartosz, I will try securing my DH cluster 🙂

      Author's profile photo Tran PhucAn
      Tran PhucAn

      Hi Bartosz,

      Thanks for your sharing.

      In my case, i've already set up FIORI for new SAP system. And i want to know " How to set up SSL of Let's Encrypt using for FIORI Application ? ".

      I had tried search on google with keyword "SSL for FIORI" but can not find anything.

      • With laptop, i can add host in windows/system32/driver/etc/hosts and using as well.
      • With mobile (IOS), when i try with APP FIORI, i get message no certificate => I searched on google, and i know " Must be SSL if you want to use for FIORI application "

      Could you please suggest for me some ways for this case or share some knowledge ?

      My server:

      • S/4 HANA 1809 Initial Shipment Stack
      • Linux SUSE 12 SP3
      • Actived FIORI
      • There is not any SSL on server.
      • hostname # with domain that i want to register SSL.

      Thanks in advance.

       

      Author's profile photo Bartosz Jarkowski
      Bartosz Jarkowski
      Blog Post Author

      Hello Tran,

      I found following document - quickly reviewed it and it looks OK :

      https://www.sap.com/documents/2017/03/ece286fd-ac7c-0010-82c7-eda71af511fa.html

      Author's profile photo Bartosz Jarkowski
      Bartosz Jarkowski
      Blog Post Author

      And if you'd like to you Let's Encrypt, please refer to this blog:

      https://blogs.sap.com/2018/12/13/use-a-lets-encrypt-certificate-for-sap-hana-or-sap-netweaver-as-abap/

      But I found it's to much hassle with Let's Encrypt and the ABAP.

      Author's profile photo Frank Schuler
      Frank Schuler

      Thank you, Bartosz.

      Excellent blog again. I believe the installation of the cert-manager has become simpler since:

      https://cert-manager.io/docs/installation/kubernetes/

      Very best regards

      Author's profile photo Roland Kramer
      Roland Kramer

      Hello Frank Schuler  and Bartosz Jarkowski

      can you please have a look to the Blog - https://blogs.sap.com/2020/05/23/secure-the-ingress-for-dh-2.7-or-di-3.0 and the open question on the Github - https://github.com/jetstack/cert-manager/issues/2959.

      maybe you know were my problem is related ...

      In the meantime, the notation for the ClusterIssuer and the Certificate changed

      Best Regards Roland