Alias domains and HTTPS
We are receiving increasing reports from customers about certificate mismatch issues when dealing with aliases and redirects.
As the world goes https, unfortunately cpanel aliases are getting left behind. A customer can no longer easily redirect one domain to another without getting SSL errors.
Obviously, Aliases don't have a vhost entry and they can't have their own certificates - so adding them at all now seems almost completely pointless, when the entry point to most domains in whatever form is almost always https now.
It's impractical to ask a customer to purchase more addon domains just so they can redirect one domain to another.
The issue often stems from Google results - where it seems all URL's contain https - even if the domain is not https enabled.
Its really hard to tell a customer that there's nothing we can do to help with this issue.
There is clearly a need for customers to redirect domains to other domains and this is most definitely the job of the web server. I do hope cpanel have a solution going forward. Perhaps there is a way to have a vhost entry and autossl certificate, without allowing for a website to be hosted from the domain?
Something needs to be done though.
-
Hello @4u123, Using Addon domains (which have their own virtual hosts) instead of Aliases is the best "workaround" for the issue you have described. However, your concern is understandable, especially since you noted a desire to avoid the need to increase the number of addon domains allowed per account. I recommend sharing this feedback as a feature request via our 0 -
A feature request is not appropriate here, simply because this issue affects the basic functionality of your platform. It's something you should have discussed internally and already found a solution for - and already implemented! The fact is that parked domains (aliases) have become completely defunct because they don't work with https - and this affects our customers right now. Why haven't you anticipated this issue and done something about it? It's cpanels job to find a solution that allows the end user to redirect domains, retaining the functionality of aliases and ensuring that visitors won't receive errors in the browser. You need to keep up with the development of your product and find solutions before these issues arise. I'm sure there are a number of ways you can achieve this - but it is certainly not the responsibility of your customers to suggest ways in which you do that. I don't work for you. 0 -
What is the status of this problem? I privately manage 100s of domains names with their web sites and FTP access. I want them all to be only accessible through https and FTPS. This seems to be a very common and legitimate request that should be a cPannel protection option. If this is not feasible I will have to find or make designed an alternative, quit cPannel, and change hosting provider. I am certainly not alone in that situation. There is therefore a certain urgency in addressing this. Unless you consider this an RFC usersbug to address with the ietf-http-wg? 0 -
There shouldn't be any issue adding an SSL to an alias domain, as long as it's listed as a SAN in the certificate - AutoSSL successfully issues SSLs to parked/alias domains and you can easily force HTTPS through the Domains interface within cPanel Furthermore, there's no reason why you can't use FTPS or SFTP along with requiring HTTPS. 0 -
Well, this is kick in the pants. We have over 50 domains with just an .htaccess file to redirect to the main site to avoid SSL issues . As you may be aware, cPanel modified its licensing terms at the beginning of this year. The new licensing tiers have led to its largest price increase ever. Previously each cPanel license included an unlimited number of "user accounts". Under the new licensing model cPanel is limiting the number of included user accounts per license type, which increases the cost for any customer with more than five (5) user accounts.0 -
Well, this is kick in the pants. We have over 50 domains with just an .htaccess file to redirect to the main site to avoid SSL issues .
As you may be aware, cPanel modified its licensing terms at the beginning of this year. The new licensing tiers have led to its largest price increase ever. Previously each cPanel license included an unlimited number of "user accounts". Under the new licensing model cPanel is limiting the number of included user accounts per license type, which increases the cost for any customer with more than five (5) user accounts.
I'm not sure what relevance your comment has to this thread. cpanel licensing works on a "per account" basis - not a "per domain" basis - and how does licensing come into the issue of aliases not working with https?0 -
If we were using an alias on a domain with SSL, the browser would throw an insecure message. The workaround was to give the domain it's own hosting and redirect any needed area. We asked the data center how many cPanel accounts we have (not domains) and they reported the exact match to the number domains we have hosted on the server. I think that they are confused too but to make sure we don't see the server get shutdown over a payment issue, we are switching over to add-on domains. That seems much better and with AutoSSL, shows no warnings. The only thing to do is keep an eye on the domain registration as if it goes down, it will take out the add-on sites. Thanks for your feedback and keep safe. 0 -
You need to use addon domains instead of domain aliases. I've detailed this before, I'm sure it's in a post some where on this forum. Domain Aliases (parked domains) worked fine way back when SSL/TLS was not as big of a thing. Just keep slapping domains to the ServerAlias directive in a VirtualHost and the world was great. But when SSL/TLS started to become a big thing, this notion lost it's usefulness. Adding (or deleting) a domain name to the ServerAlias directive means that you had to re-issue a secure certificate to now include ALL of the domain names in the ServerAlias (and ServerName) directives. Add a domain alias... reissue the full certificate... wait 3 days... add a new domain alias... reissue the full certificate. The way around this is to use Addon domains. Addon domains (or parked domains on top of a subdomain) have their own VirtualHost. Nothing stops you from reusing an already used path as the DocumentRoot. So you you can have [plain]example.tld[/plain] as the main domain with a DocumentRoot of [font="courier new">/home/example/public_html and then add an addom domain - [plain]addonexample1.tld[/plain] and set it's DocumentRoot to [font="courier new">/home/example/public_html and a new VirtualHost will be created. Add another addon domain [plain]addonexample2.tld[/plain] with a DocumentRoot of [font="courier new">/home/example/public_html and a new VirtualHost will be created. Now each of these VirtualHosts (can) have their own independent TLS certificate issued. In your's truly's humble opinion - the current Domain Alias (appending an ever growing list of domains to the ServerAlias) needs to be stopped. Everything needs to be addon domains. Every domain - whether it's a real account, an addon domain, a subdomain, or just a domain name that mirrors other content (reuses a DocumentRoot) - needs it's own VirtualHost. The ServerAlias directive should be restricted to it's more intended use, to clone common hostnames related to the domain name (ServerName), i.e. [plain]www.example.tld[/plain], [plain]mail.example.tld[/plain], etc. 0
Please sign in to leave a comment.
Comments
8 comments