We have developed and deployed an application in SAP BTP (Cloud Foundry) for one of our clients, this application is developed in Java Spring Boot, SAP UI5 and SAP HANA. The requirement was to expose the application under customer domain and not with the SAP BTP provided default domain, so we used SAP’s Custom Domain server, it is one of the services provided by SAP in BTP landscape. Here I am gonging to highlight our learning and experience on SAP’s Custom Domain service.
What is custom domain
When you host/deploy an application in BTP it would be accessible with the default sub domain provided by the cloud vendor. But as an application owner we never want our application to be accessible via default sub domain provided by cloud vendor, we would want our application to be accessible under our own domain. Custom domain helps to exposure our cloud application under our own domain.
What is custom domain service in BTP
SAP provides many services in BTP, Custom Domain service is one of the services which helps customers to configure and publicly exposure their application under their own domain. By using this service, subaccount owners can make their SAP BTP applications accessible via a custom domain that is different from the default one (hana.ondemand.com) – for example, www.myapp.com.
Features
- Access to your domain: Configure your application with a name that is easily recognizable by your customers and users.
- Application identity protection: Upload a TLS/SSL certificate to help secure your application identity and the data transmitted between the browser and your application
Environment
Custom Domain service runs in both Cloud Foundry and Neo environments.
Use Cases
Any PaaS or SaaS customer in SAP BTP would require this service to expose their application/ subscribed service securely under their own domain.
Process to create a custom domain for your application
- Subscribe to the Custom Domain Manager by using the SAP BTP cockpit in the Instances and Subscriptions section in your subaccount.
- Create a new instance and configure it by logging into Custom Domain Manager.
Tools required for SAP Cloud Foundry
You need the Cloud Foundry CLI and the Custom Domain CLI plugin to use the Custom Domain service.
Secure your application
To make sure that your domain is trusted, and all your application data is protected, you have to get an appropriate TLS/SSL certificate from a Certificate Authority (CA). Determine the domains you want to be protected by this certificate. One certificate can be valid for a number of domains and subdomains, but you can also use a dedicated certificate for each domain
- Standard certificate – A standard certificate protects one domain, for example. www.myapp.com.
- Wildcard certificate – A wildcard certificate secures multiple applications of a domain, for example, *.myapp.com covers any application under the domain myapp.com, like a.myapp.com, but not the domain myapp.com itself.
In our case we have used CA signed wildcard certificate for an application deployed in SAP Cloud Foundry, I am going to touch upon the steps.
We have used Cloud Foundry command line interface (CLI) to mange the SSL certificate for our custom domain.
- Generate the Certificate Signing Request (CSR) for your domain by using CLI. While creating CSR, we would need to provide few important information and generate a private key.
cf custom-domain-create-key my-domain-key "CN=*.myapp.com, O=Organization, OU =Address, L=Address-2, ST=Address-3, C=Address-3" "myapp.com" "*.myapp.com"
- Download the CSR (.pem) from CLI and share with authority for signing.
cf custom-domain-get-csr my-domain-key csr.pem
- Once signed certificate is received from CA then we would need upload and activate it to BTP through CLI.
- Upload the new certificate.
cf custom-domain-upload-certificate-chain my-domain-key NewCertificate.pem
- Activate uploaded certificate.
cf custom-domain-activate my-domain-key "*.myapp.com" "myapp.com"
We would need to renew the certificate before it gets expired, while renewing please make sure you use a new private key while generating the CSR file and delete the old private key when new certificate is uploaded and activated.
Graphical overview