Occasional errors with my LetsEncrypt certs

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

[ec2-user@(snip) letsencrypt]$ /opt/letsencrypt/letsencrypt-auto --versionRequesting to rerun /opt/letsencrypt/letsencrypt-auto with root privileges...
certbot 0.30.2

https://sendy.amazinglybrilliant.com.au works for me, and for most other people. But occasionally I get emails saying that it doesn't work. It uses a LetsEncrypt certificate.

One (relatively technical) user forwards one error from his Windows computer, which reads:

This site can’t provide a secure connection
sendy.amazinglybrilliant.com.au sent an invalid response.
Try running Windows Network Diagnostics.
ERR_SSL_PROTOCOL_ERROR

Another sends a screenshot from mobile Safari, which says "sendy.amazinglybrilliant.com.au may be impersonation sendy.amazinglybrilliant.com.au to seal your personal or financial information. Safari warns you when a website has a certificate that is not valid."

I can't see anything wrong with the certificate, using a few online test websites. Many, many users are using it without any issue. But I'm not really very clever with this kind of thing. Have I messed something up?

It would be really helpful if the users experiencing this issue could take a screenshot of the certificate details when this happens. This should be possible both on Windows and in mobile Safari, from the error screen.

Thanks. I’ll ask them to do that, and we’ll see what happens.

Right. The one on Windows says...

Strangely IE 11 provides more information than Chrome. I get

Turn on TLS 1.0, TLS 1.1, and TLS 1.2 in Advanced settings and try connecting to https://sendy.amazinglybrilliant.com.au again. If this error persists, it is possible that this site uses an unsupported protocol or cipher suite such as RC4 (link for the details), which is not considered secure. Please contact your site administrator.

But the various flavours of TLS are already turned on in browser settings. If I turn on SSL2 and SSL3 I get a different message. Firstly ESET tells me there’s encrypted traffic, but I tell it not to worry. I then get “there was a problem with this site’s security certificate”

The security certificate presented by this website was issued for a different website's address.

The security certificate presented by this website has expired or is not yet valid.

If I click on “continue to website (not recommended)” ESET again warns me of encrypted traffic, I tell it not to worry and I then get “this page can’t be displayed”.

ESET :confused:. Sounds like their traffic is being man-in-the-middled by their antivirus?

They should be able to see both the name of the certificate and its expiry date. These would be very valuable details.

Hi @JamesCridland

opend your site with IE11 and Edge, no problem.

So it sounds like a problem with this ESET, perhaps a replaced (invalide) certificate to see the traffic.

Send these users that link:

Disable SSL scanning in ESET Windows products

https://support.eset.com/kb3126/?locale=en_US&viewlocale=en_US

Users have to add root certificates and manage list of trusted certificates, if they enable SSL scanning.

Thanks, Juergen.

I haven’t used Windows since 2009, so I don’t really understand what ESET is.

What confuses me is the report from Mobile Safari that also says the certificate is duff.

The rest of my certificates are via Amazon - https://podnews.net as one example - and that unfailingly always works when the amazinglybrilliant one doesn’t. I’m aware I’m running “letsencrypt” rather than “certbot”, but it seems unconnected, am I right?

“This CA Root certificate is not trusted because it is not in the Trusted Root Certification Authorities store.”

The IP address mentioned here is the IP address of the box that hosts my website. He can see https://podnews.net (which is an Amazon certificate, hosted via Cloudfront but actually on this box).

I’m at a loss to know what’s going on here. Any advice? I’d rather not sling Cloudfront on the top of it, but that looks the only option.

So ESET creates an own certificates and is a Man in the Middle to break the SSL-connection.

This is really bad.

I’m a bear of little brain - perhaps you might help me.

Wouldn’t this break EVERY certificate? How come https://podnews.net works for him, but https://sendy.amazinglybrilliant.com.au doesn’t?

Screenshots there

https://support.eset.com/kb3126/?locale=en_US&viewlocale=en_US

say, that users can create trusted domains and other special rules. So these domains may work as expected.

Sorry, I don't quite understand yet. Reading up about ESET, it will perform a man-in-the-middle attack for SSL websites. And it has a list of exceptions, notably things like Google and Yahoo.

users can create trusted domains and other special rules

This user will not have create a trusted domain for https://podnews.net - I guarantee it (a tiddly little website that nobody cares about). Yet he can see that absolutely fine.

Hmm. I wonder whether there's a default exception for .net or .com, but not for .au ? I shall dig further.

Yes, this is the problem.

It's not a problem of your website, your config or your certificate.

It's a problem of ESET and ESET-users.

Thanks. I still don’t understand why it fails on the LetsEncrypt certificate for sendy.amazinglybrilliant.com.au but works on the podnews.net certificate. That’s the confusion that I have. Maybe the LetsEncrypt certificate is a bit fiercer in security than the Podnews one. Who knows…

Anyway, thanks for the help.

Can you look on your server for a ip-172-30-0-169 certificate? Maybe one of your backend servers is configured to use it?

Was Apache ever configured to use it?

Could some users have a cached DNS record with the wrong server’s IP address?

Could there be some sort of old Apache process using an older configuration? Like if you reloaded or restarted Apache but one of its processes didn’t?

1 Like

If so, perhaps there is an SNI failure somewhere (maybe even in ESET).

Or it may be more about perspective...
Do you use split-horizon DNS.
Is your system directly available from within your internal network?
[to include access via WiFi and VPN connections]

That seems likely - there is indeed a ip-172-30-0-169 certificate if you connect without SNI. On the other hand podnews.net works fine without SNI. So that would explain the difference.

You could try reordering your virtualhosts so that the sendy.amazinglybrilliant.com.au one comes first and is used as the default for clients that don't support SNI.

1 Like

@mnordhoff I’ve not configured an ip-172-30-0-169 certificate (though not very sure where to find it). Apache has never been configured to use it; this website has only ever had one IP address. Apache starts/stops relatively regularly (it’s part of my deployment script) and I think there’s been a reboot since, but happy (kind of) to reboot if that’ll help.

@rg305 I don’t know what split-horizon DNS is, so presume that I don’t use it. I only ever access this server, which is on Amazon EC2, by SSH to a public DNS name for it, and don’t have an internal network nor any VPN.

@jmorahan That’s odd - podnews.net has a standard AWS certificate, for CloudFront, and I thought they were SNI only…

It’s very possible that your OS automagically generated a self-signed certificate and configured Apache’s default HTTPS virtual host to use it.

Why it would sporadically be used remains a question.

Edit: Wait a second. If it’s because those clients don’t support SNI, that question was answered.

This may have come with the system (as a default - somehow)
Please show:
grep -Eri 'sslcert|servname|serveralias' /etc/apache2