Problem with automatically generated self-signed SSL certificates

cPanelNick

Administrator
Staff member
Mar 9, 2015
3,488
35
208
cPanel Access Level
DataCenter Provider
One of the other approaches we considered to solve this problem was a default SSL Vhost per ip (at the top of httpd.conf).

Unfortunately, there were downsides that were deemed unacceptable to proceed with this plan:
Uses additional memory per IP address
Will break existing set primary ssl domain functionality.
non-SNI users will now get the default vhost instead of the primary

Adding default ssl vhost per ip would disproportionally affect existing users. SNI adoption has not yet reached a level were we feel comfortable accepting the downsides.

The always create an SSL host approach was adopted because we felt it carried the least risk to existing customers and solved the problem.
 

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,909
2,222
463
Hello,

To update, an option to disable the automatic self-signed certificate generation is planned for cPanel version 64. It's not yet determined if the feature will backport to cPanel 62, however feel free to subscribe to the request to receive updates to it's status:

Disable Automatic self-signed SSL

Thank you.

Update from the feature request:

Quick Update: We have completed most of the initial work for this option, however we do not have a test case that was not solved by enabling AutoSSL. If this functionality is important to you, please open a ticket at cPanel Customer Portal with information about how this request affects you. Please be sure to ask for it to be linked to CPANEL-11589.

Thank you.
 
Last edited:

sparek-3

Well-Known Member
Aug 10, 2002
2,019
225
368
cPanel Access Level
Root Administrator
I'm posting this question here because it's not really related to the Feature Request. It's probably not really related to any of this discussion, but in the text of the proposed Setting on the Feature Request I just have some questions.

Is Google (and/or any other search engine) going to start crawling HTTPS sites automatically? I mean, if I have a website - example.tld - and I only reference that website every where as http://example.tld - is Google going to automatically start trying to access and index https://example.tld?

I know that Google wants to start weighing secure sites more than non-secure sites. And I get that. But is all of this push to have every single website have their own secure certificate predicated on Google and other search engines just completely ignoring non secure links? If so, that's just dumb on Google's part.

As far as wanting my site to show without warnings when I go to https://example.tld I really need to ask myself, have I installed a secure certificate for example.tld? If that answer is no... then... to expect https://example.tld to work, that's ... not smart. Perhaps I need to educate myself on how to get a secure certificate for my example.tld site.

I've had clients ask before "When I go to https://example.tld I don't see my website." When I ask them if they have purchased a secure certificate, and they reply no, I tell them that is what the problem is. They can either purchase a secure certificate or don't try to go to https://example.tld - it's pretty simple.

With free DCV certificates and AutoSSL, the response can be just as simple as "Have you applied for a secure certificate in your cPanel?" When they reply no, then that's what they then need to do.

I'm a bit more in favor of educating users, rather than just perpetuating stupidity. Explaining why a client needs to do something, rather than just having it done for them.

I'm sorry, but all of this massive move to https just seems like it has all been hurried and lacks a lot of foresight. I'm not necessarily talking about just cPanel, but I'm also talking about Google and all of these other industry giants. They want everything secure, but they haven't thought about how to do it.
 
  • Like
Reactions: vacancy

vacancy

Well-Known Member
Sep 20, 2012
458
159
93
Turkey
cPanel Access Level
Root Administrator
I agree.

As a google search engine, is monopoly and trying to manage the whole ecosystem as it wants. The technical issues behind this work are not in google's mind.

It is also a big lie that sites using ssl are advantage compared to sites not using ssl. A site using ssl can not be 100% safe. There is no sense in using ssl in a blog or news site.

When you activate ssl on a phishing site, will google up this site from the front row?

So funny.
 

sparek-3

Well-Known Member
Aug 10, 2002
2,019
225
368
cPanel Access Level
Root Administrator
Well, I agree that the web should be more secure. I don't question that. I'm not sure that "every website should have its own secure certificate" is the best way to approach this.

As far as Google goes - I don't have a problem with them wanting to rank secure sites higher than their non-secure counterparts. But that should be viewed as an incentive for website owners to take the step and be proactive in obtaining a secure certificate and keeping that secure certificate valid. If a website owner is not willing to invest the time needed to do that, then how much are they really investing in their website? And how much weight should Google (or any search engine) put into ranking that website?

What I have an issue with is if Google believes that every website should just be accessible at https://example.tld and they just start trying to index https versions of every domain. That's just dumb. I don't believe Google can be that dumb. If Google wants to weigh example.tld lower because it doesn't have a secure certificate, that's fine by me. But don't go around thinking they can "fix" it by just assuming http://example.tld and https://example.tld are the same.

The point about phishing sites is also valid. Although it was just as valid with any purchased DCV certificate before free DCV and Let's Encrypt came along. Pretty much anybody could get a DCV certificate for about $10. But this is where the industry is lacking foresight. If every website on the Internet has a secure certificate, then all non-EV certificates are equal in terms of authenticity. The encryption is still there, but authenticity is gone (but to be honest, it was never there for any DCV certificate). But if the end-goal is to focus on the encryption aspect... why not focus on something like STARTTLS for HTTP? Again, that's not in the realm for cPanel. But if the industry wants all web traffic to be encrypted, then is "every website should have its own secure certificate" the best approach? Was this thought out by the industry?
 

feanorknd

Member
Sep 28, 2005
21
1
153
As someone said at feature request:

I think the best solution would be to make this an option, worded something like:

For every new VirtualHost (new account, subdomain, addon domain, parked domain) create:

- A self-signed certificate

- A free AutoSSL (cPanel Comodo or Let's Encrypt)

- No certificate

This is a must! I do not want any kind of certificate on my shared IP, for any domain there.


  • Do not want all domains to have SSL enabled (reason could be paid services, as well as duplicated content for many domains)
  • If only one of the domains have SSL enabled at shared IP, its certificate may apply to all of the rest when trying https... I want Apache to not negociate HTTPS on my shared IP at all.
 

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,909
2,222
463
Hello Everyone!

Here's the most recent update from the feature request:

Quick Update: We have completed most of the initial work for this option, however we do not have a test case that was not solved by enabling AutoSSL. If this functionality is important to you, please open a ticket at cPanel Customer Portal with information about how this request affects you. Please be sure to ask for it to be linked to CPANEL-11589.
If you have a scenario that isn't solved with the use of the AutoSSL feature (free cPanel-signed SSL certificates), then please open a support ticket with the URL above and reference case CPANEL-11589.

If only one of the domains have SSL enabled at shared IP, its certificate may apply to all of the rest when trying https... I want Apache to not negociate HTTPS on my shared IP at all.
This would be solved by ensuring every domain name had it's own free cPanel-signed certificate through the AutoSSL feature.

Thank you.
 

hinhthoi

Member
Mar 28, 2017
18
2
3
Vietnam
cPanel Access Level
Root Administrator
A majority of customers from a company that I know are SEO users. These users have concern about http and https of the same content. I encounter one customer very frustrated about the https version on his site and he keep questioning about that. So, please do not force people to use ssl. It is best to make it a configurable option for use to choose.

On the other site, right now Letsencrypt is free. If so many sites are using Letsencrypt, suddenly the company stop their free service, then how? There will be a massive problem for webmasters.
 

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,909
2,222
463
Is there some news when the option will be pushed to public?
This feature is not currently planned for inclusion with the product. You can find the most recent discussion of this on the corresponding feature request:

Disable Automatic self-signed SSL

If you have a scenario that isn't solved with the use of the AutoSSL feature (free cPanel-signed SSL certificates), then please open a support ticket using the link in my signature and reference case CPANEL-11589 so we can determine how to best address the specific issue you are facing.

Thank you.
 

sparek-3

Well-Known Member
Aug 10, 2002
2,019
225
368
cPanel Access Level
Root Administrator
This feature is not currently planned for inclusion with the product.
I really think this is a mistake. I really don't think cPanel has thought this all the way through.

I can probably make this work if self-signed certificates are generated by default. But as I understand it (and I may be wrong) if you enable AutoSSL, then all new VirtualHosts are going to get a cPanel or Let's Encrypt signed certificate.

I don't understand why you insist on making AutoSSL automatic for everyone.

Why not make AutoSSL something that the end-user has to explicitly enable? Why not give server administrators control over who can and cannot have access to AutoSSL?

If you insist on every VirtualHost having a secure certificate (which I don't agree with) then they should default to self-signed certificates (which I can bargain with you on this). THEN if that new account or new subdomain or new addon domain wants to get a cPanel or Let's Encrypt certificate AND if the server administrator has enabled it for that user, then that user can log into their cPanel and process a cPanel or Let's Encrypt certificate.

There's obviously pushback from several people regarding this current AutoSSL setup. So you either didn't think this all the way through, didn't get enough feedback before pushing it out, or didn't get enough feedback from different types of hosting companies. All of these complaints, aren't centered so much around AutoSSL but just the fact that it's being forced onto us.

As it stands now, the only way I see for me to use this is to disable AutoSSL. This will still generate a self-signed certificate for each new VirtualHost. but I can probably work around this. We developed our own system for issuing Let's Encrypt certificates, and automatically renewing them, long before cPanel's AutoSSL came to be. I prefer our system, mainly because I can control who can generate certificates with this system. This works for me. It may not work for everyone. But the lack of control with AutoSSL (it's either on or it's off) is what's most disturbing for me as a server administrator and cPanel's insistence on pushing this out is another disturbing factor.
 

ffeingol

Well-Known Member
PartnerNOC
Nov 9, 2001
617
199
343
cPanel Access Level
DataCenter Provider
While I understand the desire for all web traffic to be SSL (with Google pushing hard on this) it causes a lot of real world problems. The biggest issue that we run into are customers that have not coded their sites correctly and end up with mixed/insecure content warnings on their site. This currently is easily manageable as we don't allow customers to enable SSL on their site (we do it for them). That way we can give them a 'heads up' before they run into the issue.

As cPanel is now automagically generating the self signed certificates (or we can use AutoSSL to get signed ones) we literally have no way to warn clients (other than a mass mailing to all hosting clients). That is literally going to cause 100's and 100's of support tickets to be opened (why did we do this, how do they fix it, etc. etc.).

The fact that we simply have no way to control the roll out of this is the biggest issue.
 

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,909
2,222
463
Hello,

cPanel version 66 (currently available as a development build in the "EDGE" build tier) includes the following option under the "Security" tab in "WHM >> Tweak Settings":

Generate a self signed SSL certificate if a CA signed certificate is not available when setting up new domains.

Per it's description:

When you create a new domain, cPanel will apply the best available certificate (CA signed); otherwise cPanel will apply a self-signed SSL certificate and request a new certificate via AutoSSL if it is enabled. Warning: If you disable this option, and a CA signed certificate is not available, when a user attempts to visit the newly created domain over https, the user will see the first SSL certificate installed on that IP address. Warning: If you enable this option and do not have a CA signed certificate or AutoSSL enabled, Google search results may point to the SSL version of the site with a self-signed certificate, which will generate warnings in the users’ browser. To avoid both of these concerns, we strongly recommend that you enable AutoSSL.

Thank you.
 

sparek-3

Well-Known Member
Aug 10, 2002
2,019
225
368
cPanel Access Level
Root Administrator
Warning: If you enable this option and do not have a CA signed certificate or AutoSSL enabled, Google search results may point to the SSL version of the site with a self-signed certificate, which will generate warnings in the users’ browser.
This may be a bit off your pay grade, but is Google actually doing this? Is Google actually going around "Ah! I see example.tld... let me try indexing https://example.tld... Woops! self-signed! BAD! example.tld ranking lowered!" Or "certificate name and hostname mismatch! ranking lowered!"

That's not really cPanel's problem. If Google is doing that, then that's just stupid. Now if Googlebot finds example1.tld and example2.tld that are both generally on the same topic, if example2.tld is accessible by HTTPS and example1.tld isn't, then I have no problem with them ranking example2.tld higher than example1.tld. But to just blatantly expect all domains to be accessible via HTTPS, that is just stupid.

This whole push to move everything to HTTPS was not well thought out. I'm not talking about cPanel, I'm talking about the industry as a whole.
 

4u123

Well-Known Member
PartnerNOC
Jan 2, 2006
938
21
168
While I understand the desire for all web traffic to be SSL (with Google pushing hard on this) it causes a lot of real world problems. The biggest issue that we run into are customers that have not coded their sites correctly and end up with mixed/insecure content warnings on their site. This currently is easily manageable as we don't allow customers to enable SSL on their site (we do it for them). That way we can give them a 'heads up' before they run into the issue.

As cPanel is now automagically generating the self signed certificates (or we can use AutoSSL to get signed ones) we literally have no way to warn clients (other than a mass mailing to all hosting clients). That is literally going to cause 100's and 100's of support tickets to be opened (why did we do this, how do they fix it, etc. etc.).

The fact that we simply have no way to control the roll out of this is the biggest issue.
The above is a very important point. Simply installing an SSL certificate on a domain (or in the case of AutoSSL, all domains and subdomains in an account) is only a very small part of making a website SSL enabled. For the end user there is often confusion and a lot of extra work required which in many cases they are not qualified to carry out. So there is a great deal of intervention required here to talk them through the changes and to assist them.

cpanel constantly and repeatedly fail to understand this industry from the end user's perspective and this problem is a prime example of that failure.

I would also like to say that self-signed certificates are a complete waste of time. They do nothing other than cause annoyance.

It's also important to point out that SSL doesn't make the web "more secure". It doesn't make websites "more secure" at all. This myth is another thing that causes problems for the end user because many people are under the assumption that having an SSL certificate on their website will prevent it from being hacked - which of course it can't. This makes the end user complacent and less likely to keep on top of web application updates.

All HTTPS is doing by encrypting the communication between the browser and the server, is protecting any sensitive data being submitted by the site visitor - but even then, this is only a risk if the data is being intercepted - which hardly ever happens anyway. When you consider that most websites don't take any card payments or personal data from their visitors, or even have forms that can be filled out - it's plainly obvious that there is simply no need to have every website covered by encryption.

I think cpanel is yet another company who has jumped on this bandwagon just because Google thinks it is a good idea.
 

sparek-3

Well-Known Member
Aug 10, 2002
2,019
225
368
cPanel Access Level
Root Administrator
I'm not going to fault cPanel on this too much. In my opinion this is more of an industry issue, a lack of foresight that the industry did not or is not paying attention to. You could argue that cPanel is being played on this, but that's about as far as I will go.

The industry as a whole does not understand the scope of what they are asking. They don't understand all of the redirects that websites will have that will prevent automated SSL validation, or the fact that website owners do not know how to redirect traffic to the encrypted HTTPS site, or the fact that many shared hosting servers have many different VirtualHosts that do not resolve back to that server, or that end users may create hundreds of subdomains that create additional secure certificates.

And, as you say, encryption is mostly unnecessary. The last time I checked, the web was public, meaning that you can go to http://www.cpanel.com see a website and I can go to http://www.cpanel.com and see the same website. Who cares if it's encrypted. If someone wants to waste their time by sniffing packets on a connection when they can just as easily go to the website themselves, then more power to them.

Now, when you start talking about WordPress logins or really any where where you have to submit something, that's usually desired to be confidential and encryption would be important here.

But this is also where you have to break down secure certificates into the roles that they play. A secure certificate is intended to provide encryption so that anyone listening on the connection would not be able to see the data passing between server and client, i.e. encrypting a WordPress login submission. Secure certificates are also expected to provide some level of authenticity, so that the website you are submitting the data to is really the associated organization that you want to submit the data to.

This tying of encryption to authenticity is where the absurdity begins. Authenticity only plays a role when you are submitting something and you need to be sure that the organization is real and that you are submitting it to the real organization. Authenticity mainly plays a role when you are submitting credit card information to pay for something. You want to be sure that Amazon is a real company and that you are submitting your credit card information to Amazon, when you buy something from Amazon. For Average Joe's Cat GIF blog, who exactly is going to be logging into the WordPress blog? Does that user really need to be sure that Average Joe is a real person/organization?

When you start thinking of secure certificates in terms of their roles, you can see the disconnect that there is.

Domain Control Validated certificates (like Let's Encrypt, PositiveSSL, RapidSSL) do absolutely nothing for authenticity. "Oh, congratulations, you really do own the domain name that you requested this certificate for."

In terms of authenticity, a DCV certificate and a self-signed certificate offer the same thing. The only advantage a DCV certificate might have over a self-signed certificate is to guard against Man in the Middle attacks. But could measures have been taken to verify the authenticity of a self-signed certificate? Perhaps by using a DNS key (much the same way that DKIM works)?

If all you are after is encryption, then why can't there be a way for individuals (or individual administrators) to provide this? Why do we have to involve a 3rd party like Let's Encrypt and Comodo? The more parties you involve in something, the more likely there are to be screw ups along the way.

Now, if you are a business, organization, or person that is accepting payment information or needs to otherwise prove to your visitors that you are real and you are who you say you are, then Extended Validation is the answer. All secure certificates that you pay money for, should be EV certificates, and should have always been EV certificates. This is because you are involving a third-party to verify that you are who you say you are, much like an escrow payment.

Secure web basically breaks down as:

1) Encryption only

and

2) Encryption and Authenticity

Most website owners aren't worried about authenticity. So why can't a better solution for Encryption only be found? Something that the end user has control over. Keep in mind, when email is passed from one SMTP server to another using TLS, authenticity doesn't play a role. Encryption is all the connection is after.

I'm more of a proponent of self-signed certificates, because they can be generated without the intervention of any 3rd party and can be generated at any time. Although I will admit that they are subject to MITM attacks. But instead of just discarding them like all the major browser players did several years ago, why not investigate how to solve this a bit more? If not a DNS DKIM-like signature verification method then perhaps something based on the notary-model? Or why not just a small warning in browsers when an unexpected secure certificate is found, such as when a new self-signed certificate is generated?

I just think there has to be a better way to offer Encryption Only secure certificates. Something that doesn't have to involve a 3rd party to sign all certificates. All of that signing and automation is bound to cause problems. What good does it do to verify that you own a domain name before issuing the certificate?

Google is dead set against EV certificates and I think a lot of people get EV certificates that don't need one. But EV certificates do have a place, and in fact should be the only type of certificate that is being sold. And if Google is insisting that every website have their own secure certificate, then I think they need to rethink that strategy.

Ultimately the issue boils down to end-user knowledge. Not knowing what they need or the refusal to learn about what they need, or perhaps not enough people willing to teach them to understand what they need.

A self-signed certificate for a WordPress admin dashboard will work for most everyone, if they understand what that involves. The first time you go to it in any browser, your browser is going to warn you (browser developers could do something about the apocalyptic message they present), it's OK to accept it if you just had the self-signed certificate installed. Then if you ever get another message about the certificate being unrecognized in that browser, then you may be in a MITM attack. The only people that need to access the secure version of the site are those individuals that access the admin dashboard - not the general public. But instead of teaching this, the industry determined that any 1 self-signed certificate could be subject to MITM attacks so ALL self-signed certificates are bad. It's easier to just tell people that they are bad than to teach them why they might be bad. Users want to be able to just click a button and then be safe, never worrying about the underlying why's.
 

4u123

Well-Known Member
PartnerNOC
Jan 2, 2006
938
21
168
You make some very valid points sparek-3.

I think cpanel are due some criticism. It is often the case that they will force new features onto us without providing any option to disable them. This happens with almost every feature they add to their product. Often they are not considerate of the end user, or the bigger picture and have a very narrow focus. Why won't they learn to add something and disable it by default so we can choose whether or not we want to use it?

Going back to the SSL issue. One thing that really bugs me is cpanel's insistence on messing with the clients' .htaccess files - and copying files into the publicly accessible areas of their web space. These things are wholly inappropriate and again they don't take into consideration the way in which a customer might have configured their website.

cpanel should never add files, or make any changes to any files within public_html or addon domain directories. Period.

Often is the case that AutoSSL can't validate a domain because of pre-existing .htaccess directives preventing this process. More headaches for us. I'm sure there are plenty of other ways to do this.

It's the same for the multi PHP implementation in EA4 - setting PHP versions in .htaccess - a really dumb and lazy thing to do. CloudLinux handles this so much better.
 

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,909
2,222
463
Often is the case that AutoSSL can't validate a domain because of pre-existing .htaccess directives preventing this process. More headaches for us. I'm sure there are plenty of other ways to do this.
Hi @4u123,

For this particular issue, the following option under the "Domains" tab in "WHM >> Tweak Settings" is enabled by default starting in cPanel version 66:

Use a Global DCV Passthrough instead of .htaccess modification (requires EA4)

Here's the description for this option:

When you enable this option, Apache adds global rewrite rules to the webserver configuration so that the system does not process additional rewrite rules for DCV filenames. These global rules make it unnecessary for cPanel & WHM to modify each virtual host’s .htaccess file. Note: When you enable this option, the system receives a trivial performance penalty because all of the HTTP requests must be matched against the DCV filename regular expressions.

Thank you.