Once you have received your subscription package information, it is important to understand how domains and certificates are managed in Magnolia Cloud.

There are two approaches available in Magnolia Cloud for domain and certificate management.

  • You have a relatively simple setup and leave the management of your single domain and certificate to Magnolia, with limited redirects in place. Your involvement is limited to registering your domains and requesting your domain mappings via the Cloud Helpdesk.
  • You have a complex scenario involving multiple domains, your own pre-existing infrastructure or regulatory constraints. You prefer to keep full ownership and control of your domain and certificate management.


Magnolia-managed setup

In a simple setup, Magnolia manages your domain and certificates.

Magnolia Cloud subscriptions have one root domain (also known as base, bare, naked, apex root or zone apex domain). By default, these are:

  • mycompany.com — Root domain.
  • www.mycompany.com — Subdomain.

Magnolia Cloud completely manages the root domain and its certificate.

You, or your chosen cloud partner, are responsible for:

  • Maintaining the Domain Name System (DNS) records on your chosen DNS provider infrastructure and adding any entries needed for Magnolia Cloud to verify ownership and certificate validation challenges.
  • Verifying and updating your Certification Authority Authorization (CAA) records if you use them. This is so that certificate validation requests can succeed.

Certificate authorities implementing CAA perform a DNS lookup for CAA resource records, and if any are found, ensure that they are listed as an authorized party before issuing a digital certificate.

Source: Wikipedia

What Magnolia provides

In a managed setup, Magnolia provides:

  • Two possible ways to point your domains to the Magnolia Cloud Live environment:
    • Preferred — A subdomain to point your subdomain/s as CNAME entries to: public-live-<subscription-code>.de.magnolia-cloud.com
    • Alternative required for root domains — A pair of fixed public IPs, provided by AWS Global Accelerator service, belonging to your subscription (each subscription has a unique pair of IPs) to point the root domain/s as A entries.
  • A DNS entry to verify ownership of the domain and validate certificate requests: example-hash.amazon.verify

Validating your domains

Before going live, we verify that you own and control all of the domain names specified on your Magnolia Cloud Helpdesk ticket. You can choose DNS (preferred) or email validation. 

  • DNS validation: You add a CNAME record to the DNS configuration for your domain. The CNAME record is provided by our Helpdesk and sent to you in your Helpdesk ticket. The certificate of the domain is valid as long as the CNAME record exists. You can revoke the permission at any time by removing the CNAME record. 

  • Email validation: You receive an email from AWS. To validate ownership of your domain, you must go to the Amazon certificate approval website and approve the request. Further instructions are provided in the body of the email. 

The following restrictions apply:

  • There is a maximum of 25 registered domain certificates per subscription.*
  • A certificate can hold a maximum of 30 domain names (including main domain and SAN entries).
  • The managed certificates cannot be used outside of Magnolia Cloud.

*To avoid reaching this limit, you can register a new domain that holds some or all existing domains while setting up the new domains as Subject Alternative Names (SAN). The new domain(s) are validated and associated to the applicable environment in replacement of any existing domains that were included in the new registered domain.

Automatically assigned (technical) domains

Magnolia automatically assigns a technical domain to each space. These domains are used, for example, in the cockpit to create links to the AdminCentral UI of Magnolia and to view the public space of an environment. For example: 

You should provide access to your websites in the Live environment using your own registered domain names. For example:

EnvironmentTechnical domain assigned to the public space
Integrationpublic-integration-<subscription-code>.de.magnolia-cloud.com
UATpublic-uat-<subscription-code>.de.magnolia-cloud.com
Livepublic-live-<subscription-code>.de.magnolia-cloud.com

You should provide access to your websites in the Live environment using your registered domain names. For example:

EnvironmentTechnical domain assigned to the public spaceYour domain names
Livepublic-live-<subscription-code>.de.magnolia-cloud.com

www.my-company.com

www.mycompany.com

Multisite domains

The Multisite module allows you to administer multiple websites from a single Magnolia subscription package. Domains used by the Multisite module must be terminated on the instance. Make sure that your domains are directly pointed to the IP or the CNAME provided by Magnolia with no gateway or redirects in between. 

If you want to more about how to use multisite, see How to use Multisite.

Adding CNAME records for your own domain names

You can register one or more CNAME records for each public space of the three Magnolia environments. However, in many cases, it is sufficient to have at least one record for the public space of the Live environment.

You must register at least one CNAME record to provide access to the public space of the Live environment under your own (registered) domain name. If you have configured multiple site definitions in order to run multiple websites, register one CNAME record for each domain.

To use your own domain name in the current release of the Magnolia cloud offer, you should ideally own the domain before subscribing to and onboarding a Magnolia PaaS plan. 

Create a Helpdesk ticket to request your domain mapping setup. 

Below is an example of a CNAME record for one domain mapped to the public space of a Live environment.

HostnameIP / Target
www.my-company.compublic-live-<subscription-code>.de.magnolia-cloud.com

Typically, you edit your CNAME records in the web interface of the domain name registrar where you registered your domains.


Managed and unmanaged Multisite domains and certificates

The solutions and restrictions for multisite domains and certificate management are the same as those described in Magnolia-managed domain and certificates.

Unmanaged setup

If you already have infrastructure supporting your enterprise domain management system or need to comply with specific regulatory or security constraints, you may choose to manage your own domains and certificates. 

SLA

In an unmanaged setup, note that your Magnolia SLA and availability and uptime checks and monitors of the subscription are affected.

Unmanaged certificates

When Magnolia does not manage the creation of certificates, we offer a manual import of the certificate for the root domain.

Once the initial certificate import is done, you or your cloud partner are responsible for installing renewed certificates via the Cloud Helpdesk. Magnolia does not oversee this process. 

There is a maximum of 25 domains (certificates).


Unmanaged domains

Managing your own domains gives you the most flexibility but you must have your own infrastructure or service to do so.

If you or your cloud partner decide to manage your own domains and certificates, Magnolia only provides the CNAME entries and the associated public IPs for the Magnolia cloud instances, such as [public|author]-<environment>-<subscription-code>.magnolia-cloud.com

Redirects

Magnolia Cloud offers 301 redirects for:

  • The root domain.
  • Multisite module domains.

For example:

FromTo
my-company.comwww.my-company.com

If you need other redirects, you or your cloud partner are responsible for their implementation.

For example, you or your cloud partner would be responsible for the following redirects:

FromTo
my-company.commycompany.com
my-company.demycompany.com
mycompany.chmycompany.com
mycompany.limycompany.com
mycompany.liwww.mycompany.com
mycompany.co.ukmycompany.com
www.my-company.co.ukmycompany.com

You may consider these possible solutions to manage your own redirects:

  • Redirects on the domain registrar — Modern domain registrars support URL redirects. This would save the certificate management for those domains.
  • Use your own account with API Gateway Service or external forwarding service (proxy) contracted directly by yourself or partner (services such as Kong, Tyk, Apigee or sub-services of CDN providers such as Akamai).
    With this approach, you can configure all your domains, redirects and certificates while fully owning and not sharing the certificates and point those to the Magnolia-provided default domain and certificate. While this setup requires you to manage domains separately from the cloud, it also provides you with the most flexibility concerning domain configuration. It also removes the need for sharing certificates for the domain with Magnolia thus providing the highest level of security for domain-certified content.

Path redirects

If you want to do path redirects, you or partner must configure them in the Virtual URI mapping module or using other equivalent Magnolia functionalities.

For example:

FromTo
www.mycompany.com/old-path-to-contentwww.mycompany.com/content
art.mycompany.comwww.mycompany.com/art

In the latter example, a combination of a CNAME record and a host-based virtual URI mapping would do.

Context path

Magnolia Cloud always deploys to the ROOT context. It is not possible to change this.

For scenarios where adaptations to the context path are needed, we recommend you use a reverse proxy or an API Gateway to give you the most flexibility.

SEO recommendations

Only root and multisite domains should be terminated on the load balancers or instances. This means all other domains should be 301 redirected before to root or multisite ones. Magnolia does not offer this service. We recommend you use a solution such as an API Gateway Service. 


#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))