Cloud domains and certificates
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.
| Option | Notes |
|---|---|
In this case, you leave the management of your domain(s) and certificate(s) to Magnolia, with limited redirects in place. Your involvement is limited to registering your domains and requesting your domain mappings via the Cockpit. |
|
This might involve 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 this case, you fall under the unmanaged setup option, meaning that Magnolia does not manage domains and certificates for you. |
| See Managing certificates for steps on managing certificates via the Cockpit. |
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
| See Managing certificates for steps on requesting certificates via the Cockpit. |
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 that added in the Cockpit. You can choose DNS (preferred) or email validation.
-
DNS validation: You add a CNAME record to the DNS configuration for your domain. 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:
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.
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 |
|---|---|
Integration |
public-integration-<subscription-code>.de.magnolia-cloud.com |
UAT |
public-uat-<subscription-code>.de.magnolia-cloud.com |
Live |
public-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:
| Environment | Technical domain assigned to public space | Your domains |
|---|---|---|
Live |
|
|
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.
Internationalized domains
Magnolia Cloud supports Internationalized Domain Names (IDNs). When entering an IDN for your domain name, we convert the Unicode input to Punycode.
| In the Cockpit, your domain name is displayed in Punycode. |
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.
Below is an example of a CNAME record for one domain mapped to the public space of a Live environment.
| Hostname | IP / Target | ||
|---|---|---|---|
|
public-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 the Magnolia-managed setup.
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. Magnolia does not oversee this process including certificate renewal.
| See Managing certificates for steps on importing certificates via the Cockpit. |
To import a self–signed SSL/TLS certificate into ACM, you must provide the certificate and its private key. To import a signed certificate, you must also include the certificate chain. Your certificate must satisfy the following criteria:
The certificate must specify a cryptographic algorithm and a key size. The following algorithms are supported by ACM:
1024-bit RSA (
RSA_1024)2048-bit RSA (
RSA_2048)4096-bit RSA (
RSA_4096)Elliptic Prime Curve 256 bit (
EC_prime256v1)Elliptic Prime Curve 384 bit (
EC_secp384r1)Elliptic Prime Curve 521 bit (
EC_secp521r1)See AWS Importing Certificate for more in-depth information.
| There is a maximum of 25 domain 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:
| From | To |
|---|---|
my-company.com |
www.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:
| From | To |
|---|---|
my-company.com |
mycompany.com |
my-company.de |
mycompany.com |
mycompany.ch |
mycompany.com |
mycompany.li |
mycompany.com |
mycompany.li |
www.mycompany.com |
mycompany.co.uk |
mycompany.com |
www.my-company.co.uk |
mycompany.com |
|
You may consider these possible solutions to manage your own redirects:
With this approach, you can configure all your domains, redirects andcertificates 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
Use the Virtual URI Mapping feature in Magnolia for path redirects.
For example:
| From | To |
|---|---|
www.mycompany.com/old-path-to-content |
www.mycompany.com/content |
art.mycompany.com |
www.mycompany.com/art |
| In the latter example, a combination of a CNAME record and a host-based virtual URI mapping would do. |