We have a client site, quatt.com, which is a Wordpress site but for which we did prototyping in Freeway (which is why I’m posting here). We’re having SSL problems even though the certificate (issued via Letsencrypt) is fine: Screenshot 2023 11 16 at 10 38 12 AM — Postimages (by the way I get the Heartbleed warning on other sites but their SSL connections are fine).
In Firefox, Chrome and Edge the site shows this error:
The connection for this site is not secure
quatt.com sent an invalid response.
The site is running on an older version of PHP and the only things I can think of are either:
- Firefox, Chrome and Edge don’t like Letsencrypt certificates even though other sites with Letsencrypt certificates aren’t having problems
- Those browsers don’t think the older PHP is secure (we stayed at the older version because we host other legacy sites for some nonprofit clients who don’t have much budget to update them).
I’m wondering if anyone here has any ideas.
Thanks in advance.
The culprit here is likely Apache (or whatever other Web server you have configured on this account) rather than PHP or WordPress. SSL termination is handled by the Web server in most cases, and configuration there may be quite out of date (using encryption settings that are no longer in vogue, for example). Pass this along to your sysadmin, and have them check the SSL settings and TLS encryption mode.
Thanks Walter, we’ll take a look.
Hi Walter, everything seems to be OK. I’m wondering if it’s #2, that those browsers don’t think the older PHP is secure. What do you think?
PHP doesn’t enter into it at that level. Everything about the SSL termination is handled in the Web server. In Apache, that’s in the mod_ssl plugin. In other Web servers, it’s a similar module of one kind or another. While PHP is usually compiled into the Web server, often using the mod_php plugin, it’s simply a shim that directs PHP instructions to the command-line of the server, so that they can be converted to HTML, and then sent on to the Web server for delivery to the visitor. That whole loop only happens after the initiating request is accepted by the SSL mechanism, keys are exchanged, decryption occurs, and the request becomes readable by Apache. It’s all at a different level of the request “stack”, as it were.
I had a look at the link you posted, which is redirecting after a mighty pause to https://blue-iceberg.com/quatt.com here, and I cannot seem to fiddle the URL in such a way that it can appear to be its own domain.
The encryption on that server appears to be modern and high-quality, using a 2,048-bit key. I really cannot explain why the exact error you quoted would be raised. Do you know any more about the browser/platform/version that reported it?
Oops. I forgot to mention that in order do deal with this we created a static version of the site, uploaded it to our server, and put a redirect on from quatt.com to blue-iceberg.com/quatt.com. Unfortunately that didn’t solve it. I’m now asking the client’s IT guys to take the redirect off but they haven’t called me back. I’ll let you know when they do.
OK, this problem went away for the quatt.com website but now we have it on others, including our own www.blue-iceberg.com. I’m being told on the Letsencrypt discussion list (community.letsencrypt.org) that our versions of Apache and OpenSSL are too old but I can’t update these from Plesk. The server is running Plesk Onyx Version 17.8.11 Update #94. I thought that an upgrade to Plesk Obsidian would solve this but our hosting company, GoDaddy, is not willing to do this on our server yet. I’m angry because we used to host with Mediatemple which had good tech support but they were acquired by GoDaddy and we were migrated to a new server recently which I believe is the root of all these problems.
My question is: if I update Apache and OpenSSL manually via SSH, will that break Plesk Onyx or will things still be OK?
I haven’t used Plesk in over a decade. Not sure whether the elements within it are tightly bound by version or not. My guess is that you could try it and see, as long as the server has some form of backup that you could roll back to. Another way to treat this is less like pets and more like cattle: spin up a new server and deploy one site there. See if everything works before you move everything else over. The notion of keeping a server around for years is somewhat antithetical to good sysadmin practice these days. Most of the pros I know (not me, to be clear!) use containers and virtualization and can spin up a new server in minutes using orchestration tools like Kubernetes or similar.
Walter, I’d love to move to a new server. It would also be cheaper as Godaddy is fleecing us for what they call a “non-standard VPS”. Problem is, some of our sites are running on old PHP code and the clients don’t have money to update their code. So I’m kind of stuck and ideally could make this work so I can kick the can down the road. The Godaddy tech people walked me through updating the SSL certificates and have assured me this will work, but told me I’ll have to wait 72 hours for it to propagate. Time’s up tomorrow afternoon so we’ll see.
Well, I waited 72 hours and surprise, surprise, it didn’t work. I’m going to manually try to update Apache and OpenSSL via SSH and see if that fixes it. If that doesn’t work I’m going to have to look at another hosting company since I’m fed up with Godaddy. I’m looking at Hostinger, Bluehost… any ideas? (by the way we went with Fastmail at your recommendation, Walter–thanks!) Ideally a place to host multiple sites as well as email for some. Thanks!