No Pain, No Gain. Get Started with SAP Cloud Platform Custom Domains

Introduction

 

When you deploy an application on SAP Cloud Platform, you receive a one-of-a-kind URL to access it. For example, https://mycompany0a12345b.hana.ondemand.com. Hard to pronounce and even harder to remember, isn’t it?

Instead, you can tailor a much better looking and more comprehensible URL: www.mycompany.com. This way your customers won’t get confused.

Prerequisites

 

To use SAP Cloud Platform custom domains in the Neo environment, you’ll need to go through several interactions with providers external to SAP before starting the configuration of your custom domain.

First of all, don’t underestimate the prerequisites. Follow them step by step to avoid missing any relevant details.

 

Basic Terminology

 

To help you learn more about the SAP Cloud Platform custom domain terminology, let’s look at some of the basic notions. The correlation between SSL hosts, domain certificates, and custom domain quota is not always that clear. Once you manage to wrap your head around these notions, the overall picture gets much brighter. Let’s briefly look at how they interact with each other.

• Custom Domain Quota

For each SAP Cloud Platform custom domain you purchase, you gain one custom domain quota.

• Domain (SSL) Certificate

One custom domain quota allows you to upload a maximum of four domain certificates.

Note: You can use only one of the uploaded certificates for production purposes.

• SSL Host

For each custom domain quota, you can create one SSL host using the create-ssl-host command. When you run the bind-domain-certificate or set-ssl-host commands, you can bind only one certificate to it.

The SSL host URL ends in *.ssl.ondemand.com. You need it when you update your DNS records. You can always get the SSL host URL by running the list-ssl-hosts command.

 

What’s the difference between a domain certificate and a certificate signing request (CSR)?

 

The CSR is an encoded file that holds your public key and contains specific information that identifies your company and domain name. To be able to use an SAP Cloud Platform custom domain, it is recommended to create a CSR using the generate-csr command.

Note: You also have the option to upload a certificate that is not based on a CSR generated via the generate-csr command. To do that, you must use the -k parameter in the upload-domain-certificate command to upload the certificate’s private key. However, note that uploading a private key from a remote location poses a security risk. For that reason SAP recommends that you use only certificates that are based on CSRs generated via the generate-csr command.

Running the generate-csr command doesn’t grant you the domain certificate right away. You need to send the generated CSR to a certificate authority (CA) of your choice. Some of the popular certificate authorities are GoDaddy, Symantec, Verizon, Comodo, DigiCert, IdenTrust, etc.

Then the CA signs the CSR and sends you back the domain certificate. Later, you have to upload that certificate to SAP Cloud Platform and bind it to the SSL host that you’ve already created.

 

I have one certificate. How many custom domains can I protect with it?

 

The number of custom domains you need usually depends on your business case. Also take into account that you protect your custom domain using a domain certificate.

There are three types of certificates. Each certificate type comes with its own specifics and protects a different number of domains and subdomains. Some of these certificate types may not apply to your scenario so plan carefully. Here are some of these specifics:

• Standard certificate

It protects one domain (www.mycompany.com). It doesn’t protect any other subdomains (login.mycompany.com).

The standard certificate provides protection for one domain only. If you want to secure any other subdomains, you will have to purchase a separate certificate for each separate subdomain. This means that you will need more SSL hosts, thus additional custom domain quota.

• Wildcard certificate

It protects multiple subdomains of one level (test.mycompany.com, preview.mycompany.com, www.mycompany.com, etc.), but not the domain itself (mycompany.com).

If you have a website that has multiple subdomains, instead of buying an SSL certificate for each subdomain, you can protect all subdomains with one wildcard SSL certificate.

In the context of SAP Cloud Platform, mapping lots of subdomains to a single SSL host also has some disadvantages:

• If the certificate suffers from a security breach, it may affect all applications that are hosted on these subdomains.
• If the HTTP traffic is too massive, it may cause performance issues for all applications that are hosted on these subdomains.

If there are too many custom domain mappings, you may consider using more SSL hosts to spread the certificate bindings and reduce the HTTP traffic load.

• Subject Alternative Names (SAN) certificate

It protects multiple domains (www.mycompany.com, www.mycompany.net, www.mycompany.de, etc.) and subdomains of one or more levels (www.mycompany.com, login.test.mycompany.com, etc.).

The SAN certificate lets you secure several websites, including many domains and subdomains. That’s why it’s often called a multidomain certificate.

 

Configuration Steps

 

Now that you’ve got to know the prerequisites and the basic SAP Cloud Platform custom domain terminology, you should feel much better prepared when going through the custom domain configuration process. Nevertheless, some doubts may pop up while going through the steps. Let’s have a look at some of the most frequently asked questions:

 

How do I check my custom domain quota?

 

Having the knowledge that one custom domain quota lets you have one SSL host and up to four domain certificates in total, let’s see how you can check what’s left of your custom domain quota. We’ll use a couple of examples.

The first example shows a part of the output of the list-ssl-hosts command:

In this case, the owner of the global account has a custom domain quota of two. The quota is currently maxed out in terms of SSL hosts, because there are two SSL hosts created for that specific subaccount.

The second example shows a part of the output of the list-domain-certificates command:

The account quota here shows the number eight, because one custom domain quota grants you a quota for having up to four domain certificates. Thus, 2 x 4 = 8. In this example though, the quota is not maxed out, because there are currently six uploaded certificates in the same subaccount and the maximum number of allowed certificates is eight. The owner can still upload up to two certificates in that subaccount.

Of course, you have probably noticed that if you have a custom domain quota of two, two SSL hosts, and six certificates in total, you will need no more than two certificates at any given moment. That’s because you can’t bind two or more certificates to an SSL host. Let’s just say that for some business scenarios, you may want to have more than the needed number of certificates. However, if you think you don’t need a specific certificate, you can delete it with the delete-domain-certificate command.

 

How do I update my DNS records?

 

Each DNS hosting service has its own DNS settings, but the general logic is more or less the same.

Your goal here is to point the traffic for your custom domain to your application on SAP Cloud Platform:

1. Get your SSL host URL (for example, EU0123456789012.ssl.ondemand.com) previously obtained using the create-ssl-host command. If you don’t have the SSL host URL at your disposal, you can get it with the list-ssl-hosts command.

2. Add a CNAME record for each domain name to point to the SSL host URL. In the following example, there is one domain name: www.mycompany.com

For more information about this step, see Configure DNS.

 

Troubleshooting

 

Apart from the custom domain documentation, there are other sources of information that you may also want to try out such as the Guided Answers for custom domains in the Neo environment of SAP Cloud Platform. Their goal is to provide you with seamless troubleshooting experience.

You can learn more about the guided answers as a whole from Ani’s blog Guided Answers for SAP Cloud Platform.

 

Conclusion

 

These are one of the most difficult-to-understand parts of the process. Hopefully, now you feel more confident to embark on your SAP Cloud Platform custom domain journey. If you find something else about the configuration steps that’s hard to grasp, don’t hesitate to share it with the rest of the SAP community in the comments section below!