Can I change the HTTPS inheritance for parked and add-on domains in WHM?

Below is a detailed explanation of how HTTPS behavior works for parked and add-on domains within WHM (WebHost Manager), along with guidance on how you might effectively “change” or more precisely manage the certificate assignments and behavior for these domains. This discussion covers the underlying concepts, the configuration options available in WHM/cPanel, and best practices to ensure that each domain uses the proper SSL certificate.

Understanding Parked and Add-On Domains in WHM

Before addressing HTTPS inheritance directly, it is important to clarify the differences between the types of domains managed via WHM:

• Parked (Alias) Domains: These are domains that point to the same content as your primary domain. They are often used for branding, redirect purposes, or to capture misspelled traffic. Traditionally, a parked domain may be served using the SSL certificate associated with the primary domain if that certificate covers the parked domain’s name.
• Add-On Domains: Unlike parked domains, add-on domains are separate domains that host their own website files, usually in a separate directory. However, by default, if no dedicated SSL certificate is installed for an add-on domain, its secure access (HTTPS) can fall back on the “inherited” certificate from the primary domain. In both cases, a mismatch or lack of proper domain coverage in the certificate leads to browser warnings.

The term “HTTPS inheritance” is not a formal option provided in WHM; rather, it describes the default behavior wherein if a dedicated certificate is not assigned, a parked or add-on domain may inadvertently use the certificate of its parent or primary domain. This practice is common when a certificate is a wildcard (or multi-domain) certificate covering several domains, but it can lead to issues if the certificate does not list all the domains served.

How SSL Certificates and Domain Coverage Work

Certificate Scope and Domain Coverage

An SSL certificate is bound by the domain names that it covers. For a browser to consider an HTTPS connection secure, the following must be true:

• The certificate must be issued to the specific domain (or a wildcard pattern or SAN list covering that domain).
• There must be no mismatches between the certificate’s common name (and any subject alternative names) and the domain being requested.

When you have a primary domain with an SSL certificate that does not include the parked or add-on domains in its coverage, users visiting those additional domains over HTTPS will encounter security warnings. In some configurations, particularly when using shared certificates, the add-on or parked domain might “inherit” the primary domain’s certificate if no specific instructions are provided otherwise. This is what is generally referred to as HTTPS inheritance.

The Role of AutoSSL

In recent versions of cPanel/WHM, the introduction of AutoSSL has greatly simplified the management of SSL certificates:

• AutoSSL for All Domains: AutoSSL is designed to automatically detect all domains (including add-on and parked domains) associated with an account and install valid SSL certificates for each.
• Separate Certificates for Each Domain: When AutoSSL is enabled, rather than “inheriting” an SSL certificate from the primary domain, each domain receives its own certificate (often from Let’s Encrypt or cPanel’s preferred provider). This eliminates the browser errors associated with certificate mismatches.

This shift means that rather than trying to “change inheritance,” you would ensure that each domain is covered appropriately with its own certificate via AutoSSL or by manually installing a multi-domain or individual certificate.

Can You Directly Change HTTPS Inheritance?

There is no direct WHM configuration toggle labeled “HTTPS inheritance” that you can switch on or off for parked and add-on domains. Instead, the behavior is determined by:

• Certificate Installation Method: Whether a certificate that covers all domains (a multi-domain/SAN or wildcard certificate) is installed.
• AutoSSL Configuration: How AutoSSL is configured and whether it automatically issues certificates for all types of domains.

If your goal is to change or override the default certificate behavior for parked and add-on domains, the following methods are recommended:

1. Installing a Multi-Domain SSL Certificate

A common solution is to issue a certificate that explicitly includes all the domain names in question. This can be achieved by:

• Purchasing a SAN Certificate: A Subject Alternative Name (SAN) certificate can list several different domains in one certificate. When you install such a certificate for an account, it covers the primary, add-on, and parked domains as long as they are all specified in the SAN entries.
• Using a Wildcard Certificate: If the add-on and parked domains are subdomains or follow a predictable pattern, a wildcard certificate (e.g., *.example.com) might be appropriate, though note that wildcards do not typically cover different base domains.

This method prevents the inheritance issue by explicitly providing the necessary domain coverage, thereby avoiding browser warnings.

2. Configuring AutoSSL to Issue Individual Certificates

If you prefer automated management, ensuring that AutoSSL is enabled and properly configured can resolve HTTPS inheritance concerns:

• Enable AutoSSL in WHM: Navigate to the AutoSSL section in WHM. Ensure that AutoSSL is enabled for your server and that it is set to include add-on and parked domains.
• Account-Level Settings: Some settings in the account’s configuration can be adjusted to ensure that AutoSSL recognizes and secures all domains associated with that account.
• Periodic Certificate Renewal: AutoSSL manages certificate installation and renewal periodically. This means that even if a domain is newly added or parked, AutoSSL will detect and secure it without manual intervention.

By having AutoSSL issue a certificate for every domain, you effectively circumvent the “inheritance” issue, because each domain presents its own valid certificate rather than relying on a parent’s SSL certificate.

3. Manual Certificate Installation for Specific Domains

For complete control, you may choose to manually install an SSL certificate for each add-on or parked domain:

• Access SSL/TLS Manager in WHM: Use the “Manage SSL Hosts” or “Install an SSL Certificate on a Domain” interface within WHM to add certificates specifically for each domain.
• Verification of Domain Coverage: When doing this manually, ensure that the installed certificate includes the correct domain names in its SAN list.
• Avoiding Inheritance Mismatches: By taking manual control, you eliminate any potential for misdirected certificate assignment that might occur when a domain inadvertently inherits the primary certificate.

This approach is more labor-intensive but offers precise control over which certificate is served for each domain, ensuring compatibility with secure HTTPS connections.

Considerations and Best Practices

Certificate Matching and Browser Trust

Browsers rely on the presented certificate matching the domain. Therefore, any configuration that leads to a domain “inheriting” a certificate not intended for it will result in trust warnings. This is particularly significant when:

• The primary certificate does not include SAN entries for parked or add-on domains.
• An add-on domain has been misconfigured to point to the same certificate file as the primary domain.

Always verify your SSL configuration using online tools (such as SSL Labs’ SSL Server Test) to ensure that all served certificates are correct and that no unexpected inheritance is occurring.

Impact on SEO and User Trust

While HTTPS is a critical ranking factor for SEO and a trust signal for users, misconfigured SSL certificates can have the opposite effect. An inherited or mismatched certificate might result in users encountering security warnings, which could reduce traffic and damage the reputation of your websites. Therefore, it is crucial to ensure that each domain is properly secured.

Testing and Verification

• Staging Environment: Before applying changes in production, it is advisable to test changes in a staging environment.
• Monitoring Certificate Expiry: Whether using AutoSSL or manual installations, monitor certificate expiry dates to avoid unexpected downtime or security warnings.
• Client Communication: If changes affect end users (for example, if you need to redirect traffic temporarily), communicate these updates through proper channels.

Frequently Asked Questions (FAQ)

1. Can a parked (alias) domain use a different SSL certificate than the main domain it points to?

No — a parked domain shares the virtual host with the primary domain. Consequently, only one SSL certificate can be assigned to that host. If you attempted to install a different certificate for the alias, it would replace the certificate for the primary domain as well.

2. Is it possible to install SSL separately for an add‑on domain?

Yes — an add‑on domain is a standalone virtual host. That enables you to install a separate SSL certificate that covers that domain only. Unlike a parked domain, it does not share the certificate with the primary domain

3. What SSL behavior should I expect when using AutoSSL with parked or add‑on domains?

When AutoSSL is enabled, WHM/cPanel automatically detects all domains—including both add‑on and parked domains—and attempts to issue SSL certificates for each. If successful, each domain gets its own certificate, eliminating awkward “inheritance” issues. If no certificate exists yet, the system will generate a self‑signed one until AutoSSL installs a valid one.

4. If I want unique SSL coverage for a parked domain, what is the recommended approach?

Since parked domains cannot hold their own separate certificates, the recommended approach is:

• Convert the parked domain into an add‑on domain, pointing to the same document root as your primary domain.
• Then install a dedicated or SAN certificate that includes that domain name. This allows independent SSL coverage while still serving the same content.

5. What happens if a domain name is pointed to remote nameservers when adding an add‑on or parked domain?

By default, WHM disallows adding domains whose DNS does not resolve to your server. If needed, you can enable the “Allow Remote Domains” option in WHM’s Tweak Settings → Domains. This lets you add domains even if they’re using external nameservers. Note: enabling this setting poses potential security risks and should be used judiciously.

Conclusion

To summarize, WHM does not offer a direct “HTTPS inheritance” toggle that you can change. Instead, the inheritance behavior observed with parked and add-on domains is a consequence of how SSL certificates are installed and recognized by the system:

• If a domain lacks its own SSL certificate, it may appear to “inherit” the certificate of the primary domain.
• To ensure that every domain has valid, matching SSL coverage, you should consider issuing a multi-domain or SAN certificate that covers all the intended domains, or leverage AutoSSL to issue separate certificates for each domain.
• Alternatively, manual certificate installation for each domain provides the most control if AutoSSL does not meet your specific requirements.

In practice, managing SSL for multiple domains is best addressed through careful planning of your certificate strategy, ensuring that every domain (whether primary), add-on, or parked—is covered by a certificate that accurately lists its domain names. This approach not only resolves any issues regarding HTTPS inheritance but also guarantees secure, trustworthy connections for your end users.

For further details and official recommendations, you may refer to the cPanel documentation on AutoSSL and SSL/TLS management:
cPanel AutoSSL: https://docs.cpanel.net/whm/ssl-tls/manage-autossl/

Managing SSL/TLS in WHM: https://docs.cpanel.net/cpanel/security/ssl-tls/

By following these guidelines, you will have full control over SSL certificate management for parked and add-on domains in WHM, ensuring that each domain serves HTTPS correctly and securely.