Issue with EV SSL renewal

Hi

Please help a very frustrated new Zenner.

I've just renewed my EV SSL certificate. Prior to the renewal, you could type my sites URL and the site would appear in a browser as HTTPS showing company name and full URL. Since updating my SSL I have had all sorts of problems getting the SSL to work. I have been in touch with my server companies on many occasions and they now state that the SSL is working fine and the problem is with the Zen Cart catalog and Admin configure.php's. I can get the SSL to work if I type https://www.mysite.co.uk/catalog but it will not work if I type just mysite.co.uk . I then get an error as:

Forbidden

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

I want to have my SSL across the whole of my site, so I have set in both catalog and admin configure.php to 'false'. As a note, my admin works fine with full SSL, so no need adjustments this side. Below are my two configure files.

#Catalog#
/*************** NOTE: This file is similar, but DIFFERENT from the "admin" version of configure.php. /
/**** The 2 files should be kept separate and not used to overwrite each other. ***********/

// Define the webserver and path parameters
// HTTP_SERVER is your Main webserver: eg-http://www.your_domain.com
// HTTPS_SERVER is your Secure webserver: eg-https://www.your_domain.com
define('HTTP_SERVER', 'http://www.mysite.co.uk');
define('HTTPS_SERVER', 'https://www.mysite.co.uk');

// Use secure webserver for checkout procedure?
define('ENABLE_SSL', 'false');

// NOTE: be sure to leave the trailing '/' at the end of these lines if you make changes!
// * DIR_WS_* = Webserver directories (virtual/URL)
// these paths are relative to top of your webspace ... (ie: under the public_html or httpdocs folder)
define('DIR_WS_CATALOG', '/catalog/');
define('DIR_WS_HTTPS_CATALOG', '/catalog/');

#Admin#

/**

• WE RECOMMEND THAT YOU USE SSL PROTECTION FOR YOUR ENTIRE ADMIN:
• To do that, make sure you use a "https:" URL for BOTH the HTTP_SERVER and HTTPS_SERVER entries:
  */
  define('HTTP_SERVER', 'https://www.mysite.co.uk');
  define('HTTPS_SERVER', 'https://www.mysite.co.uk');
  define('HTTP_CATALOG_SERVER', 'https://www.mysite.co.uk');
  define('HTTPS_CATALOG_SERVER', 'https://www.mysite.co.uk');

// secure webserver for admin? Valid choices are 'true' or 'false' (including quotes).
define('ENABLE_SSL_ADMIN', 'false');

// secure webserver for storefront? Valid choices are 'true' or 'false' (including quotes).
define('ENABLE_SSL_CATALOG', 'false');

Oh yes, I have placed an .htaccess file in the Public_html directory that reads as follows:
// ########################
// ## SSL .htaccess
// ########################

RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}/$1 [R=301,L]

Can anyone advise me where I'm going wrong?

Thanks

Well, for one: to get https: across the entire site, one must also tell ZC how to get there when SSL is not enabled:

define('HTTP_SERVER', 'http://www.mysite.co.uk');

Should be:

define('HTTP_SERVER', 'https://www.mysite.co.uk');

In your catalog includes/configure.php

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.

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:

I've just renewed my EV SSL certificate. Prior to the renewal, you could type my sites URL and the site would appear in a browser as HTTPS showing company name and full URL. Since updating my SSL I have had all sorts of problems getting the SSL to work. I have been in touch with my server companies on many occasions and they now state that the SSL is working fine and the problem is with the Zen Cart catalog and Admin configure.php's. I can get the SSL to work if I type https://www.mysite.co.uk/catalog but it will not work if I type just mysite.co.uk . I then get an error as:

Forbidden

You don't have permission to access / on this server.
I give them credit for trying to pass the buck ... But ... if it "worked before the SSL cert was changed", and suddenly afterward it "doesn't work", then ... what changed was the SSL configuration of the server ... not Zen Cart.

And the "forbidden" error strongly indicates that they've busted the vhost for the SSL side of your domain and have it pointed to someplace other than the same document root as the non-SSL site.

In short: it's a server issue.

(Unless you're not telling us about changes you made to your ZC files in the meantime. But if nobody changed Zen Cart, then ... the problem isn't Zen Cart.)

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.

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 https://www.anglingcentrewestbay.co.uk you will get a Forbidden Message unless you add /catalog.

All help very much appreciated :smile:

Man from Mars:

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

> 
> All help very much appreciated :smile:

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.

Man from Mars:

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.

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...

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 insensitive.

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]

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:

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

to:

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

good luck!

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:

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

> 
> to:
> 
> ```
  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.

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:

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

> 
> to:
> 
> ```
  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 https://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.

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

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 [noparse]www.anglingcentrewestbay.co.uk[/noparse] 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.

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

completely concur w rod.

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. :)

mc12345678:

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,

Agreed, but it is very rare that anyone would need a doc_root at a level higher than public_html - I've never found a need for this in over 20 years of hosting (exect on my own servers/VPS servers, where a higher level can be used to greatly enhance some forms of security), but basically, this is a moot point that doesn't need to even be mentioned, let alone discussed.

mc12345678:

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.

NOT SO! I've yet to find a host where this isn't possible - Not only is it possible, but in many situations it is actually desired.

mc12345678:

The thing is here. The OP had previously hosted the site with this sub-directory is the domain,

This is pretty standard practice.

mc12345678:

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...

What can I say? The OP has simply never had the site correctly set up - Well, he has, but only if he ever uses a single domain/site for the given host.

mc12345678:

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.

It is not my point to discuss any of the possible workarounds. I have already acknowledged that they exist. Let's leave it at that.

mc12345678:

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.

You are correct, but this is still a 'workaround' of an iincorrect document_root.

As it stands (for the OP) - his URL for his zencart site is always going to show /catalog/ - In some cases this is fine, if there are other files/software (eg, Wordpress) exists in the document root, and the zenstore is a subset of the wordpress site), but his zenstore isn't a subset of any other software - He has nothing in the document root (other than the .htaccess file to force a needless redirect to a folder, that should be the document root.

mc12345678:

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. :)

As I stated, I will never understand why people make it hard for themselves, and I strongly disagree with your statements that imply it can't be done right.

Lets look at a couple of examples... assume a person has a single hosting account with two different zencart stores - Based on what you are saying (and with full acknowledgement that a folder above public_html can't be used, then what will the folder structure be?

There are three possibilities:

/public_html/zenstore#1/
/public_html/zenstore#1/zenstore#2

In this scenario. and based on the claim that doc_root can''t be changed, there will need to be a .htaccess redirect placed in public_html for zenstore#2 and zenstore#2 will need the WS defines for the folder/
The URL for zenstore# look quites unprofessional - being in a folder of the domainname. IOW, a 'workaround' is needed.

/public_html/zenstore#1/
/public_html/zenstore#2/

This is very similar to scenario one, but now both stores/domains need a 'workaround' and the folder showing in the URL - There is effectively no 'root' for either domain.

Same as #2
/public_html/zenstore#1/
/public_html/zenstore#2/

... But this time, we have set the document_root for zenstore#1 to be /plublic_html/zenstore#1 and the document_root of zenstore#2 to be /public_html/zenstore#2

In this scenario, we don't need any .htaccess redirects in /public_html/ - From the server perspective, this folder doesn't even exist. We also don't need to include zenstore#x in any of the zencart server defines, nor do we need to set any zencart WS defines to refer to any folders. THese will all simply be the default "/"

The only place where zenstore#x will be defined in the zenconfig file, will be in the FS defines.

It really couldn't get any simpler than that.

Even with just a single store in a folder located off of the public_html/ folder - as is the OP's case (/catalog/ ) - The /catalog/ is superfluous and unprofessional if shown/used in the URL. It smacks of amateurism.

And if you think that this professional scenario can't be achieved "due to ISP/host limitations, then please contact me via PM, because I have a lot to teach you about host configurations.

FYI,
http://www.radiosailingshop.com.au/
http://girlbysea.com.au

Are two independent zencart sites for a customer with a single hosting account with a file structure
/public_html/radiosailing/
/public_html/girlbysea/

There are no redirects in place, no /folders/ in the zencart config files (other than the FS defines) - You can go to either site, and no 'folders' are shown in the URL (one would expect http/domainname1.com/radiosailing/ and http://domainname#2/girlbysea/ unless a rewrite were used. The 'magic' that makes this work, with no redirects, and no /folders/ shown is simply because the document_root for the radiosailing domain is set to /public_html/radiosailing/ and the document_root for girlbysea is set to /public_html/girlbysea/

I have yet to find a host where this configuration isn't possible. I/we even have a policy these days that all sites we setup/host actually use a document_root one folder deeper than /public_html/ - It makes no difference to the webserver (which will always use the correct 'root' for any given domain for any given customer). but it makes a huge difference in regards to the file structure and ease of adding other domains for the same customer account.

Hopefully, this all makes sense to you (I suspect it doesn't though), else you wouldn't be making statements that imply that this isn't possible with all hosts. It is possible, and where one icould have been difficult, the cPanel (that most hosts use these days) makes it trivial.

BTW, I hate cPanel - It allows people without a clue the ability to set up their own 'hosting business'. (I'm not suggesting that you are one of these people) but without Cpanel (or should I say WHM) most hosting providers these days wouldn't even exist.

Cheers
RodG

RodG:

Agreed, but it is very rare that anyone would need a doc_root at a level higher than public_html - I've never found a need for this in over 20 years of hosting (exect on my own servers/VPS servers, where a higher level can be used to greatly enhance some forms of security), but basically, this is a moot point that doesn't need to even be mentioned, let alone discussed.

NOT SO! I've yet to find a host where this isn't possible - Not only is it possible, but in many situations it is actually desired.

This is pretty standard practice.

What can I say? The OP has simply never had the site correctly set up - Well, he has, but only if he ever uses a single domain/site for the given host.

It is not my point to discuss any of the possible workarounds. I have already acknowledged that they exist. Let's leave it at that.

You are correct, but this is still a 'workaround' of an iincorrect document_root.

As it stands (for the OP) - his URL for his zencart site is always going to show /catalog/ - In some cases this is fine, if there are other files/software (eg, Wordpress) exists in the document root, and the zenstore is a subset of the wordpress site), but his zenstore isn't a subset of any other software - He has nothing in the document root (other than the .htaccess file to force a needless redirect to a folder, that should be the document root.

As I stated, I will never understand why people make it hard for themselves, and I strongly disagree with your statements that imply it can't be done right.

Lets look at a couple of examples... assume a person has a single hosting account with two different zencart stores - Based on what you are saying (and with full acknowledgement that a folder above public_html can't be used, then what will the folder structure be?

There are three possibilities:

/public_html/zenstore#1/
/public_html/zenstore#1/zenstore#2

In this scenario. and based on the claim that doc_root can''t be changed, there will need to be a .htaccess redirect placed in public_html for zenstore#2 and zenstore#2 will need the WS defines for the folder/
The URL for zenstore# look quites unprofessional - being in a folder of the domainname. IOW, a 'workaround' is needed.

/public_html/zenstore#1/
/public_html/zenstore#2/

This is very similar to scenario one, but now both stores/domains need a 'workaround' and the folder showing in the URL - There is effectively no 'root' for either domain.

Same as #2
/public_html/zenstore#1/
/public_html/zenstore#2/

... But this time, we have set the document_root for zenstore#1 to be /plublic_html/zenstore#1 and the document_root of zenstore#2 to be /public_html/zenstore#2

In this scenario, we don't need any .htaccess redirects in /public_html/ - From the server perspective, this folder doesn't even exist. We also don't need to include zenstore#x in any of the zencart server defines, nor do we need to set any zencart WS defines to refer to any folders. THese will all simply be the default "/"

The only place where zenstore#x will be defined in the zenconfig file, will be in the FS defines.

It really couldn't get any simpler than that.

Even with just a single store in a folder located off of the public_html/ folder - as is the OP's case (/catalog/ ) - The /catalog/ is superfluous and unprofessional if shown/used in the URL. It smacks of amateurism.

And if you think that this professional scenario can't be achieved "due to ISP/host limitations, then please contact me via PM, because I have a lot to teach you about host configurations.

FYI,
http://www.radiosailingshop.com.au/
http://girlbysea.com.au

Are two independent zencart sites for a customer with a single hosting account with a file structure
/public_html/radiosailing/
/public_html/girlbysea/

There are no redirects in place, no /folders/ in the zencart config files (other than the FS defines) - You can go to either site, and no 'folders' are shown in the URL (one would expect http/domainname1.com/radiosailing/ and http://domainname#2/girlbysea/ unless a rewrite were used. The 'magic' that makes this work, with no redirects, and no /folders/ shown is simply because the document_root for the radiosailing domain is set to /public_html/radiosailing/ and the document_root for girlbysea is set to /public_html/girlbysea/

I have yet to find a host where this configuration isn't possible. I/we even have a policy these days that all sites we setup/host actually use a document_root one folder deeper than /public_html/ - It makes no difference to the webserver (which will always use the correct 'root' for any given domain for any given customer). but it makes a huge difference in regards to the file structure and ease of adding other domains for the same customer account.

Hopefully, this all makes sense to you (I suspect it doesn't though), else you wouldn't be making statements that imply that this isn't possible with all hosts. It is possible, and where one icould have been difficult, the cPanel (that most hosts use these days) makes it trivial.

BTW, I hate cPanel - It allows people without a clue the ability to set up their own 'hosting business'. (I'm not suggesting that you are one of these people) but without Cpanel (or should I say WHM) most hosting providers these days wouldn't even exist.

Cheers
RodG

If I were to properly split through the above, this might be "easier" but, I'm lazy. :)

I have not personally come across a server that can not permit assignment of a document root to anything other than public_html; however, in assisting other to initially setup their system I have been told that they would have to obtain a second domain in order to have any domain made accessible from deeper than the main public_html... I personally use one if not more levels deeper than public_html for my sites/test sites. That a site can not is really all/more about will not because it doesn't fit their business model or whatever other dumb @$$ reason that they have come up with to not make it amenable to the customer/store owner.

My issue here is that in none of the examples provided did a change in document root resolve the uri to what it has been before the SSL was installed and there has been no discussion of the impact of a change of the web-facing uri with regards to search engines or ranking.. Somewhat comical to bring to the discussion is the "professionalism" of the uri that tongue in cheek supposedly makes no difference to customers because they don't pay attention to them anyways, and could be anything. (Little bit of a continuous discussion about unrelated topic of URI rewriters and the web site path that with great surprise has dwindled as of recent. ;) )

Okay, but seriously, like I said, I agree that there is no business reason for a domain name that solely supports a single "subject" (store) should use a web-facing subdirectory as the base of the store. At the very least changing the document base for a store that has already been in operation to remove the web-facing sub-directory will break links that are/have been stored by visitors even those that only saved the store's home-page... And to prevent/correct that specific issue if one wished to maintain that level of reachability at least for a period of time would require a rewrite rule (again) which has also been suggested as unfavorable/unnecessary. Yes, of course could make the change and then let the chips fall where they may.. But that should be a conscious decision not just something willy nilly done.

Further unfortunately, it seems that perhaps a similar rewrite/redirect previously existed, but wasn't known to exist and when touching the site the host modified something to accomplish what we all would suggest (for a new site or to plan for as a transition) which is to place the site/software at the root of the domain name regardless of how many sub-directories exist on the "back-end". Regardless they changed the operation and have falsely accused ZC as being the fault.

OP, choose what you would like. Right now your what, at least 3 days without guests arriving at your store by typing in the domain name... How's traffic been? Reduced? Sales? Any change? Are you wanting operation as it was and setting aside time to address the other things that we're here talking about? I would suggest doing something, either move the document root, or move the store from the sub-directory to the document root, or redirect visitors to the sub-directory. Right now as you discovered, entering just the domain-name gives a 403 forbidden page which means off to the next site if/when provided.