Technical Articles
Secure the Ingress for DH 2.7 or DI 3.0
Last Changed: 5th of November 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.
- ingress.yaml – ingress-prod.yaml
add the line to the section “annotations”cert-manager.io/cluster-issuer: letsencrypt-prod
- HTTP01-issuer.yaml – HTTP01-issuer-prod.yaml
- Certificate.yaml – Certificate-prod.yaml
you can use the Let’s Encrypt Staging Environment to test all the needed functions beforehand, e.g. adding the staging environment intermediate certificate (“Fake LE Intermediate X1”) to your Web Browser.
server:/ # kubectl apply -f HTTP01-issuer.yaml -n $NAMESPACE
server:/ # kubectl apply -f Certificate.yaml -n $NAMESPACE
server:/ # kubectl get Certificate -n $NAMESPACE
NAME READY SECRET AGE
letsencrypt-staging False vsystem-tls-letsencrypt-staging 9m24s
vsystem-tls-certs-prod True vsystem-tls-certs-prod 16h
server:/ #
Example with the Certificate “letsencrypt-staging”:
=> describe Certificate letsencrypt-staging
=> describe CertificateRequest letsencrypt-staging-<9-digits>
=> describe Order letsencrypt-staging-<9-digits>-<9-digits>
=> describe Challenge letsencrypt-staging-<9-digits>-<9-digits>-<9-digits>
=> describe Secret vsystem-tls-letsencrypt-staging
server:/ # kubectl describe certificate letsencrypt-staging -n $NAMESPACE
###
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 $NAMESPACE
###
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 $NAMESPACE
###
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 $NAMESPACE
NAME STATE
letsencrypt-staging-2680584605-3621476536-2139230782 valid
letsencrypt-staging-2680584605-3621476536-3545865779 pending
server:/ # kubectl describe challenge letsencrypt-staging-2680584605-3621476536-2139230782 -n $NAMESPACE
###
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 $NAMESPACE -o yaml
server:/ # kubectl describe secret vsystem-tls-certs-staging -n $NAMESPACE
Name: vsystem-tls-certs-staging
Namespace: $NAMESPACE
###
Data
====
ca.crt: 0 bytes
tls.crt: 3610 bytes
tls.key: 1675 bytes
server:/ #
Tutorial: Securing NGINX-ingress
finally the AKS cluster should have a valid HTTPS URL to call.
It looks like the way @Bartosz Jarkowski exposed the SAP Data Hub Launchpad is more efficient then the sap online help – Your SAP on Azure – Part 20 – Expose SAP Data Hub Launchpad
and the Your SAP on Azure – Part 16 – Easy TLS/SSL with SAP Data Hub and Let’s Encrypt works as well! actually with the current SAP Data Hub Installation only a few steps are necessary.
Applying necessary Certificates for Backend Connections
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. CER is an X. 509 certificate in binary form, DER encoded. CRT is a binary X. 509 certificate, encapsulated in text (base-64) encoding
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)
DigiCert Trusted Root Authority Certificates
openssl allows you to convert the files from binary format to plain format and vice versa.
SAP Data Intelligence accepts files with extension .pem or .crt
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
SAP Cloud Connector accepts files with extension .der or .cer
openssl x509 -inform DER -in DigiCertGlobalRootG2.crt -out DigiCertGlobalRootG2.cer
openssl x509 -inform DER -in DigiCertHighAssuranceEVRootCA.crt -out DigiCertHighAssuranceEVRootCA.cer
openssl x509 -inform DER -in SAPSSO_CA_G2.crt -out SAPSSO_CA_G2.cer
openssl x509 -inform DER -in SAPGlobalRootCA.crt -out SAPGlobalRootCA.cer
openssl x509 -inform DER -in SAPNetCA_G2.crt -out SAPNetCA_G2.cer
openssl x509 -inform DER -in SAPPassportG2.crt -out SAPPassportG2.cer
openssl x509 -inform PEM -in certificate.cer -out certificate.crt
SAP Cloud Connector Administration – Trust Store
Roland Kramer, SAP Platform Architect for Intelligent Data & Analytics
@RolandKramer
“I have no special talent, I am only passionately curious.”
Hi,
I am using Data Intelligence Cloud to connect to an on-prem system via Cloud Connector.
I see this error in the Cloud Connector logs..
sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Looks like the certificate of the SAP Data Intelligence ingress is not trusted by SAP Cloud Connector.
Where do I get the certificate of the SAP Data Intelligence ingress endpoint and so that I can upload it into the trust store of the SAP Cloud Connector? I see a couple of certificates under the Connection management->Certificate tab...but don't see an option to download them. Would appreciate any help in this matter.
Thanks
-ravi