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.