So I had a long conversation with TSOHOST this morning asking them why the connection gets reset I provided all the evidence and below is what the outcome was
i do understand that, but since i am unable to replicate any of these issues on my end (on two environments) there's little I can do, regrettably.
to summarise - you can't run curl commands on this server as you don't have root privileges nor the curl extension enabled; your SSL is not aplying because you are missing a force HTTPS rule, which should be added via your .htaccess file for each website (and you have none for neither website) and you can't automate SSL renewal on shared hosting because again, you are on a shared hosting server with no root access (you need sudo privileges to run either certbot or any autoSSL rule)
i'm sorry if this is not an acceptable answer, Keith. but regrettably, from all you mentioned above, you are trying to achieve something that is not possible on your current hosting server
Looks like the TSO Host answer you got below is not even correct given what you said in your first post. And, I was getting "reset" errors for your "home" page using a Windows Edge browser.
You could use the DNS Challenge to get a cert. But, at least some people will still see that "reset" error using your site. And, TSO Host is unable to reproduce or offer tracing help so you have to decide if they are still a good service.
cURL is simply a command-line browser that @MikeMcQ used to demonstrate the problem. There's no need for you to run cURL yourself. As @MikeMcQ mentioned above, the same issue occurs when attempting to reach your homepage with a typical browser.
That TSOHOST responder clearly hasn't a clue what they're doing since CertSage uses UAPI to enable the force https toggle inside cPanel itself (which you can also do manually under the domains section in cPanel). You do not want to do this in an .htaccess file for many reasons.
That's not entirely true nor is it relevant to the problem at hand. Please stop framing this as a problem with CertSage or certificates with them, meaning please move them away from looking at those things, which aren't the problem, and have them work on the actual problem, which is a connectivity issue (server or network problem).
There's no actual problem with having CertSage acquire or its install a cert in its own right. As you already know (and I'm only stating for the benefit of broader clarity here), the intermittent connectivity issue is causing problems with http(s) communications in general, which is interfering with CertSage being able to complete an HTTP-01 challenge with Let's Encrypt. CertSage usage is not the problem here. It's merely indicating the actual problem. This is a server/network problem, so we need to stop pointing fingers at the wrong places (CertSage/certs) and start pointing fingers at the right places (server/network). Acquiring and installing a certificate by some other means will NOT fix this problem.
So not having any luck with renewing my four SSL certificates I left it for a few days and I found I was now getting two different messages when trying to renew.
Your symptom has changed but the underlying problem is the same. There are inconsistent results making requests to your domain. We have seen this same pattern of faulty redirects and your original problem of "reset" failures. The pattern is that the first request from an IP fails but then they work properly. But, if you wait too long from that same IP the next request will fail but then work again.
See below that the first request from a new IP gets a faulty redirect (back to itself). But, after that requests are normal. Retrying multiple times you just got lucky that eventually Let's Encrypt's requests came from IP addresses it used on previous attempts.
You will get more consistent results getting a cert if you start using the DNS Challenge. But, they may be a big effort. Or, try using a different Certificate Authority.
But, this just would improve getting a cert. Some users of your sites may be affected. It is difficult to know the scope since your hosting provider cannot find the problem.
UPDATE: Regular users may be affected but only a minor issue with this faulty redirect. A browser would see the redirect, follow it, and then get a proper redirect. Let's Encrypt sees the faulty redirect and stops to protect itself from chasing a redirect loop. So, the DNS Challenge would help unless your provider goes back to issuing "reset" failures for the first request.
First request. Note it redirected to just '/' and no "Server" header
curl -i holmes.uk.com
HTTP/1.1 302 Found
Connection: close
Pragma: no-cache
cache-control: no-cache
Location: /
Immediately after get redirected by Apache server to your HTTPS as expected
curl -i holmes.uk.com
HTTP/1.1 302 Found
Date: Mon, 24 Jul 2023 16:37:41 GMT
Server: Apache
Location: https://holmes.uk.com/
Content-Length: 206
Content-Type: text/html; charset=iso-8859-1