1. Help Center Home
  2. Platform Overview
  3. Customer Site Settings
  4. Customer Site Settings – HSTS includeSubDomains

Customer Site Settings – HSTS includeSubDomains

WARNING: This setting is cached by web browsers for one year and cannot be quickly reverted so proceed with caution.

What is includeSubDomains in the HTTP Strict-Transport-Securty header?

When CIMcloud sends the Strict-Transport-Security HTTP response header, the includeSubDomains option extends the HTTPS-only policy to every subdomain of your site’s domain. Without it, only the exact domain visitors use is covered. With it, browsers will also refuse to load any subdomain over plain HTTP — including subdomains that your CIMcloud site does not control.

Example: If your CIMcloud site is www.example.com and includeSubDomains is enabled, the browser will also enforce HTTPS for portal.example.commail.example.comlegacy.example.com, and every other subdomain — even if those are separate applications hosted elsewhere.

For technical background on HSTS, see the MDN Web Docs reference: Strict-Transport-Security — HTTP | MDN

To manage this setting:

  1. Go to Settings Workspace > Customer Site Settings > Customers Sites
  2. Edit the site
  3. On the General tab, go to Security > Include Subdomains in Strict-Transport-Security Header (HSTS)

Is includeSubDomains Safe for Your Site?

Whether this option is safe depends entirely on whether every subdomain of your domain can be served over HTTPS. Review the scenarios carefully below to assess your situation. The header is cached for one year by browsers is

  • You have no third-party applications running on subdomains. Your CIMcloud site uses only www.example.com (and possibly example.com itself). There are no other third-party subdomains with web applications or services.
  • All subdomains already run HTTPS. Every subdomain of your CIMcloud site’s domain — including any third-party tools, portals, or integrations — is already configured to serve requests exclusively over HTTPS with a valid certificate.

includeSubDomains will break access to third-party application when:

  • A third-party application runs on a subdomain and still uses HTTP. Your CIMcloud site is example.com and support.example.com is a legacy help desk tool that does not have SSL configured or that redirects some requests over HTTP.
  • A subdomain is used for a service that cannot guarantee 100% HTTPS. Your CIMcloud site is example.com and ftp.example.commail.example.com used in links lacks a valid SSL/TLS certificate.
  • An ERP or internal tool is hosted on a subdomain and serves HTTP content. Even if it is only used internally, the browser-level HSTS policy will block access for anyone who has visited the main site.

How to Evaluate Whether a Third-Party Application Is Safe

To safely enable includeSubDomainsevery subdomain must serve 100% of its requests over HTTPS and 0% over HTTP.

Use the following steps to verify:

  1. Inventory your subdomains. Review your DNS records and list every subdomain of your domain that has web traffic (A records, CNAME records, etc.).

  2. Test each subdomain for HTTPS support. Open each subdomain in a browser using https://. Confirm that:

    • The page loads without certificate warnings.
    • The certificate is valid (not expired, not self-signed without trust).
  3. Test that HTTP is fully redirected or blocked. Open each subdomain in a browser using http://. Confirm that:

    • The browser is immediately redirected to https://or
    • The connection is refused (no HTTP server is listening at all).
    • There must be no pages, assets, or API responses served over plain http://.
  4. Check for mixed content. Even if the subdomain loads over HTTPS, verify it does not load any resources (images, scripts, stylesheets, iframes) from http:// URLs. Browser developer tools (Network tab) can reveal mixed-content requests.

  5. Verify all ports and paths. HSTS applies to all ports of a host, not just port 80/443. If the application uses non-standard ports, test those as well.

  6. When in doubt, contact the vendor of the 3rd party application.  CIMcloud is unable to evaluate third party applications.

If any subdomain fails any of the above tests, it must be resolved before enabling includeSubDomains.

Fixing a Third-Party Application Broken by includeSubDomains

CIMCloud is unable to notify affected users or clear affected browser caches.

If includeSubDomains was already enabled and a third-party application on a subdomain stopped working for users, take the following steps:

Immediate Steps

  1. Revert the setting in the Worker Portal
  2. Notify all affected users. Users whose browsers have cached the HSTS policy will be unable to access the broken subdomain for up to one year. They will see a browser error that cannot be bypassed. Ask them to:

    • Clear their browser’s HSTS cache. In Chrome, visit chrome://net-internals/#hsts, search for your domain, and delete the HSTS entry. In Firefox, clearing all browsing data (including cached content) will remove stored HSTS policies.
    • Restart the browser after clearing.

Resolving the Root Cause

Choose one of the following approaches for the affected subdomain:

  • Update the third-party application to use HTTPS. Install a valid SSL/TLS certificate on the application, configure the server to redirect all HTTP traffic to HTTPS, and verify there is no remaining HTTP content. Once fully HTTPS-compliant, includeSubDomains can safely be re-enabled.

  • Move the third-party application to a different domain. If it is not feasible to add HTTPS to the application, move it to a domain (or subdomain of a different domain) that is not covered by your site’s HSTS policy. For example, move legacy.example.com to legacy.example-internal.com — a separate domain entirely.

Was this article helpful

Related Articles

Subscribe to receive email updates of what's new in the CIMcloud Help Center.