SSL Exceptions on client connections

Help
#1

My domain is:
easysms.gr

I ran this command:

It produced this output:

My web server is (include version):
Apache/2.4.29 (Ubuntu)

The operating system my web server runs on is (include version):
Ubuntu 18.04.4 LTS

My hosting provider, if applicable, is: serverloft.eu

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

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

Three days ago i noticed that some client connection attempts threw SSL Exceptions.
Made an Google Apps Script to make requests all night and 16% of all requests ended in failure to connect due to ssl exceptions.
The same goes with the browser, it has very abnormal behaviour. Refuses to connect and with refresh it does!

Please advice
Thank you

#2

I fail to understand what advice you are seeking.
Nor do I see the relevance of whatever problem you may be experiencing to the cert being used.
This forum is geared towards helping people get/renew/automate LE certificates.
And without seeing what was being used in your "Google Apps Script" and the errors it produced, it is nearly impossible to give you any useful advice.

1 Like
#3

If you follow few links it will throw you at some point a connection refusal page.
It is not a consistent behaviour (refresh usually works). Around 15% of calls don't get through.
It looks like a certificate error, but only for few connections. I couldn't find a more appropriate topic to post.
Thank you for the prompt reply.

#4

I just went to your site. It loaded very fast and is secure.
However, going to your site a second time threw the "not secure" error.
The URL I used was easysms.gr
This is the URL that loaded (secure) the first time :
https://easysms.gr/app/sms-marketing.php?ModPagespeed=off

Using the same easysms.gr link a second time I was sent to this URL the second time:

  • https://easysms.gr/app/sms-marketing
    That gave the "not secure" error.
    Notice the missing .php?ModPagespeed=off? That was the only difference I saw.

Trying a 3rd time I again reached the secure URL shown above.
Using http://easysms.gr I was forwarded to the https version of the site.
Using https://www.easysms.gr I was forwarded to the https version of https://easysms.gr.
Using http://www.easysms.gr I was forwarded to the https version of the site https://easysms.gr.

So there was one instance when it loaded as unsecure and that was with the missing tail end of the URL. This isn't a problem with the certificate, but with your configuration. Apparently, your server is serving an incomplete URL redirect once in a while. Something is buggy.

#5

It looks like there might be a load balancer with multiple server instances behind it, where some of the instances have had the renewed certificate updated successfully and others haven't. In the case where it fails, it sends this recently-expired certificate:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            04:df:8d:4c:dd:15:60:ab:0a:b5:e5:9a:44:52:70:54:9e:c3
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
        Validity
            Not Before: Sep 11 16:14:29 2020 GMT
            Not After : Dec 10 16:14:29 2020 GMT
        Subject: CN = easysms.gr
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:e1:29:7c:04:b0:07:85:3c:f8:9f:ff:b6:5b:30:
                    4b:74:9f:fd:3a:17:c3:38:8b:f3:df:a3:35:53:de:
                    76:d9:5f:a9:a6:6e:37:d9:cc:79:67:3b:08:e7:00:
                    51:17:9e:9c:23:d8:96:89:4a:79:92:28:f3:dc:82:
                    42:33:7b:6a:35:f6:8f:ff:b3:dc:5b:0b:a8:23:92:
                    f9:ae:09:82:be:8d:ba:3a:bc:68:98:79:3f:e8:34:
                    c6:1e:8f:84:9a:41:21:dc:98:50:7b:54:c2:48:7f:
                    f5:88:e4:df:a8:be:f9:7c:0a:4b:6c:a2:35:64:94:
                    95:e1:c3:9b:06:bc:40:25:e2:f8:77:5f:c9:ce:d7:
                    8b:c0:78:0d:08:15:1b:64:5c:6f:9f:55:ea:06:4d:
                    ee:f3:23:07:60:1c:90:1b:a9:d5:60:cc:e3:d9:58:
                    66:3e:57:7f:95:e7:84:2d:12:62:14:9b:b9:bb:99:
                    55:cd:5d:c8:ff:93:89:5a:46:3a:fb:a6:d6:51:78:
                    86:5c:2b:d7:56:dc:4c:c3:8a:c7:74:c2:1a:a0:25:
                    d9:4a:0d:33:da:bc:a0:24:85:01:b4:2c:80:a1:8e:
                    96:53:c8:78:7e:cb:5a:76:af:f0:2f:07:fc:76:a6:
                    f6:73:91:93:46:4e:ad:77:71:3d:4a:85:77:6d:1b:
                    e8:51
                Exponent: 65537 (0x10001)
[...]

instead of the updated one which it sends most of the time.

1 Like
#6

Also I think @_az has pointed out that there can be a weird form of breakage for Apache where different Apache server processes keep running with the same bound socket reference, while they have separate copies of the certificate and key in their memory. That is basically to say that Apache is actually able to "restart" where both the old and the new configuration are active at the same time in different copies of Apache that are sharing a port.

Needless to say, that is a fairly significant bug in Apache! But it does seem to happen.

If that's the problem, then you probably want to do something like

sudo service apache2 stop
sudo killall -9 apache2
sudo service apache2 start

which should probably fix it. If so, maybe we need to encourage the Apache developers to figure out how to prevent this bug from happening...!

2 Likes
#7

Restarting Apache fixed the problem.
In deed 15% of Apache processes were serving the old certificate.
Thank you so much for the highly technical skills!

2 Likes
#8

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