Insecure Connection Error

Help
1

My domain is: www.blue-iceberg.com

I ran this command: Installed certificate using Letsencrypt Plesk extension version 2.12.8-709. Added acme-challenge record to DNS.

It produced this output: The site works fine in Safari and Firefox but in Chrome and Edge I get this message:

This site can’t provide a secure connection

blue-iceberg.com sent an invalid response.
ERR_SSL_PROTOCOL_ERROR

My web server is (include version): Linux

The operating system my web server runs on is (include version): CentOS 6.3

My hosting provider, if applicable, is: Godaddy (Was Mediatemple but Godaddy bought them)

I can login to a root shell on my machine (yes or no, or I don't know): Yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): Plesk Onyx Version 17.8.11 Update #94

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): ? Don't know

• • • • • • • • • • • • • • • • • • • • • • • • • • • • •

I renewed the certificate using the Letsencrypt Plesk extension and it is valid until February 22, 2024. I generated the new certificate and made a TXT acme-challenge record in DNS. As I mentioned above, the certificate is valid when I check it and passes when I check it with digicert, geocerts, etc. The only issue is that when I test it on SSL Checker (sslchecker.com) I see that Root 1 is missing in the certificate chain (see screenshot here: Screenshot 2023 11 24 at 5 36 33 PM — Postimages) However another site has the same error and has no issued with the SSL connection. I also have the "Permanent SEO-safe 301 redirect from HTTP to HTTPS" box checked in Plesk Hosting Options.

Does anybody have any idea what I'm doing wrong here?

Thanks in advance.

1 Like
2

Hi @rcacciato, and welcome to the LE community forum :slight_smile:

You haven't done anything wrong.
Recently, the cross-signed DST root cert has been showing up as expired/revoked.
If you don't actually need it, you can just switch to using the shorter chain.
[which will be the default in a few months anyways]

3 Likes
3

Thanks, rg305. How do I switch to the shorter chain? Will this solve my ERR_SSL_PROTOCOL_ERROR problem?

1 Like
4

I can reproduce the likely reason for the error you see (see below)
You might check out this other thread for possible correction

curl -i https://www.blue-iceberg.com
curl: (35) error:0A000172:SSL routines::wrong signature type

openssl s_client -connect www.blue-iceberg.com:443
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = blue-iceberg.com
verify return:1
40176A373E7F0000:error:0A000172:SSL routines:tls12_check_peer_sigalg:wrong signature type:../ssl/t1_lib.c:1567:
2 Likes
5

I am not sure you'll be able to do anything about this error, but have a look here:

https://www.ssllabs.com/ssltest/analyze.html?d=blue-iceberg.com

4 Likes
6

Yes, this looks like the "OpenSSL SHA-1 handshake" bug. It doesn't have anything to do with Let's Encrypt or your certificate. It is a bug in your webserver's software, which modern OpenSSL, Chrome, and other software doesnt' tolerate anymore.

Unfortunately most online "cert checking" tools don't flag this, because it's not a problem with the certificate.

You have three options:

  1. Upgrade your operating system. Centos 6 has been EOL for years already. You should do this anyways. Your software is old and insecure, with many known bugs. Your website is at risk by using software past EOL.

  2. Stop using SNI. The bug only occurs when OpenSSL is used with SNI (multiple domains on one IP address). However, I looked in the Plesk Onyx manual and it says: "On Plesk for Linux, the support for SNI is always on and cannot be disabled." There may be some workaround, but I am not an expert in Plesk. This requires you to have one IP address per hosted site as well, which may be a problem if you have many domains.

  3. Put your website behind some sort of load balancer or CDN that does TLS for you, so the user's browser doesn't have to talk to your website directly.
    a. An external CDN like Cloudflare could work
    b. Or just another server you run, if it's easier to start a 2nd one with a more modern operating system.
    c. You could use another HTTPS proxy like Caddy on the system that doesn't use OpenSSL. You'd disable TLS in your existing server, and Caddy handles listening on https on port 443 and redirecting to 80 (plain http:)

9 Likes
7

Thanks for this input. If I am able to upgrade CentOS 6 version up to 6.9 will this fix the issue? Or do I have to go to a later version. We hosted with Mediatemple which had great tech support but they were bought by GoDaddy (less good tech support) and I'm being told our Linux VPS is locked down.

2 Likes
8

Centos 6 never went beyond version 1.0.1e, but the bug was fixed in 1.0.1i. I haven't checked if Centos backported that patch specifically, but it seems unlikely to me.

4 Likes
9

There are build guides (and even ready-to-use RPM's) for openssl 1.0.2 on CentOS 6 elsewhere on this forum:

This works because openssl 1.0.2 is ABI compatible with 1.0.1 (newer versions aren't).

But let's be clear: anything you change on your CentOS 6 server is at your own risk, you should upgrade or replace it eventually.

3 Likes
10

Btw I can't verify it right now, but I'm pretty sure the latest version of openssl 1.0.1 on CentOS 6 does support SHA-2 server signatures, so maybe just upgrading your CentOS 6 is enough.

4 Likes
11

Indeed this particular patch was backported to CentOS 6 with openssl 1.0.1e-34:

Tue Mar 03 2015 Tomáš Mráz tmraz@redhat.com 1.0.1e-34

  • copy digest algorithm when handling SNI context switch
  • improve documentation of ciphersuites - patch by Hubert Kario
  • add support for setting Kerberos service and keytab in
    s_server and s_client

This was released in March 2015, so you haven't updated your server for at least 8,5 years??
(the last CentOS 6 patches came out in November 2020)

5 Likes
12

I would not dare to connect such a system to the global internet :scream:

1 Like
13

Personally I'd say the solution is moving your sites to new hosting. I see you are a web host for multiple clients. You could temporarily use a more modern OS and webserver as a front end server (like Caddy or nginx) with a reverse proxy to your old server for the content, then gradually move your sites to new server (or servers). Depending on your hosting features you could keep the same IP (so clients don't have to update DNS) but point that to your reverse proxy, which in turn connects to the old server on a different IP. If you can't move the IP address around you could instead get each client to repoint their DNS individually, but get an IP you can reassign as required for your new hosting, or use CNAMEs instead of IPs for website host DNS entries.

Either way you need to retire this server so I'd suggest using this problem as an opportunity.

As you move each site to a new server or hosting solution, document it's individual requirements and configuration process, that way next time stuff needs moved it's easier to do so and you don't get stuck on an old server for fear of not being able to migrate. This also serves as a "disaster recovery" document if a server fail.

2 Likes
14

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.