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.
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.
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.
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:
- 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.
- Preferred — A subdomain to point your subdomain/s as CNAME entries to:
- A DNS entry to verify ownership of the domain and validate certificate requests:
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 domains (certificates) per subscription.*
- 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:
|Environment||Technical domain assigned to the public space|
You should provide access to your websites in the Live environment using your registered domain names. For example:
|Environment||Technical domain assigned to the public space||Your domain names|
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.
|Hostname||IP / Target|
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.
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.
In an unmanaged setup, note that your Magnolia SLA and availability and uptime checks and monitors of the subscription are affected.
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).
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
Magnolia Cloud offers 301 redirects for:
- The root domain.
- Multisite module domains.
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:
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.
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.
In the latter example, a combination of a CNAME record and a host-based virtual URI mapping would do.
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.
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.