Problem statement

SAP offers through its Cloud Appliance Library the possibility to demo or try out systems like SAP S/4HANA. That’s great and very convenient if you want a sandbox to play.

However, it’s delivered without trusted SSL certificate which can be a problem particularly if you want to use the APIs through tools that only allow a trusted CA as part of the certificate chain. If you wonder what I’m talking about this is the symptom when connecting to a webserver without trusted CA in the SSL certificate.

Image 1: Invalid SSL certificate of a CAL server in Chrome Browser

Solution approach

There are several ways to overcome it. The first 2 are described in a document specific for SAP CAL systems. You can find the document here. I recommend to consider them first.

However, there is a third approach to it: You can set a reverse proxy in between the client and the system with invalid certificate. You can then secure the proxy with a valid certificate. In that way you don’t need to touch the CAL system (or any other invalid certificate using web server) and can potentially use an already existing certificate to secure the connection.

In my case I already run a SAP BTP Kyma cluster that can secure any connection through API Rules so I used this.

Image 2: Solution architecture with reverse proxy on Kyma

If you want to apply this approach for yourself you can use this nginx configuration example below.

server {
    resolver 8.8.8.8;
    listen 8080;
    server_name myCalSystem.com;

    location / {
        proxy_pass https://$server_name:44301;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Adjust server_name and port as needed.

You can then build a docker image like so:

FROM nginx:stable

WORKDIR /etc/nginx/conf.d
COPY nginx.conf default.conf

EXPOSE 8080

where nginx.conf is the config file above.

Finally deploy it on SAP BTP Kyma (or anywhere else) like that:

apiVersion: v1
kind: Namespace
metadata:
  name: s4hanacal-proxy
  labels:
    istio-injection: enabled
---
kind: Deployment
apiVersion: apps/v1
metadata:
  name: s4hanacal-proxy-app
  namespace: s4hanacal-proxy
spec:
  replicas: 1
  selector:
    matchLabels:
      app: s4hanacal-proxy-app
  template:
    metadata:
      labels:
        app: s4hanacal-proxy-app
    spec:
      containers:
        - name: s4hanacal-proxy-container
          image: <add your docker image here>
          ports:
            - name: http-port
              containerPort: 8080
              protocol: TCP
          imagePullPolicy: Always
      restartPolicy: Always
---
kind: Service
apiVersion: v1
metadata:
  name: s4hanacal-proxy-service
  namespace: s4hanacal-proxy
  labels:
    app: s4hanacal-proxy-app
spec:
  ports:
    - name: http-port
      protocol: TCP
      port: 8080
      targetPort: http-port
  selector:
    app: s4hanacal-proxy-app
  type: ClusterIP
---
apiVersion: gateway.kyma-project.io/v1alpha1
kind: APIRule
metadata:
  name: s4hanacal-proxy-apirule
  namespace: s4hanacal-proxy
  labels:
    app.kubernetes.io/name: s4hanacal-proxy-apirule
spec:
  gateway: kyma-gateway.kyma-system.svc.cluster.local
  rules:
    - accessStrategies:
        - handler: allow
          config: {}
      methods:
        - PUT
        - PATCH
        - POST
        - GET
        - OPTIONS
      path: /.*
  service:
    host: s42021
    name: s4hanacal-proxy-service
    port: 8080

Replace with your own docker image name.

You can now access S/4HANA through that API Rule host.

Image 3: S/4HANA CAL accessed through SAP BTP Kyma host with trusted SSL.

Closing

A short blog this time. Hope it’s useful for some of you. Let me know in the comments.