Custom Hostnames

How to link custom hostnames to your WEM Portals

IMPORTANT: our Shared Windows Runtime (staging.wem.io and live.wem.io) is no longer the default runtime and new projects should NOT be running on this environment.

Check forum post https://forum.wem.io/link?threadid=837 for information to get your existing Windows applications migrated to new Kubernetes Shared Runtime.

For new projects: if your Workspace does not yet provide Kubernetes Hosting Zones, please make a request in WEM Support.

At some point you might want to use a hostname that is part of your own domain to be linked to your WEM-portal.

Something like https://portal.yourdomain.ext

For this to work, you need to understand a bit about DNS and Hostnames, and most importantly the CNAME DNS record.

CNAME DNS Records

To let people access your WEM Portal by using your hostname, the Internet's DNS system needs to know where to go when the hostname is entered in a browser - and that is done by linking the hostname via a CNAME record to the location of the WEM Runtime Zone where your portal is running.

The CNAME Target values are the hostnames by which the WEM Runtime Zones are known and can be reached for internet traffic; once the WEM Runtime Zone is reached, the WEM Runtime Services will recognize your actual hostname in the request and the corresponding portal will be presented to the user.

Below are the standard steps for portals running in the West-Europe Kubernetes Zone:

Hosting Zones in Modeler Portal Settings

1. Create a CNAME record for the hostname in your domain's DNS management (or let your DNS management people do this for you).

2. Point the CNAME to live.westeurope.wem.io when your portal is using the WEM Shared West-Europe (kubernetes) hosting zone. Check below for other runtime zone values.

3. Add the hostname to your portal settings and publish from Modeler to Staging and Live (publish is a linear chain).

4. For an SSL Certificate, it is no longer necessary to make a WEM Support Request - the Kubernetes Runtime will automagically create a standard LetsEncrypt SSL Certificate when a new (custom) hostname is published and added to the Runtime. This may take up to 15 minutes so please allow the runtime to perform the necessary steps (request, validate, install) before checking your app for a valid SSL certificate. This service will fail when the CNAME is not correct or not yet available: the LetsEncrypt validation step will fail and the request will be blocked. If this is your case, you can create a Support ticket to let WEM Support check and manually fix your certificate requests, provided your custom DNS/CNAME record is correct and publicly available.

You can have multiple hostnames added to your portal, but they all MUST target the same Zone as indicated in the Hosting Zone setting of the portal.

So you can use and keep using the standard provided hostname that automatically uses the correct zone-related endpoint and add your own hostname as additional option to use when all settings (CNAME record and SSL certificate) are in place.

For CNAME records in your domain's DNS management, use:

Runtime Zone	CNAME target
WEM Shared West-Europe Live	live.westeurope.wem.io
WEM Shared West-Europe Staging	staging.westeurope.wem.io
WEM Shared US Live	live.us.wem.io
WEM Shared US Staging	staging.us.wem.io
EUR Live	no longer supported for new requests
EUR Staging	no longer supported for new requests
APAC Live	no longer supported for new requests
Kubernetes Private Cloud*	check with DevOps or WEM Support for the correct hostname.

CNAME and WEM Portal Hostname

A DNS-change like this may take up to 24 hours to be distributed along all DNS servers around the internet. You can check your hostname using Google's DIG: https://toolbox.googleapps.com/apps/dig/ - if it shows the correct value, you can assume the hostname is available to all (or at least most) users.

CNAME check in DIG

Use/Force HTTPS: LetsEncrypt default service

To have SSL available (and forced) for your custom hostname, WEM offers the service for free Let's Encrypt certificates. On WEM Kubernetes (Private) Clouds this is automatically handled - provided that the CNAME is correct.

The CNAME is used by the LetsEncrypt Validation Step to check that the hostname is indeed linked to the environment from where the request is created. If the CNAME is not available or not pointing to the correct environment, the request will fail and will be blocked. In that case, you need to ask WEM Support to manually start the request again - AFTER you have made sure the CNAME is correct.

This process can take up to 15 minutes, so please wait at least this long before checking if your newly published hostname is SSL secured.

For the current EUR and APAC Zones, we will no longer provide custom SSL certificates, but rather ask you to request a migration (https://forum.wem.io/link?threadid=837).

WEM Kubernetes Private Clouds

Obviously we cannot provide the CNAME Target values for the WEM Kubernetes Private Clouds in this public documentation. For any specific WEM Kubernetes environment, the correct CNAME target value can be obtained via authorized DevOps or WEM Support.

For portals running in a Kubernetes (Private) Cloud, some details may be different:

• The hostname may not be publicly available if the environment uses private DNS, in which case the check using Google DIG is not possible;

• The Publish DevOps Settings may be turned off in the Modeler Settings, in which case the hostname and https management must be done in the WEM DevOps Portal (and then there is no need to publish the changes for hostnames and https).

• The WEM DevOps Portal provides other options to manage SSL certificates, including starting a custom request to be handled by your Certificate Authority of choice.