Skip to main content
We are aware of an issue after updating to cPanel versions 11.110.0.65, 11.126.0.21, or 11.128.0.11, some cPanel plugins or features are no longer functioning properly including WP Toolkit. Please see the following article for more information and updates:
Update to latest cPanel 110, 126, or 128 versions removes "addonfeatures" directory.

Comments

12 comments

  • cPanelMichael
    Hello @BlueSteam, Here's an update from one of our Technical Analysts to the support ticket you opened noting a potential workaround: [QUOTE] First, you would need to go into WHM >> Tweak Settings and ensure Service subdomain override is set to "On". Then you would need to create the service subdomains you want to create (IE: cpanel.domain.tld or webmail.domain.tld) as individual subdomains via "cPanel >> Subdomains" and redirect them to their proper ports. (2083, 2096). This will create new and separate entries in the httpd.conf file for those service subdomains. Then, install the new third-party SSL certificate on the main domain and allow AutoSSL to install the rest.
    Can you let me know if this workaround was helpful? If so, I'll update the other thread you referenced with the updated workaround instructions. Thank you.
    0
  • BlueSteam
    While your workaround will allow you to install separate free SSL certificates for the service subdomains, it now breaks the access to the cpanel and webmail interfaces from behind a firewall which is primarily what the service sub domains are meant for. Redirecting them now to the ports, blocks the access from behind a firewall. So no, the workaround doesn't work .
    0
  • cPanelMichael
    Hello @BlueSteam, A feature request is best approach going forward if you'd like to see a path to supporting this directly in the product. Can you open a
    0
  • BlueSteam
    We shouldn't have to put in a feature request for something that was always there and taken away. Thats like giving someone a steering wheel in a car and then taking it away and asking them to justify why they need it!!
    0
  • cPanelMichael
    Hi @BlueSteam, While it may have been possible to workaround the issue in the past, it's not supported because Service Subdomains are setup as part of ServerAlias entries in the parent domain's virtual host within the Apache configuration file (as opposed to separate virtual hosts the way standard subdomains are setup). One avenue to explore is the use of the commercial SSL certificate on the parent domain. Is there a particular need that's addressed through the commercial SSL certificate as opposed to using AutoSSL to secure the parent domain? Thank you.
    0
  • BlueSteam
    In the past when it was working, it was never a workaround. We simply disabled AutoSSL from updating the certificate for the www record. I would not call that a workaround. They removed it because they said it was affecting the performance but then they should have implemented it differently instead of completely removing the ability to do it. Now that they have removed it, we have to ask for it as a feature??? Go figure! To answer your question about why wew want it is simple. Websites are public facing. Email is not. Most, if not all clients, feel more at ease with a paid SSL for their website rather than a free oone. Most clients don't want a paid one for their mail. Don't ask me why but that's the feedback I have had from my clients when I've been trying to sell them a wildcard SSL.
    0
  • sparek-3
    I know for the mail subdomain - which automatically gets created within the domain name's VirtualHost entry - you can setup a mail subdomain - which will create it's own VirtualHost entry. And that allows you to create a Let's Encrypt or other certificate just for [plain]mail.example.tld[/plain] without interfering with the certificate for [plain]example.tld[/plain]. When you create an [plain]example.tld[/plain] web hosting account, the system creates an Apache VirtualHost: ServerName [plain]example.tld[/plain] ServerAlias [plain]www.example.tld[/plain] [plain]mail.example.tld[/plain] Now when you purchase a secure certificate - probably that is only going to be valid for [plain]example.tld[/plain] and [plain]www.example.tld[/plain] - meaning mail.example.tld is left out to dry. By creating a [plain]mail.example.tld[/plain] subdomain from within the account's cPanel - this modifies the above Apache VirtualHost to: ServerName [plain]example.tld[/plain] ServerAlias [plain]www.example.tld[/plain] And creates a new VirtualHost: ServerName [plain]mail.example.tld[/plain] ServerAlias [plain]www.mail.example.tld[/plain] Now, does this work with cPanel service subdomains? I don't know. But might be worth a try. The broader scope of this is trying to shove everything under one VirtualHost. This worked fine before HTTPS and the prevelance of SSL every where for everything, because the need to verify and tie VirtualHosts to a certificate did not exist. But now, I'm not sure if it's the right move. Just about everything should be in it's own VirtualHost. Service subdomains, mail subdomain, parked domains (domain aliases), etc, should all be in their own VirtualHost so that certificates can be issued independently.
    0
  • BlueSteam
    No it doesn't work with service subdomains . That's why you have to enable that setting mentioned in the second reply of this post called "Service subdomain override".
    Service subdomains, mail subdomain, parked domains (domain aliases), etc, should all be in their own VirtualHost so that certificates can be issued independently.

    I couldn't agree with this more!!! Regarding the fact that when purchasing SSL certificates mail sub domain is left out to dry? This is the reason why the clients don't want to pay for a wildcard certificate just to secure their service subdomains because they feel they should not have to spend more money because of this oversight from cpanel so they opt for AutoSSL to secure them but that breaks the paid SSL for their www. So to get around it you have to now enable the setting mentioned above and then go and create manual subdomains and then more redirects to the correct ports just to get it working but then you aren't able to access cpanel or webmail from behind a firewall which negates the entire reason for the service subdomains completely . So cpanel broke it and now they want us to open a feature request to fix it . /facepalm
    0
  • sparek-3
    Not really a solution to this issue - but what I did - and I did this before service subdomains were a thing in cPanel, was to create a set of service subdomains based on the server's hostname (or just pick a domain name you have control of on the server) and then setup redirects such that [plain]http://example.tld/proxy-cpanel[/plain] redirects to [plainhttps://cpanel.theserver.tld[/plain]. This negates the need for every domain name to have their own secure certificate for the service subdomains and every account can access their cPanel, WHM, Webmail, etc through a (relatively) easy URL to remember. You could probably do something similiar such that [plain]http://cpanel.example.tld[/plain] redirects to [plainhttps://cpanel.theserver.tld[/plain]. Again, this isn't really a solution to this initial question per se... unless you look at this from a different perspective and realize that having service subdomains for every domain name hosted on the server is probably overkill.
    0
  • BlueSteam
    Yh, not really a solution but thanks
    0
  • cPanelMichael
    Hello @BlueSteam, Thank you for providing us with additional feedback. An internal case (CPANEL-22039) was opened to report this behavior. I've added a link to this forums thread to the case, and I'll provide updates here as they become available. In the meantime, there is an existing feature request that corresponds to this issue at: AutoSSL: Enable separately for mail or website. It only notes the "mail" subdomain, but the concept would apply to any service subdomain. I encourage anyone seeking this functionality to vote for the request, as it helps demonstrate the demand for a feature to Development. Thank you.
    0
  • cPanelLauren
    This internal case was closed due to the fact that implementing this would require each host has only one name and no aliases, not only would this not scale well but it's not really realistic with Apache.
    0

Please sign in to leave a comment.