Issue with EV SSL renewal

[mc12345678]

Another thing is that you don't have anything in your htaccess that forces the inclusion of www. as a prefix, just something that forces the page to go to https with whatever domain name has made it to this point.

[mc12345678]

And (sorry for the individual posts) there is nothing that redirects/forces the visitor to go to the catalog sub-directory if it was not included in the original uri. Which of course also begs the question of why the store is seen by visitors to be in a sub-directory anyways rather than at the root of the domain name?

[Man from Mars]

Another thing is that you don't have anything in your htaccess that forces the inclusion of www. as a prefix, just something that forces the page to go to https with whatever domain name has made it to this point.

This .htaccess was given to me be the support team at 123 Reg. what should it be if I may ask?

I have no idea about writing these scripts. My site is www.anglingcentrewestbay.co.uk you will get a Forbidden Message unless you add /catalog.

All help very much appreciated

[mc12345678]

This .htaccess was given to me be the support team at 123 Reg. what should it be if I may ask?

I have no idea about writing these scripts. My site is www.anglingcentrewestbay.co.uk you will get a Forbidden Message unless you add /catalog.

All help very much appreciated

Unfortunately this is not a ZC specific issue, so the solution(s) can be found by searching the internet. There are a number of ways to accomplish the task, some dependent on the server others well, just form/function I guess.

Here is one solution that is likely to work:

Your .htaccess should look something like this. Note, the sequence of "commands" in the .htaccess are as important as any line of code in say the ZC store. They are processed top down and in some cases stop execution of any further rules. So, sequence (at least of groups) is important.

The below .htaccess rule was tested against an online htaccess tester and appeared to work for all cases of:
http://angling
https://angling
http://www.angling
https://www.angling
and with or without the subdirectory of catalog being present as the first sub-folder
with the response of https://www. and the subdirectory appended to the path with whatever file(s) that were called and parameters attached. Note that any other subdirectory that is first after the site name will be appended to the catalog directory such that:
site/other_directory/file.php?param1 will give: site/catalog/other_directory/file.php?param1

RewriteEngine on

RewriteBase /

RewriteCond %{HTTP_HOST} ^(www\.)anglingcentrewestbay\.co\.uk [NC] # Checks if the HTTP_HOST either has or does not have www prefix. If so, continue checking
RewriteCond %{REQUEST_URI} ^/(catalog/)?(.*)$ # Checks if the base of the site is called or optionally if the subdirectory catalog/ is used and captures the remainder of the URI as %2
RewriteRule ^(|/catalog)(.*)$ https://www.anglingcentrewestbay.co.uk/catalog/%2$1 [QSA,L,R=301] # If no subdirectory is provided or if the directory is /catalog then if /catalog it will be removed from the $1 response portion as part of %2 and any remaining parameters will be appended with site being https and including the prefix of www.

[mc12345678]

Though, one thing I see is that a 301 will be provided regardless of the address that is entered.. :/ Grrr.. Just realized/thought about that.. So, guess could add a few other checks against the provided values such that if it is not SSL or it is not catalog, or it does not begin with www, then do all of the above.. May come back with something more to support that portion of the testing...

[mc12345678]

Corrected htaccess if host is unable to correct their document-root issue:

This will not issue a 301 if all of the features are used (https, begins with www., and in the subdirectory catalog) All of those tests are case *in*sensitive.

RewriteEngine on

RewriteBase /

RewriteCond %{HTTP_HOST} ^(www\.)anglingcentrewestbay\.co\.uk [NC] # Checks if the HTTP_HOST either has or does not have www prefix. If so, continue checking
RewriteCond %{HTTP_HOST} !^www\. [NC,OR]
RewriteCond %{REQUEST_URI} !^/catalog [NC,OR]
RewriteCond %{HTTPS} off [NC]
RewriteCond %{REQUEST_URI} ^/(catalog/)?(.*)$ # Checks if the base of the site is called or optionally if the subdirectory catalog/ is used and captures the remainder of the URI as %2
RewriteRule ^(|/catalog)(.*)$ https://www.anglingcentrewestbay.co.uk/catalog/%2$1 [QSA,L,R=301] # If no subdirectory is provided or if the directory is /catalog then if /catalog it will be removed from the $1 response portion as part of %2 and any remaining parameters will be appended with site being https and including the prefix of www.

[/QUOTE]

[carlwhat]

#1 the hosting company may have screwed things up; that is really not for me to say. i'm just trying to help the OP solve their problem.
#2 mc is very competent; i'm sure there is good advice in there, but IMHO it does not have to do with the '/catalog' problem you are now having. although it may be able to solve the problem; i am not nearly as competent in the black magic of .htaccess rules.
#3 i disagree that the problem is a mis-configuration on document root for the SSL. both of these links go to the same place:

http://www.anglingcentrewestbay.co.uk/catalog/
https://www.anglingcentrewestbay.co.uk/catalog/

i still think the problem can be solved with ZC configure.php files. how they got screwed up, i can not say.

when you removed the 'catalog/' from the other code, it looks like you may need to add it to your document root variable:

 define('DIR_FS_CATALOG', '/YOUR/CURRENT/ROOT/catalog/');

you would need to do this on both files.

good luck.

[mc12345678]

Not that I necessarily have access to improperly setup a site with an SSL, but I did notice something that seems odd... If the SSL were properly setup when trying to access the root of the domain (up a folder from the root of the store) via https, shouldn't the denied access response be provided over port 443 instead of port 80?

Forbidden

You don't have permission to access / on this server.
Apache/2.4.23 (Unix) Server at www.anglingcentrewestbay.co.uk Port 80

Or is it the fact that it is reporting an attempt to access the root of the server (which really or likely is several folders into the system) that is the indication of this document-root issue? (I sometimes forget that the reported location is from the root of the server where other times a reported issue is from the current location...) If I'm right about the reported error being associated with the root of the server, then I now understand how the certificate setup was called to question (at fault at least in part).

The fact that when the subdirectory is referenced that the site operates, to me states that internally the includes/configure.php file was setup well enough to present the first page (indicating to me that generically speaking the DIR_FS constants pointed to the right place(s) on the system to allow loading of files when accessed using DIR_FS_ related constants). The fact that one could navigate from that location also indicates to me that generally speaking the DIR_WS_ related constants were set right at least relative to the current location. So that further indicates to me that the configure.php files are/were correct for the current configuration. The problem as identified at the onset is getting the customer to the proper folder based on entering the domain name only (and of course ensuring that the web-facing side is https: and that the https: path includes the information necessary to satisfy the SSL certificate "validation".)

The fact that it is/was desired to have the entire site SSL, and the rewrite in the htaccess to try to force to https on at least first page load or at any time a http: path is provided and that navigation from one page to another or an attempt to access the site using http: forced me as a webpage clicker to end up on a page with https indicates that at least the htaccess rule that was present was working to keep pages https. But... if you were to look at the source code of the page, there existed links to items in the store that had an http: link which can only be provided if 1) hard coded (discouraged because is less flexible) or 2) one or more of the includes/configure.php constants had http: in it... (that was one of the earlier changes recommended). By leaving that as http: and the htaccess forcing https, basically every link clicked on required rewriting and the page would still cause basic links to begin with http:.

I may not fully understand the document-root aspect of the SSL, but it doesn't seem to me that the SSL configuration itself would modify how a visitor gets to the correct path in the store (I think those two things are separate, but it based on higher authority comment at least when trying to access the root of the store there is information provided/known to indicate such a problem). Now, I also hazard to guess that your public_html folder doesn't include any version of an index file, neither index.html nor index.php. That too could be why the unauthorized access message is presented...

Regardless, I stand by my previous recommendations as a manually entered means to get the visitor to the sub-folder by https: and the domain name to include www. on first (and subsequent) page load and the other change of the includes/configure.php to have HTTP_SERVER include https: as part of the URI to then support staying on https: from page-to-page and not cause additional redirects. There may still be a problem with things such as the document-root of the certificate, there may have been some internal redirect to the folder that was removed/modified by the host, etc... I don't know how it was setup before. I do know that the host provided .htaccess rule is one rule that will change the visited page from http: to https:; however, that is all that it does. It does not redirect to the sub-folder, it doesn't ensure that www. is part of the domain name assuming that the certificate requires the www. prefix, etc... The "short" .htaccess rule I provided is expected to ensure all three conditions are met by either making the necessary modifications to the provided information or not doing anything if the expected information is already present such as when navigating the site once there. I chose the compact method to attempt to minimize processing for each page load and to keep things straight because if split out more, then would have to address each issue separately with the expectation that the end result would be as desired and future additions of htaccess rules (if any) wouldn't muck things up.

[RodG]

Just my 2cents worth.

If the document_root is correctly defined (cPanel and/or host setting) there is no need for any rewrites/redirects.

I'll even go as far to say, if a rewrite is needed, then you are doing it all wrong.

If the document_root is correctly set (for this site), the *only* place "catalog" would appear in the zencart configure files will be in the FS defines. If 'catalog' appears in any of the server defines, or the WS defines then you are doing it wrong.

Sure, I will admit that a person *could* mess around using rewrites/redirects, and they could add/include folder paths in the Server/WS defines in the ZenCart config files to get a site 'functional' - but all this is really doing is compensating for an incorrect/invalid document_root.

I prefer the KISS principle.

1. Get the document_root correct
2. Set the zencart *server* settings - Domain name only - no paths or subfolders.
3. Set the zencart FS paths (The WS settings never need to be changed from their defaults)
4. Remove the .htaccess file

The site should then function correctly, both with and without SSL. If it doesn't, then investigate why not - BEFORE considering redirects/rewirite, or adding paths/folders to anything ofther than the FS defines.

Then, and only then should one consider *optionally* adding rewrites/redirects to take care of ' *1st access* changes (www to non www, and/or http to https).

I will never really understand why so many people make this so difficult for themselves

Cheers
RodG

[DrByte]

you will get a Forbidden Message unless you add /catalog.

That's a misconfiguration of permissions on your hosting account, for whatever directory is the document-root in ssl mode.

Your hosting company needs to fix what they broke.