Web Hosting Forum | Lunarpages

Advanced Lunarpages Assistance => Web Site Management => Topic started by: scanman20 on February 19, 2016, 06:49:06 AM

Title: Let's Encrypt
Post by: scanman20 on February 19, 2016, 06:49:06 AM
Is LP planning to offer this free service? Other hosts have already implemented it, so I'd expect to follow suit.

For those unfamiliar with Let's Encrypt (https://letsencrypt.org/) (https://letsencrypt.org/):

Letís Encrypt is a free, automated, and open certificate authority (CA), run for the publicís benefit. Letís Encrypt is a service provided by the Internet Security Research Group (ISRG).

The key principles behind Letís Encrypt are:
Title: Re: Let's Encrypt
Post by: MrPhil on February 20, 2016, 02:32:38 PM
Does this require or allow SNI (Server Name Indication)? That is a shared IP address for private certs; http://forums.oscommerce.com/topic/409069-server-name-indication/ . Anyone know what LP's position is on this for Basic plans (Linux shared server)? It would be nice not to have to pay for a dedicated IP address, and to use a low cost or free SSL certificate for a low-volume ecommerce site.
Title: Re: Let's Encrypt
Post by: scanman20 on February 22, 2016, 07:53:29 AM
According to https://groups.google.com/a/letsencrypt.org/forum/#!topic/client-dev/hB4RDKz53Zk and http://security.stackexchange.com/questions/78849/will-lets-encrypt-require-sni-from-the-operators yes.
Title: Re: Let's Encrypt
Post by: MrPhil on February 22, 2016, 12:55:59 PM
My browser tells me there is no groups.lunarpages.com. Could you check that first URL?
Title: Re: Let's Encrypt
Post by: scanman20 on February 23, 2016, 07:25:46 AM
lol that's not the link I posted. The forum changed it! Substitute google for lunarpages in that link. What kind of stupid filter is this?

Title: Re: Let's Encrypt
Post by: MrPhil on November 20, 2016, 09:14:44 AM
So, what choices does a Lunarpages customer have if they want to enable SSL on their site? I am considering opening a store on my site, which will require SSL (HTTPS) on at least some of its pages (ones carrying sensitive information). Also, Google is starting to downrank HTTP sites in favor of HTTPS sites (not just pages), so in the long run it's good to have a site completely HTTPS.

For a long time, LP has offered static IP addresses and commercial private SSL certificates, which may be a bit on the expensive side for small shops. They also offer shared SSL certificates for free, but the domain used will not match the rest of your site, which can put off a lot of customers. Do shared certificates still not work with PHP? I don't expect LP to offer private SSL certificates for free, since there is a cost associated with them, but what can they offer us that's fairly low cost? Dedicated IPv4 addresses are also going to get quite expensive, so some method that allows sharing or virtual IP addresses would be very good.

Don't forget that SSL comes in different encryption strengths (e.g., 128, 256, 1024 bit), and some financial (payment) services may require fairly strong encryption (now or in the future).

http://wiki.lunarpages.com/Adding_Features/SSL
http://wiki.lunarpages.com/Additional_Dedicated_Hosting_Features/Dedicated_Linux_SSL_Certificate
http://wiki.lunarpages.com/SSL_Renewal_is_not_automatic
Title: Re: Let's Encrypt
Post by: MichaelT on November 20, 2016, 11:52:19 PM
At this time, Letís Encrypt certificate are not supported on the shared servers although this may change at some time in the future. Until then, Letís Encrypt certificates would require either a VPS or Dedicated server.
Title: Re: Let's Encrypt
Post by: MrPhil on November 22, 2016, 07:50:50 AM
An interesting article: http://www.theregister.co.uk/2016/01/07/net_scum_getting_lets_encrypt_certs_for_malware/

Now, The Register has become something of an online tabloid, and its articles should be taken with a few grains of salt. If I read the article correctly, Let's Encrypt SSL certificates themselves have not been compromised, but the problem is that bad actors are using them to encrypt malware deliveries from malicious (or compromised?) sites, so that en-route scanners don't pick up malware. The basic problem seems to be that those running Let's Encrypt feel it is not their job to enforce anti-malware site lists. Other certificate vendors apparently do revoke certificates if those sites are being used to distribute malware.

The bottom line is that while Let's Encrypt SSL certificates are apparently as good as anyone else's, they may be getting a bad odor about them for their policies on malware sites. Does anyone know if this has changed since this article was posted nearly a year ago?
Title: Re: Let's Encrypt
Post by: MrPhil on August 17, 2017, 08:35:39 AM
Is Lunarpages giving us SSL certificates? I see that a couple days ago, several .well-known/ and .well-known/pki-validation/ directories suddenly showed up on my site, along with some "ssl" names and such. Googling for information, I see on some other hosts they were rolling out Let's Encrypt certificates for their users, and creating such directories.

I hope to see a formal announcement on this soon. I would be delighted to get free SSL support, if that's what it is. I'm not happy, though,  to see updates to my files and directories with no word what's going on. I had some cgi-bin/ files mysteriously update all by themselves a few weeks ago, and support claimed to have no idea what happened. After some back and forth, they admitted doing some server updates.I caught this because I do a weekly listing of my files and directories to see what's changed (looking for unauthorized changes) that might be hacks.

Update: after adding https to my .htaccess Hotlink Protection, I took my site for a spin on https and so far it appears to be OK. I still need to fix a couple of hard-coded http entries, and turn on http->https redirect once I get the word that SSL is fully enabled. Going through my .htaccess, I found RewriteCond's added at every rewrite to stop .cpaneldcv and .well-known/ URIs from being rewritten. I suspect that most of these are unnecessary (just cycles wasters, as they'll never be tripped), but I'd like to know exactly what the intent is before I remove most of them.
Title: Re: Let's Encrypt
Post by: scanman20 on August 18, 2017, 05:44:00 AM
Let's hope this happens and happens soon. Apparently yesterday Google emailed  webmasters a notice that as of October when Chrome 62 is released that we'll all need SSL on our forms, otherwise Chrome will display warnings:


Quote
Chrome will show security warnings on http://www...

To owner of http://www...,

Starting October 2017, Chrome (version 62) will show a ďNOT SECUREĒ warning when users enter text in a form on an HTTP page, and for all HTTP pages in Incognito mode.

The following URLs on your site include text input fields (such as < input type="text" > or < input type="email" >) that will trigger the new Chrome warning. Review these examples to see where these warnings will appear, so that you can take action to help protect usersí data. This list is not exhaustive.

[...]

The new warning is part of a long term plan to mark all pages served over HTTP as ďnot secureĒ.

Hereís how to fix this problem:

Migrate to HTTPS
To prevent the ďNot SecureĒ notification from appearing when Chrome users visit your site, only collect user input data on pages served using HTTPS.
Read about HTTPS
Need more help?

ē   Learn more about this change in the blog post Next Steps Towards More Connection Security.
ē   Learn how to Secure your site with HTTPS.
ē   Ask questions in our forum for more help - mention message type [WNC-10038795].
Title: Re: Let's Encrypt
Post by: rickei on August 18, 2017, 09:44:23 AM
I've noticed the folders on my servers as well.
.well-known/pki-validation/
I tried my HTML sites and they seem to be working fine using HTTPS://  but my PHP sites are giving errors saying that the cert belongs to other domain name who happen to be hosted by LP. (one is a dildo company topcattoys)

I wish LP was a little more forthcoming on what they a planning here, and what I will need to do per the email that scanman20 posted. I host about 20 sites through LP and there is no way I can afford to get a dedicated account for each of them.
Title: Re: Let's Encrypt
Post by: MrPhil on August 19, 2017, 01:29:43 PM
If you're getting SSL mixups on certain kinds of site code (such as PHP on an add-on), I would open a support ticket. You may have run across some sort of edge case that they're not properly setting up for, or they made a mistake somewhere.

My site is also PHP-powered, but no add-on or subdomains. I only tried a couple pages, not any forms or anything, so it's possible I too will run into some problem. As I recall, the old shared certificates didn't run with PHP, and maybe that has something to do with the setup on the new ones. PHP itself is used on the majority of sites, so that would certainly need to be fixed.
Title: Re: Let's Encrypt
Post by: MrPhil on August 21, 2017, 05:24:42 AM
It's not Let's Encrypt (it's another free SSL system), and it's still in testing. I'm told that there will be a formal announcement when they consider it ready to go.

I'm going to hold off turning my site to SSL until the new system is formally rolled out.
Title: Re: Let's Encrypt
Post by: MrPhil on December 11, 2017, 03:06:27 PM
Still holding. Still holding.... still holding. Fingertips tapping on table. Almost four months now. They must have run into some nasty problems. I think they can write off the free SSL system they were trying to use.
Title: Re: Let's Encrypt
Post by: scanman20 on December 12, 2017, 06:54:01 AM
I've been using it for about a month now with no noticeable issues. And my Google ranking increased. Good thing LP keeps us in the loop  :roll:
Title: Re: Let's Encrypt
Post by: mbchb on December 14, 2017, 10:22:48 AM
It seems to be working fine for my sites, but I tried to setup a http to https 301 redirect and it does not work.
Title: Re: Let's Encrypt
Post by: MrPhil on December 14, 2017, 11:02:25 AM
If you show your .htaccess code to do the redirect, maybe someone can figure it out. And is this in the root (/) .htaccess? Does giving https: in the address work -- it's just http: doesn't get changed to https:? Does it fail for files in both the root and in deeper directories?
Title: Re: Let's Encrypt
Post by: mbchb on December 15, 2017, 07:13:44 AM
Yes, the main domain and all addons work fine when using https instead of http. I used the Control Panel 301 redirect to generate the .htaccess code. I was experimenting with a single primary domain, so I selected a single domain, rather than all. The CP redirect generated the code below within the .htaccess, located in the primary domain's public_html directory.

RewriteEngine on
RewriteCond %{HTTP_HOST} ^websitedomainname\.com$ [OR]
RewriteCond %{HTTP_HOST} ^www\.websitedomainname\.com$
RewriteCond %{REQUEST_URI} !^/[0-9]+\..+\.cpaneldcv$
RewriteCond %{REQUEST_URI} !^/\.well-known/pki-validation/[A-F0-9]{32}\.txt(?:\ Comodo\ DCV)?$
RewriteRule ^(.*)$ "https\:\/\/websitedomainname\.com\/$1" [R=301,L]

The code looked OK to me, but it would not allow access to the http or https version of the site. Often giving the too many redirects error.

Thanks
Title: Re: Let's Encrypt
Post by: MrPhil on December 15, 2017, 08:23:28 AM
The first two lines can be simplified to
Code: [Select]
RewriteCond  %{HTTP_HOST}  ^(www\.)?websitedomain\.com$The last line can be simplified to
Code: [Select]
RewriteRule  ^(.*)$  https://websitedomain.com/$1  [R=301,L]
Now, do you have another rewrite rule (redirect) somewhere that redirects websitedomain.com to www.websitedomain.com? If you do, that will give you a loop ("too many redirects") because you're changing the incoming URL to websitedomain.com, and then changing it to www.websitedomain.com. Furthermore, you want to put a guard RewriteCond on to do this only if it comes in http, not https -- that could also be giving you a loop. If you want to force websitedomain.com (no www):
Code: [Select]
RewriteEngine On
RewriteCond  %{HTTPS}  !on  [OR]
RewriteCond  %{HTTP_HOST}  !^websitedomain\.com$  [NC]
RewriteCond %{REQUEST_URI} !^/[0-9]+\..+\.cpaneldcv$
RewriteCond %{REQUEST_URI} !^/\.well-known/pki-validation/[A-F0-9]{32}\.txt(?:\ Comodo\ DCV)?$
RewriteRule ^(.*)$ https://websitedomainname.com/$1 [R=301,L]
If you want to force www (www.websitedomain.com):
Code: [Select]
RewriteEngine On
RewriteCond  %{HTTPS}  !on  [OR]
RewriteCond  %{HTTP_HOST}  !^www\.websitedomain\.com$  [NC]
RewriteCond %{REQUEST_URI} !^/[0-9]+\..+\.cpaneldcv$
RewriteCond %{REQUEST_URI} !^/\.well-known/pki-validation/[A-F0-9]{32}\.txt(?:\ Comodo\ DCV)?$
RewriteRule ^(.*)$ https://www.websitedomainname.com/$1 [R=301,L]

Don't forget to remove any other no www -> www (or vice-versa) redirects. Also, if you have add-on domains or subdomains that you do or don't want SSL forced, this will have to be changed a bit. It's not clear to me what you have and what you want done, so I didn't clutter it up with more cases. Basically, for each domain name (or subdomain), you would have a section like that above.
Title: Re: Let's Encrypt
Post by: mbchb on December 15, 2017, 11:07:19 AM
I appreciate the information. I have checked the root and there are no redirects setup anywhere that I can find.

I was just trying set my primary domain so that all requests to http (including http://www) would be redirected to the https version site. Eventually, I would like to do the same for the sub domains. However, some of the sub domains are hosted on but not registered with Lunarpages.

Title: Re: Let's Encrypt
Post by: MrPhil on December 15, 2017, 11:30:38 AM
If you're getting redirect loops, then something is going beyond what you've shown here. Usually, it's something like forcing "www." in one place and then non-www in another, by accident, when trying to do something like forcing https. The "other" place could be in this .htaccess, or in one in another directory.

It should be simple enough to redirect all http (non-SSL) to https (SSL) for a given domain name. I take it you have a primary domain and one or more add-on domains. There remains the possibility that you may not "see" the add-on domain names during .htaccess processing, but already have it changed to primary-domain/add-on-top-directory/. That would be seen as add-ons or subdomains being switched to SSL, even though you only specified the primary domain in the rules. Anyway, something to keep in mind (you might have to specifically exclude the top level directory of the add-on or subdomain in a RewriteCond).

My understanding is that subdomains are strictly local to Lunarpages' internal nameservers, and have nothing to do with a registrar. Add-ons are registered with a registrar, which can be LP (handled by Tucows) or some other registrar service. Both come in to your site under the primary domain, with a specified root directory (public_html/addOnName/ or public_html/subDomainName/), unless something has radically changed since I last played with this. If you attempt to put a subdomain on an add-on domain, I'm not sure what will happen (didn't work years ago).

Anyway, you need to use cPanel/LPCP/other control panel to add or delete add-on domains or subdomains, but be careful about getting tricky with it -- things like subdomains on add-on domains may still break. And there's always the possibility that SSL doesn't yet work on some things.
Title: Re: Let's Encrypt
Post by: mbchb on December 15, 2017, 11:45:17 AM
I am thinking that the guard condition you mentioned may be the problem:

RewriteCond  %{HTTPS}  !on  [OR]

I will give your last code a try shortly. The CP generated code omitted that line.

Thanks again.
Title: Re: Let's Encrypt
Post by: mbchb on December 20, 2017, 08:59:45 AM
If you're getting redirect loops, then something is going beyond what you've shown here. Usually, it's something like forcing "www." in one place and then non-www in another, by accident, when trying to do something like forcing https. The "other" place could be in this .htaccess, or in one in another directory.

It should be simple enough to redirect all http (non-SSL) to https (SSL) for a given domain name. I take it you have a primary domain and one or more add-on domains. There remains the possibility that you may not "see" the add-on domain names during .htaccess processing, but already have it changed to primary-domain/add-on-top-directory/. That would be seen as add-ons or subdomains being switched to SSL, even though you only specified the primary domain in the rules. Anyway, something to keep in mind (you might have to specifically exclude the top level directory of the add-on or subdomain in a RewriteCond).

My understanding is that subdomains are strictly local to Lunarpages' internal nameservers, and have nothing to do with a registrar. Add-ons are registered with a registrar, which can be LP (handled by Tucows) or some other registrar service. Both come in to your site under the primary domain, with a specified root directory (public_html/addOnName/ or public_html/subDomainName/), unless something has radically changed since I last played with this. If you attempt to put a subdomain on an add-on domain, I'm not sure what will happen (didn't work years ago).

Anyway, you need to use cPanel/LPCP/other control panel to add or delete add-on domains or subdomains, but be careful about getting tricky with it -- things like subdomains on add-on domains may still break. And there's always the possibility that SSL doesn't yet work on some things.

Your redirect code seems to work fine for my primary domain, it causes some issues with the sub domains - not providing access to sub-directories. I think there was a flag in CP that created a wildcard for the sub-directories.

I will play around with it, but I suspect Lunarpages has not fully implemented the free SSL for shared accounts.

Thanks again for the info.
Title: Re: Let's Encrypt
Post by: MrPhil on December 20, 2017, 02:41:42 PM
One thing to keep in mind (at least as of a couple years ago, on a cPanel server) is that LP does weird things with .htaccess. What I found happening is that if an actual directory path was given in the address, that the server skipped over the root and other higher-level .htaccess files, and went directly to that directory and its .htaccess. They denied they were doing that, but I proved they were (and worked around it by never giving actual directory paths deeper than root). So, if you had a redirect in your /.htaccess, it wouldn't be seen if you gave a deeper address. Maybe it's been fixed since then, but if not, it's something to consider if you're getting odd behavior.

Also, it's difficult to tell in advance if your HTTP_HOST is going to be the add-on or subdomain name, or if it's going to be the primary domain with the top level directory. I think it will consistently be one way or the other, but you may need to do some experimenting to see what form to use in your .htaccess.
Title: Re: Let's Encrypt
Post by: MrPhil on January 14, 2018, 02:16:23 PM
I got an email today from "cPanel" telling me that I am the proud owner of a renewed DV certificate for AutoSSL. I guess that means that SSL is formally available. It says that I should go to the SSL/TLS Wizard to upgrade to an EV or OV certificate.
Title: Re: Let's Encrypt
Post by: scanman20 on January 16, 2018, 07:36:15 AM
I didn't get an email like that. Would be nice if LP sent out updates when they do stuff like this.
Title: Re: Let's Encrypt
Post by: MrPhil on January 16, 2018, 08:45:49 AM
Hmm. Maybe it was a false alarm, like those missiles approaching Hawaii? I'm still waiting for an announcement from LP itself that the system can be used.
Title: Re: Let's Encrypt
Post by: scanman20 on January 17, 2018, 06:38:07 AM
Hmm. Maybe it was a false alarm, like those missiles approaching Hawaii?
   :clap: