Issue with EV SSL renewal

**carlwhat** · 9 Mar 2017, 06:39 PM

Originally Posted by Man from Mars

define('DIR_WS_CATALOG', '/catalog/');
define('DIR_WS_HTTPS_CATALOG', '/catalog/');

Can anyone advise me where I'm going wrong?

Thanks

your hosting company is correct. your SSL seems to be working fine.

to change your home from this:

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

to:

https://www.anglingcentrewestbay.co.uk

you need to change your configure.php file. change these lines:

Code:

  define('DIR_WS_CATALOG', '/catalog/');
  define('DIR_WS_HTTPS_CATALOG', '/catalog/');

to:

Code:

  define('DIR_WS_CATALOG', '/');
  define('DIR_WS_HTTPS_CATALOG', '/');

good luck!

**DrByte** · 9 Mar 2017, 07:54 PM

Originally Posted by carlwhat

your hosting company is correct. your SSL seems to be working fine.

to change your home from this:

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

to:

https://www.anglingcentrewestbay.co.uk

you need to change your configure.php file. change these lines:

Code:

  define('DIR_WS_CATALOG', '/catalog/');
  define('DIR_WS_HTTPS_CATALOG', '/catalog/');

to:

Code:

  define('DIR_WS_CATALOG', '/');
  define('DIR_WS_HTTPS_CATALOG', '/');

good luck!

If that's the case, then the hosting company DID change things, because BEFORE the ssl cert update, it was working as /catalog, and not as / ... so they DID mangle things, without saying so.

**Man from Mars** · 10 Mar 2017, 12:11 AM

Originally Posted by carlwhat

your hosting company is correct. your SSL seems to be working fine.

to change your home from this:

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

to:

https://www.anglingcentrewestbay.co.uk

you need to change your configure.php file. change these lines:

Code:

  define('DIR_WS_CATALOG', '/catalog/');
  define('DIR_WS_HTTPS_CATALOG', '/catalog/');

to:

Code:

  define('DIR_WS_CATALOG', '/');
  define('DIR_WS_HTTPS_CATALOG', '/');

good luck!

I changed the catalog/includes/configure.php file as above and still had an error of 'you don't have permission..... Apache/2.4.23 (Unix) Server at www.anglingcentrewestbay.co.uk Port 80'

Do I still need to add the .htaccess update as well (previous reply from MC12345678) or just the amendment to configure.php?

Thank you everyone for your support, very much appreciated.

**carlwhat** · 10 Mar 2017, 12:49 AM

#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:

Code:

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

you would need to do this on both files.

good luck.

**mc12345678** · 10 Mar 2017, 03:33 PM

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?

Code:

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** · 11 Mar 2017, 05:19 AM

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

**carlwhat** · 11 Mar 2017, 05:45 AM

completely concur w rod.

**mc12345678** · 11 Mar 2017, 09:58 AM

And unfortunately for some, there are those hosts that say: thou has no way as an end user to adjust the document root of the server as public_html is your document root, you have no access to a higher path/area, and if you decide to place the contents of your store in a sub-directory from public_html you will forever be forced to use some other process to ensure that customers arrive at that location as the "root" of your store. And while such individuals have the right to change to a host that would actually allow them to not have a web-facing sub-directory, there are those that will persist on with the domain hosted in sub-directory by way of redirect/continuous display of Web facing sub-directory.

The thing is here. The OP had previously hosted the site with this sub-directory is the domain, continues to want that and the site is not supporting that arrangement and the host has not provided a solution that complies with that arrangement. So... from the OPs perspective the document root has always been public_html with the site provided from catalog as the first directory off of public_html...

As DrByte said, it worked before the host made a change and it was working in such a way that catalog was displayed in the browser as a sub-directory off of the domain name. If you are stating/giving a solution that will alter the uri that has been in existence and used for the site, the effects of such modification both "good" and bad should be explained to the OP. Otherwise, as has been provided give a solution that restores the web-facing operation back to what it was.

Like I said, I didn't see how the document root could be used to necessarily force a visitor onto the web-facing catalog directory by way of entering just the domain name. And no such solution was described as it isn't possible without some form of rewrite/redirect based on the above two posts.

I personally agree that a sub-directory in the uri (DIR_WS_CATALOG) is generally unnecessary if not in some ways harmful, but that is associated with a new install not an existing one of a relatively new store. Making a change at that point in the operation is something that should be planned not just done because a couple of people made it sound cool. :)

**RodG** · 11 Mar 2017, 11:14 AM