HTTPS / SSL Certificates

HTTPS-Protocol

By default, we deliver all HTTPS sites via the modern HTTP/2 protocol for maximum performance. Of course, this option is also backwards compatible with HTTP/1.1 if a browser/client does not yet support HTTP/2.

If you wish to completely deactivate HTTP/2 on this subdomain and only deliver the site under HTTP/1.1, you can "downgrade" it here. However, we do not recommend this and there are no reasons to do so.

Force HTTPS

Would you like to always redirect your visitors to the encrypted website?

http:// → https://

As soon as the SSL certificate has been issued correctly, you can force HTTPS (recommended!). This means that any visitor will be automatically redirected from HTTP to HTTPS if he tries to access your website without encryption.

TIP

In addition to «Force HTTPS», you should also set the HSTS max-age header. See instructions below.

Aliases in SAN (subjectAltName)

INFO

This option is activated by default on the main subdomain (www), but not on additional subdomains, as these usually are not accessed via subdomain aliases.

If you also want to include all domain aliases in the SSL certificate, you can activate this option here. However, we advise against activating this option, as this may cause problems in the future during the automatic renewal of an SSL certificate if one of the domain aliases no longer points to our web server at that time.

With this option, all alias domains are also added to the SAN (subjectAltName) of the SSL certificate, e.g:

• sub.example.com (subdomain of the main domain)
• sub.example.net (subdomain of domain alias example.net)
• sub.example.com (subdomain of domain alias example.com)

If you do not publish these additional subdomains, they should not be included in the certificate.

Alternative Hostname in SAN (subjectAltName)

INFO

This option is not available on the main subdomain (www), as the alternative hostnames are always included in the SAN for the main subdomain by default.

With this option you activate our alternative hostname (also known as «Temporary URL») in SAN (subjectAltName) of the SSL certificate:

• web999.onlime.ch (main subdomain “www”)
• sub.web999.onlime.ch (subdomain “sub” as an example)

If you do not publish this URL externally, you do not need to include it in the certificate. The alternative hostname is only required for testing if your domain does not yet point to our web server or has not yet been registered.

HSTS (Strict Transport Security)

What is HSTS?

HTTP Strict Transport Security (also named HSTS) is an opt-in security enhancement that is specified by a web application through the use of a special response header. Once a supported browser receives this header that browser will prevent any communications from being sent over HTTP to the specified domain and will instead send all communications over HTTPS.

• Wikipedia: HTTP Strict Transport Security
• OWASP: HTTP Strict Transport Security (HSTS)
• MDN: Strict-Transport-Security
• RFC6797: HTTP Strict Transport Security (HSTS)

HSTS max-age

The HTTP header extension Strict Transport Security (HSTS) allows the server to instruct the browser that the connection should only be established via HTTPS. This gives you the additional security of ensuring that the browser accesses your website via https:// right from the start and is not dependent on the “Force HTTPS” setting above. Every browser with which your website has already been visited before remembers this setting for max-age number of seconds.

The following header is set on the server side if you have also activated “Force HTTPS ”:

Strict-Transport-Security: max-age=15768000

Under Apache, this corresponds to the following entry in the respective SSL VirtualHost:

Header always set Strict-Transport-Security "max-age=15768000"

You can turn off HSTS completely by entering 0 seconds as max-age value.

To positively influence the rating of your website in the SSL Server Test by QUALYS, you should set HSTS max-age to a value over 180 days (6 months), our recommendation: 15768000

IMPORTANT!

Only activate HSTS max-age if you know what you are doing! As soon as you have activated HSTS, there is no going back (or only after the previously defined max-age has expired) and your website is only accessible via HTTPS! Highly recommended, but not as long as your SSL certificate has not yet been issued correctly.

HSTS includeSubDomains

If you have activated HSTS max-age you can also extend HSTS to all subdomains by activating includeSubDomain.

If you make this setting on your main subdomain (www), HSTS includeSubDomain is set on your main domain and thus becomes valid for all subdomains. However, if you only activate includeSubDomains on one subdomain, HSTS will only be set for other sub-subdomains, for example *.sub.example.com.

When includeSubDomains is activated, the following header is set:

Strict-Transport-Security: max-age=15768000; includeSubDomains

HSTS preload

The following requirements must be met to activate the HSTS preload flag:

• The HSTS max-age must be at least 31536000 seconds (1 year).
• HSTS includeSubDomains must be activated.

When preload is activated, the following header is set:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

With preload you define a policy for your domain, which allows it to be included in the browser HSTS preload list. Most popular browsers (Chrome, Firefox, Opera, Safari, Edge) are based on Chrome's preload list. For more details, please refer to RFC6797 or hstspreload.org.

SSL Certificate

An SSL certificate is issued for each subdomain (including all domain aliases or domain pointings that point to this subdomain), or for each domain redirect. It's a Let's Encrypt certificate which is automatically renewed every 90 days by us.

Certificate Status

An SSL certificate can be in any of the following states:

SSL cert status	Description
request	The certificate was recently requested, either by adding or renaming a subdomain, or by adding an addon domain. The subjectAltnames (SAN) of the certificate are not yet collected and they will only show up once the cert is issued.
pending	The certificate is currently getting issued. Let's Encrypt is running HTTP-01 Challenge Checks and if all requested subjectAltnames (SAN) of the certificate can be resolved, the certificate is issued.
issued	The certificate was successfully issued. It's not yet installed in your webserver's VirtualHost, so wait for it to switch to INSTALLED.
installed	The certificate was successfully issued and installed in your webserver's VirtualHost configuration. It's now live!
reissue	There was a REISSUE of an existing certificate requested, either by domains getting added to the certificate's subjectAltnames (SAN) (e.g. created an addon domain as a domain alias/pointing), or by domains now resolving to your webserver which previously didn't (see DNS checks).
failed	The certificate issuance has failed for some reason. This is an edge case which only happens when our DNS checks for all provided subjectAltnames (SAN) succeed, but Let's Encrypt cannot issue the certificate. In this case, our support team is getting notified and we try to act asap. Don't worry, if this was a failure on a reissue, your previous working certificate will stay installed on your webserver.

subjectAltnames (SAN)

subjectAltnames stands for Subject Alternative Names (SAN), representing all domains that are included in the SSL certificate. Every subdomain runs its own SSL certificate, but it includes both www and non-www version of your domain, and every addon domain which points to that subdomain. Any domain alias or domain pointing that points to this subdomain is also included.

The only exception are domain redirects which run their own certificate. Domain redirects don't refer to any subdomain, as they are plain redirects which can point to any target URL. Those certificates can be managed directly under Addon-Domains.

Every subjectAltname (SAN) can be in any of the following states:

Installed	DNS	Description
		All good! All DNS checks have passed for the SAN and it is installed in the certificate.
		All DNS checks have passed but this SAN has not yet been installed in the certificate. This is usually just a temporary state, while the certificate is in REQUEST or REISSUE state, and will resolve shortly.
		One or more DNS checks for this SAN have failed, therefore it could not be installed in your certificate. You can click on the DNS icon to get further information about failed DNS checks and re-run the checks again. As long as at least one of the SANs is installed in your certificate, it will still run perfectly fine. This just means that this specific domain could not be added and you should try to resolve the DNS issues if you want to get it included.
		This is a very rare case when a SAN was previously resolving correctly (all DNS checks passed), it was installed in your certificate, but now the DNS checks no longer pass. Don't worry, an extra SAN in your certificate does not harm at all and it will eventually get removed by our consistency check / cleanup job.

Before a SAN can get installed in your certificate, it needs to pass the following 3 DNS checks:

	DNS check	Description
	A-Record Configuration	Verifies that the domain's A-record correctly points to the IP address of our web server.
	Let's Encrypt CAA Authorization	Checks if the CAA-records, if present, include Let's Encrypt (letsencrypt.org) as an authorized CA (Certificate Authority).
	IPv6 Record Absence	Confirms that no AAAA-records (IPv6) are set for the domain. The presence of IPv6 records might interfere with Let's Encrypt's authentication process, which primarily uses IPv4 for domain validation.

IMPORTANT

All of these 3 DNS checks are required to pass for any domain that is getting added to your SSL certificate. We are using Let's Encrypt HTTP-01 challenge to verify your domains upon certificate issuance.

You can see the results for each of these DNS checks by clicking on the «DNS» icon next to a subjectAltname (SAN). We'll show you exactly which check has failed and you can re-run the checks after fixing the issue in DNS.