[CPANEL-22039] AutoSSL doesn't cover Service Subdomains when parent domain uses third-party cert

[BlueSteam]

I refer you to an older thread (1 year old)

Paid SSL on Domain, Free AutoSSL on Subdomains?

I needed a paid SSL certificate installed for my clients www entry and the client wanted to use AUTOSSL for the service subdomains such as cpanel, webmail etc. because the client didn't want to shell out the money for a wildcard certificate.

So according to a private ticket with cPanel, this is no longer possible. It was just a year ago that this was possible but not anymore apparently. So for those of you who need this done, you need to know its not possible and cPanel is not going to find a way to make it possible unless everyone shouts loud enough.

Thus, You cannot run a Paid SSL alongside the free AUTOSSL feature with the service proxy subdomains (cpanel, webmail, mail etc)

If ANYONE has a solution to this OBVIOUS problem that I'm sure I am not the only one who is experiencing this issue, PLEASE do share!

cPanels reply on this topic.

--------------------------------------------
There have been significant changes in the way we handled SSL certificates. Originally, we did have separate VirtualHosts created for some but not all of the service subdomains (FKA proxy subdomains).

Back then, it was possible to assign a different IP and different SSLs for each. But this also caused a huge strain on the servers (at Let's Encrypt and Comodo) and our developers had to approach this in a different way.

Some of those changes involved only generating an SSL for certain service subdomains based on certain account settings.
For example, we used to order SSL's for whm.domainname.tld each time, but now only do so if the account in question is a reseller. Additionally, we no longer request them for Autodiscover (unless Autodiscover is enabled at the time).

The other changes involved included placing all service subdomains as ServerAliases (instead of ServerName) and that also prevents different IP addresses now for service subdomains, aliased or addon domains.

It is simply no longer possible to do that via WHM. There is possibly a way to do this manually with making changes to some files, but this is not supported and would have to be redone every 3 months when a new AutoSSL is generated for the service subdomains. If you feel that a feature like this is beneficial, I encourage you to file a feature request at https://features.cpanel.net. Our developers love feature requests and this is the place to begin a discussion with them as well as other users who might be interested in this.
--------------------------------------------

 

[cPanelMichael]

Hello @BlueSteam,

Here's an update from one of our Technical Analysts to the support ticket you opened noting a potential workaround:

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.

 

[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 .

 

[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 feature request and post the link here once it's opened? I can start linking the request when I see similar requests in an effort to demonstrate community demand for the functionality.

Thank you.

 

[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!!

 

[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.

 

[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.

 

[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 mail.example.tld without interfering with the certificate for example.tld.


When you create an example.tld web hosting account, the system creates an Apache VirtualHost:

ServerName example.tld
ServerAlias www.example.tld mail.example.tld

Now when you purchase a secure certificate - probably that is only going to be valid for example.tld and www.example.tld - meaning mail.example.tld is left out to dry.

By creating a mail.example.tld subdomain from within the account's cPanel - this modifies the above Apache VirtualHost to:

ServerName example.tld
ServerAlias www.example.tld

And creates a new VirtualHost:

ServerName mail.example.tld
ServerAlias www.mail.example.tld


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.

 

[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

 

[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 http://example.tld/proxy-cpanel redirects to https://cpanel.theserver.tld. 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 http://cpanel.example.tld redirects to https://cpanel.theserver.tld.

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.

 

[BlueSteam]

Yh, not really a solution but thanks

 

[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.

 

[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.