Skip to Content
Technical Articles

Secure the Ingress for DH 2.7 or DI 3.0

Last Changed: 25th of May 2020

Blog: prepare the Installation Host for the SLC Bridge
Blog: Maintenance Planer and the SLC Bridge for Data Hub
Blog: SAP DataHub 2.7 Installation with SLC Bridge
Blog: Secure the Ingress for DH 2.7 or DI 3.0
Blog: Data Intelligence Hub – connecting the Dots …
new Blog: SAP Data Intelligence 3.0 – implement with slcb tool


Secure the Ingress for DH 2.7 or DI 3.0

In case (mostly possibly) you want to secure the Ingress access to the Data Hub/Data Intelligence Cluster with more than self-signed certificate, the usage of the cert-manager would be more than beneficial.

the cert-manager run’s in it’s own namespace and own pod and allows several additional possibilities. This chart is maintained at github.com/jetstack/cert-manager.

### install cert-manager v0.15.0 - jetstack
server:/ # kubectl create namespace cert-manager
# Kubernetes 1.15+
server:/ # kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v0.15.0/cert-manager.crds.yaml
server:/ # helm repo add jetstack https://charts.jetstack.io
server:/ # helm repo update
server:/ # helm install cert-manager jetstack/cert-manager --version v0.15.0 -n cert-manager [--dry-run]

server:/ # kubectl get pods --namespace cert-manager
server:/ # kubectl -n cert-manager get service ${service_name}
NAME                                       READY   STATUS    RESTARTS   AGE
cert-manager-77f4c9d4b-894dq               1/1     Running   0          4d2h
cert-manager-cainjector-7cd4857fc7-z4b6c   1/1     Running   0          4d2h
cert-manager-webhook-586c9597db-5w8sf      1/1     Running   0          4d2h
server:/ # 

the cert-manager kubectl plugin allows you additional commands together with kubectl.

prepare the files and apply them to the AKS cluster. Beside the Install Documentation there is also a Tutorial which contains additional details and a Troubleshooting Section. I have used the Automated Certificate Management Environment (ACME) with let’s encrypt.

you can use the Let’s Encrypt Staging Environment to test all the needed function beforehand, e.g. adding the staging environment intermediate certificate (“Fake LE Intermediate X1”) to your Web Browser.

If you get errors with the format of the yaml files like below, then you have to replace the existing coding with a clean one from the original source, even it looks correct. See an example here.

server:/ # kubectl apply -f Certificate.yaml -n cert-manager
error: error parsing Certificate.yaml: error converting YAML to JSON: yaml: line 11: did not find expected key

once the yaml files are applied, you can find all details starting from the certificate downwards.

server:/ # kubectl apply -f Certificate.yaml -n cert-manager
server:/ # kubectl get certificates -n cert-manager
NAME                     READY   SECRET                            AGE
letsencrypt-staging      False   vsystem-tls-letsencrypt-staging   9m24s
vsystem-tls-certs-prod   True    vsystem-tls-certs-prod            16h
server:/ # kubectl describe certificate letsencrypt-staging -n cert-manager
###
Status:
  Conditions:
    Last Transition Time:  2020-05-26T09:24:56Z
    Message:               Waiting for CertificateRequest "letsencrypt-staging-2680584605" to complete
    Reason:                InProgress
    Status:                False
    Type:                  Ready
Events:
  Type    Reason     Age   From          Message
  ----    ------     ----  ----          -------
  Normal  Requested  10m   cert-manager  Created new CertificateRequest resource "letsencrypt-staging-2680584605"
server:/ # kubectl describe CertificateRequest letsencrypt-staging-2680584605 -n cert-manager
###
Events:
  Type    Reason        Age   From          Message
  ----    ------        ----  ----          -------
  Normal  OrderCreated  12m   cert-manager  Created Order resource cert-manager/letsencrypt-staging-2680584605-3621476536
  Normal  OrderPending  12m   cert-manager  Waiting on certificate issuance from order cert-manager/letsencrypt-staging-2680584605-3621476536
server:/ # kubectl describe order letsencrypt-staging-2680584605-3621476536 -n cert-manager
###
Events:
  Type    Reason   Age   From          Message
  ----    ------   ----  ----          -------
  Normal  Created  14m   cert-manager  Created Challenge resource "letsencrypt-staging-2680584605-3621476536-2139230782" for domain "<aks-cluster>.<region>.westeurope.cloudapp.azure.com"
  Normal  Created  14m   cert-manager  Created Challenge resource "letsencrypt-staging-2680584605-3621476536-3545865779" for domain "<aks-slcb>.<region>.cloudapp.azure.com"
server:/ # kubectl get challenges -n cert-manager
NAME                                                   STATE                                  
letsencrypt-staging-2680584605-3621476536-2139230782   valid
letsencrypt-staging-2680584605-3621476536-3545865779   pending
server:/ # kubectl describe challenge letsencrypt-staging-2680584605-3621476536-2139230782 -n cert-manager
###
Events:
  Type    Reason          Age   From          Message
  ----    ------          ----  ----          -------
  Normal  Started         18m   cert-manager  Challenge scheduled for processing
  Normal  Presented       18m   cert-manager  Presented challenge using http-01 challenge mechanism
  Normal  DomainVerified  17m   cert-manager  Domain "<aks-cluster>.<region>.cloudapp.azure.com" verified with "http-01" validation
server:/ # kubectl get secret vsystem-tls-letsencrypt-staging -n cert-manager -o yaml
server:/ # kubectl describe secret vsystem-tls-certs-prod -n cert-manager
Name:         vsystem-tls-certs-prod
Namespace:    cert-manager
###
Data
====
ca.crt:   0 bytes
tls.crt:  3610 bytes
tls.key:  1675 bytes
server:/ # kubectl describe CertificateRequest letsencrypt-staging-2728998778 -n cert-manager
server:/ #

Tutorial: Securing NGINX-ingress

finally the AKS cluster should have a valid HTTPS URL to call.


Applying necessary Certificates for Backend Connections

Please note that only plain types of cer/crt Certificates are accepted.
Sometimes the Certificates are only available as binary files. These type of files are not accepted by the Certificate STore of the SAP Datahub.

Note 2631190 – Download location of SSL certificates required for Support Hub Connectivity configuration

openssl allows you to convert the files from binary format to plain format and vice versa.

openssl x509 -in DigiCertGlobalRootCA.crt -inform der -outform pem -out DigiCertGlobalRootCA.pem
openssl x509 -in DigiCertGlobalRootG2.crt -inform der -outform pem -out DigiCertGlobalRootG2.pem
openssl x509 -in DigiCertHighAssuranceEVRootCA.crt -inform der -outform pem -out DigiCertHighAssuranceEVRootCA.pem

X509 File Extensions

The first thing we have to understand is what each type of file extension is.   There is a lot of confusion about what DER, PEM, CRT, and CER are and many have incorrectly said that they are all interchangeable.  While in certain cases some can be interchanged the best practice is to identify how your certificate is encoded and then label it correctly.  Correctly labeled certificates will be much easier to manipulate.

Encodings (also used as extensions)

  • .DER = The DER extension is used for binary DER encoded certificates. These files may also bear the CER or the CRT extension.   Proper English usage would be “I have a DER encoded certificate” not “I have a DER certificate”.
  • .PEM = The PEM extension is used for different types of X.509v3 files which contain ASCII (Base64) armored data prefixed with a “—– BEGIN …” line.

Common Extensions

  • .CRT = The CRT extension is used for certificates. The certificates may be encoded as binary DER or as ASCII PEM. The CER and CRT extensions are nearly synonymous.  Most common among *nix systems
  • CER = alternate form of .crt (Microsoft Convention) You can use MS to convert .crt to .cer (.both DER encoded .cer, or base64[PEM] encoded .cer)  The .cer file extension is also recognized by IE as a command to run a MS cryptoAPI command (specifically rundll32.exe cryptext.dll,CryptExtOpenCER) which displays a dialogue for importing and/or viewing certificate contents.
  • .KEY = The KEY extension is used both for public and private PKCS#8 keys. The keys may be encoded as binary DER or as ASCII PEM.

The only time CRT and CER can safely be interchanged is when the encoding type can be identical.  (ie  PEM encoded CRT = PEM encoded CER)


This is work in progress … 

 


Roland Kramer, SAP Platform Architect for Intelligent Data & Analytics
@RolandKramer

 

“I have no special talent, I am only passionately curious.” 

Be the first to leave a comment
You must be Logged on to comment or reply to a post.