Skip to main content

Problem with automatically generated self-signed SSL certificates

raven_kg
Hello, Last night our cPanel instance was updated to 62.0 (build 8) and now it creates self-assigned SSL certificate for each new addon domain. How can I completely disable this feature? Thank you

Comments

37 comments

Date Votes
  • ffeingol
    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.
    0
  • cPanelMichael
    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.
    0
  • sparek-3
    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
    0
  • 4u123
    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.
    0
  • sparek-3
    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 [plain]http://www.cpanel.com[/plain] see a website and I can go to [plain]http://www.cpanel.com[/plain] 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.
    0
  • 4u123
    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.
    0
  • cPanelMichael
    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.
    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post