style
content

Custom domains without a custom CDN

The most common way of going live with a AEM site is to use a custom Content Delivery Network (CDN). Our documentation provides instructions for the most common CDN providers and through your Slack support channel, the AEM team provides assistance.

If you do not have a CDN, we can provide you with assistance in setting up a custom domain without a CDN.

Prerequisites and limitations

Before you go live

Reach out to the Adobe team in your dedicated Slack channel and tell them which domain (e.g. www.example.com) you want to use and which site (e.g. https://main–example–hlxsites.hlx.live) should be the content source.

The Adobe team will verify the request and tell you when you are ready for the next step. This will usually take a few hours and might take up to one business day.

Setup push invalidation

Push invalidation automatically purges content on the managed CDN whenever an author publishes content changes.

Content is purged by url and by cache tag/key.

Push invalidation is enabled by adding specific properties to the project's configuration (an Excel workbook named .helix/config.xlsx in Sharepoint or a Google Sheet named .helix/config in Google Drive).

Configuration properties:

key value comment
cdn.prod.host <Production Host> Host name of production site, e.g. www.example.com
cdn.prod.type managed

After making changes to the config sheet, preview it with the sidekick to activate the changes.

Authorize the creation of the domain validation (DV) Certificate through ACME Challenge

This ensures that the domain validation certificate is available before any traffic is directed to the CDN.

Create a CNAME as below (aka ACME DNS challenge ) to authorize the creation of the DV Certificate

_acme-challenge.<your-domain-name> CNAME <challenge-value>

For e.g.

_acme-challenge.example.com CNAME random-value.example-acme-server.com

The “challenge value” would be provided to you by the AEM team.

Once the above is done, execute dig command as below

$ dig _acme-challenge.example.com

And ensure that it responds with

_acme-challenge.example.com. 19454 IN CNAME random-value.example-acme-server.com.

If you got the response as above, you can skip the “Special Note“ below.

Note: Once the DV Certificate challenge has been created, customers have 7 days to create the validation CNAME. If not done within 7 days, then the Adobe team needs to retry the certificate issue process after the validation CNAME is created.

Special Note for DNS providers that require a trailing period (.)

Some but not all DNS providers require that a period (.) is added to the end of a target DNS to indicate that it is not local to the DNS Zone where the CNAME is being added.

dig and nslookup also add a . to the end of a domain reported to show it is fully qualified and not in the context of the zone being queried.

For instance, if we say we need a CNAME like the one below, we are using Full FQDNS (as you would see in a http url)

_acme-challenge.example.com CNAME random-value.example-acme-server.com

We expect it to be added so that

$dig _acme-challenge.example.com

responds with

_acme-challenge.example.com. 19454 IN CNAME random-value.example-acme-server.com.

And not…

_acme-challenge.example.com. 19454 IN CNAME random-value.example-acme-server.com.example.com.

(here the record was added to the DNS provider with no trailing period (.) after example-acme-server.com and hence the DNS provider assumed the target was local to the zone, i.e. example.com.... which makes no sense for an ACME DNS challenge)

To handle such situations, where your DNS provider requires you to add a trailing period (.), create a CNAME record as below:

_acme-challenge.example.com. CNAME random-value.example-acme-server.com.

Observe the trailing period (.) in the example above.

Retry the dig command as follows

$dig _acme-challenge.example.com

And ensure that now it responds as expected with

_acme-challenge.example.com. 19454 IN CNAME random-value.example-acme-server.com.

Optionally lowering TTL of existing DNS records in preparation of going live for faster roll-out

If your existing DNS records for the domain which is set to go live, have a long TTL (like 12 hours or more), then for faster roll-out of the site once it is live, you may want to set it to a lower TTL (like 1 hour or maybe even as low as 60 seconds). This ensures that after going live, the traffic starts getting routed to the new site faster instead of waiting for the original TTL to expire. Do remember to restore the TTL back to the original value while updating the DNS records for going live.

As you go live

Make or request following DNS change:

If you want to establish an automatic redirect from from https://example.com to https://www.example.com the following additional steps are required

Depending on your existing DNS setup including the TTL specified in the DNS records, these changes can take a few minutes to several hours to complete. If you have existing traffic on the site, make sure all redirects are in place or keep your existing site functional till the traffic has completely been redirected to the new site, which is essentially waiting out for the duration of the TTL in the DNS records to expire.

The certificates are issued automatically after you have successfully set up the ACME challenge as explained in the “Authorize the creation of the DV Certificate through ACME Challenge” section above.

Please note that if you are hosting both APEX and the `www` domains they both need to have the DNS configured for the certificate to be generated.

If you are looking for a timed launch, it is a good idea to create a temporary holding home page that will be replaced with the correct content at the desired launch time. As publishing in AEM is fast and predictable, this will give you more control over the visibility of your content than relying on DNS.

After you go live

The AEM team will verify your setup and let you know if any problems arise.