A single user has reported this error from his work place and provided the following sceenshot. He does not have the problem form his cellphone (other IP since he is not using Wifi). I cannot reproduce this either from my office or other source IPs, be it with Chrome or Firefox.
What could I check to understand what may be wrong with my server or certificate configuration?
Could it be that the user is actually being attacked??!!
I ran this command:
echo | openssl s_client -connect www.postelo.fr:443 -servername www.postelo.fr 2>/dev/null | awk '/Certificate chain/,/---/'
It produced this output:
0 s:CN = www.postelo.fr
i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
1 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
i:O = Digital Signature Trust Co., CN = DST Root CA X3
My web server is (include version): nginx/1.10.3 (Ubuntu)
The operating system my web server runs on is (include version): Ubuntu 18.04 LTS
I can login to a root shell on my machine (yes or no, or I don’t know): yes
I’m not using any control panel to manage my site.
The version of my client is (e.g. output of
certbot --version or
certbot-auto --version if you’re using Certbot):
first: Your domain is ok - there is a valid Letsencrypt certificate.
Second: The screenshot looks bad, really bad.
Why? Check the date: The certificate is only 14 days valid.
No CA creates a certificate with such a small time.
So it's an Anti-virus-software or something like a deep inspection, that creates an own certificate to inspect the traffic.
-->> It's the problem of that user, not of your website.
PS: Now the domain check is ready - https://check-your-website.server-daten.de/?q=postelo.fr - your www is ok. Your non-www has the wrong certificate.
CN=mailconfig.ovh.net, OU=PositiveSSL, OU=Domain Control Validated
expires in 490 days
mailconfig.ovh.net, www.mailconfig.ovh.net - 2 entries
Better: Create one certificate with non-www and www, then use that.
The issuer listed there is “SSL Proxy Trusted CA 5d3eaa0f”, which strongly support’s Jürgen’s conclusion
It could be an appliance on the user’s network that is intercepting connections and that the user was expected to trust, but has not done so. One reason that this might be seen only on some sites and not others is that the appliance might not be configured to intercept every connection, e.g. perhaps it only actively intercepts connections to “unknown” sites or something.
Thanks a lot! And thanks about the non-www, I have to fix it.
The strange thing is that when I asked the user if I could speak to his sysadmin, he told me that they don’t have one… He works with a small group of people and so I thought they had a very simple network, but they probably have something slightly more complex, and nobody who really knows about it… It may be hard to fix…
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.