Edited on: January 26, 2022
When using custom domains in SAP Business Technology Platform, you need to protect each domain using certificates. A single certificate can be used to protect a list of domains using Subject Alternative Names. This will simplify your certificate lifecycle.
This blog shows how can you leverage this with SAP Custom Domain.
Everything that runs on SAP Business Technology Platform has a URL so that people or machines can access them. By default, those URL’s are long, because SAP needs to make sure they are completely unique:
Your regular application URL
Sometimes, this domain is good because it’s a development environment or there are 10 end-users. Sometimes, it’s better to have your own domain for the application:
Your own domain, looks so professional…
Maybe customers or providers need to access this portal. Maybe it’s an application available to all employees, or you don’t want to change configurations in other systems every time the URL changes. Custom domains are useful for many reasons.
To make your custom domain trusted, you need to obtain an TLS/SSL certificate.
SSL certificates are what enable websites to use HTTPS. This means that the information exchanged between the application and the user is secure. The certificate also tells the user who is the owner. All this happens every time you open a website, it’s all in the little pad lock 🔒 next to the URL on the top of your browser:
Certificates hold some parameters. They tell the browser who is the owner, what domains it protects, when does it expire… This way, the users know that they are interacting with the right person/company, and that the communication between them and the server is secure.
For everyone to trust your certificate, they have to be issued by a certificate authority. These are trusted companies that provide a certificate chain starting from the highest institutions down to your domain.
The parameter of the certificate that identifies the domain/s protected is the Subject Alternative Name or SAN. A certificate can have one or more Subject Alternative Names listing all the domains that it protects.
You can use it to protect a single domain (
sap.com’s certificate, as an example, has multiple SAN’s to protect a list of domains:
This single certificate protects all the domains listed.
SAP supports adding Subject Alternative Names when you want to generate a certificate for your custom domains, allowing you to group custom domains in a single certificate.
This is useful when you know the domains to be protected before issuing the certificate.
Using the new UI available, you can configure your custom domains without having to deal with command line tools:
Refer to the official Custom Domain Manager guide in SAP Help Portal for details on all the steps involved. Here I will cover only how to include multiple Subject Alternative Names for your certificate without using wildcards.
As an overview, the process involves:
When you are adding your custom domains, add the domains you wish to protect: app1.example.com, app2.example.com,… under the Custom Domains section:
When you reach the step Manage Server Certificates, create a server certificate to get a Certificate Signing Request, or CSR. This will let the certificate authority know which domains need to be protected.
You will be shown two options:
Choose the first option. This will allow you to set Subject Alternative Names based on the custom domains you previously created:
For each custom domain, two options will be presented: one with the domain and another with a wildcard. Choose the domain without the wildcard if you want to generate a certificate with a list of single-domain Subject Alternative Names.
Finish by setting the Subject information for the certificate. Don’t worry about the domain appearing in the Common Name field. This field is not taken into account by browsers and has no effect.
The CSR will be generated. Once it is ready, you can go to your certificate authority of choice and request your certificate there. Please refer to the official documentation for the remaining steps and configurations.
When setting routes for your subscription services and applications, you will be asked to include a host that will result in a URL like:
This will only work if you chose the wildcard options when creating the server certificate. Leave it blank to use the domain:
Refer to the official documentation for details on all steps involved. Here I will cover only how to include Subject Alternative Names for your certificate.
In order to create a certificate, you first need to create a Certificate Signing Request, or CSR. This will let the certificate authority know which domains need to be protected.
The command to create a CSR with Subject Alternative Names has the following structure:
At the end, it will look like:
After obtaining the Certificate Signing Request, you can go to your certificate authority of choice and request your certificate there. Please refer to the official documentation for the remaining steps and configurations.
Useful links:
Summary
When using custom domains in SAP Business Technology Platform, you need to protect each domain using certificates. A single certificate can be used to protect a list of domains using Subject Alternative Names. This will simplify your certificate lifecycle.
This blog shows how can you leverage this with SAP Custom Domain.
A certificate can protect multiple domains using _Subject Alternative Names_
Both Cloud Foundry and Neo support multi-domain certificates. This blog will focus on the Cloud Foundry environment, but you can find the equivalent steps for Neo in the corresponding SAP Help document.
URL’s in SAP Business Technology Platform ⤒
Everything that runs on SAP Business Technology Platform has a URL so that people or machines can access them. By default, those URL’s are long, because SAP needs to make sure they are completely unique:
a-funny-portal.eb55a62043.cfapps.eu10.hana.ondemand.com
Your regular application URL
Sometimes, this domain is good because it’s a development environment or there are 10 end-users. Sometimes, it’s better to have your own domain for the application:
portal.example.com
Your own domain, looks so professional…
Maybe customers or providers need to access this portal. Maybe it’s an application available to all employees, or you don’t want to change configurations in other systems every time the URL changes. Custom domains are useful for many reasons.
To make your custom domain trusted, you need to obtain an TLS/SSL certificate.
What are SSL certificates ⤒
SSL certificates are what enable websites to use HTTPS. This means that the information exchanged between the application and the user is secure. The certificate also tells the user who is the owner. All this happens every time you open a website, it’s all in the little pad lock 🔒 next to the URL on the top of your browser:
The little green (sometimes grey) lock means the communication is secure
Certificates hold some parameters. They tell the browser who is the owner, what domains it protects, when does it expire… This way, the users know that they are interacting with the right person/company, and that the communication between them and the server is secure.
For everyone to trust your certificate, they have to be issued by a certificate authority. These are trusted companies that provide a certificate chain starting from the highest institutions down to your domain.
How many domains can a certificate protect? ⤒
The parameter of the certificate that identifies the domain/s protected is the Subject Alternative Name or SAN. A certificate can have one or more Subject Alternative Names listing all the domains that it protects.
You can use it to protect a single domain (
SAN=app1.example.com) or every subdomain (SAN=*.example.com).sap.com’s certificate, as an example, has multiple SAN’s to protect a list of domains:
SAN=www.sap.com SAN=translation.sap.com SAN=support.sap.com SAN=search.sap.com SAN=sap.com SAN=partneredge.sap.com SAN=go.sap.com SAN=developers.sap.com SAN=cloudplatform.sap.comThis single certificate protects all the domains listed.
Subject Alternative Names with SAP Custom Domain Service ⤒
SAP supports adding Subject Alternative Names when you want to generate a certificate for your custom domains, allowing you to group custom domains in a single certificate.
This is useful when you know the domains to be protected before issuing the certificate.
Using Custom Domain Manager UI ⤒
Using the new UI available, you can configure your custom domains without having to deal with command line tools:
Main page of the Custom Domain Manager
Refer to the official Custom Domain Manager guide in SAP Help Portal for details on all the steps involved. Here I will cover only how to include multiple Subject Alternative Names for your certificate without using wildcards.
As an overview, the process involves:
- Adding the domains you will use
- Creating a TLS configuration
- Creating a server certificate
When you are adding your custom domains, add the domains you wish to protect: app1.example.com, app2.example.com,… under the Custom Domains section:
Add the full domains under Custom Domains to be able to add them as SANs later
When you reach the step Manage Server Certificates, create a server certificate to get a Certificate Signing Request, or CSR. This will let the certificate authority know which domains need to be protected.
You will be shown two options:
Options when creating server certificates
- for your (wildcard) Custom Domains
- for your Custom Domain SaaS Routes
Choose the first option. This will allow you to set Subject Alternative Names based on the custom domains you previously created:
Selecting the Subject Alternative Names to be included in the certificate
For each custom domain, two options will be presented: one with the domain and another with a wildcard. Choose the domain without the wildcard if you want to generate a certificate with a list of single-domain Subject Alternative Names.
Finish by setting the Subject information for the certificate. Don’t worry about the domain appearing in the Common Name field. This field is not taken into account by browsers and has no effect.
The CSR will be generated. Once it is ready, you can go to your certificate authority of choice and request your certificate there. Please refer to the official documentation for the remaining steps and configurations.
When setting routes for your subscription services and applications, you will be asked to include a host that will result in a URL like:
host.app1.example.comThis will only work if you chose the wildcard options when creating the server certificate. Leave it blank to use the domain:
app1.example.comUsing SAP Custom Domain Service command line tool ⤒
Refer to the official documentation for details on all steps involved. Here I will cover only how to include Subject Alternative Names for your certificate.
In order to create a certificate, you first need to create a Certificate Signing Request, or CSR. This will let the certificate authority know which domains need to be protected.
The command to create a CSR with Subject Alternative Names has the following structure:
cf custom-domain-create-key KEYNAME "CERT_PARAMS" "DOMAIN1" "DOMAIN2" ...KEYNAME: Human-readable name for a private/public key (the public key will be included in the CSR).CERT_PARAMSmust contain at least the Common Name, orCN. You can see the supported parameters in the documentation (here).DOMAIN1,DOMAIN2… is the list of domains to be protected (they will translate into SAN’s)
At the end, it will look like:
cf custom-domain-create-key testdomainskey \
"CN=app1.example.com, EMAIL=admin@example.com, O=myorganization, C=mycountry" \
"app1.example.com" \
"app2.example.com" \
"portal.example.com"Backslashes allow for multi-line commands so it’s easier to read
After obtaining the Certificate Signing Request, you can go to your certificate authority of choice and request your certificate there. Please refer to the official documentation for the remaining steps and configurations.
Useful links:
- SAP Custom Domain Service in SAP Discovery Center for availability and pricing.
- SAP Custom Domain Service in SAP Help Portal for the official documentation.
- SAP Managed Tags:
