Sympl-ssl fails: Failed: SSL_connect returned=1 errno=0 state=error: wrong version number

Problem Description

SSL certificates won’t update.

Any Error Messages

    The current set is no longer valid for this domain.
    No valid certificate sets found.
    Fetching a new certificate from LetsEncrypt.
    !! Failed: SSL_connect returned=1 errno=0 state=error: wrong version number

Environment

  • Sympl Version [10.0]:
  • Sympl Testing Version? [No]
  • Debian Version [Buster]:
  • Hardware Type? [Pi]
  • Hosted On? [lan]

I’m not having any issues with normal hosted servers when forcing a renew for a cert.

And that error seems to be appearing when sympl-ssl tries to connect out to Let’s Encrypt, before you get the Requesting verification for example.com from https://acme-v02.api.letsencrypt.org/directory message, and a quick Google suggests it’s from a miss-matched SSL protocol/crypt

I’d check that the Pi has full access out and in (not going through a proxy or anything), but if that’s still a problem, I’ll see if I can replicate it with a hosted Pi.

Ping seems to connect OK

$ ping acme-v02.api.letsencrypt.org
PING ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com (172.65.32.248) 56(84) bytes of data.
64 bytes from 172.65.32.248 (172.65.32.248): icmp_seq=1 ttl=50 time=55.8 ms

That may look slow to you, but it’s using Three 4G mobile broadband, which has terrible ping times.

And I can connect in to it from my phone using the DDNS hostname, so that’s not broken.

Other servers seem fine. That’s the only pi I have running sympl

Ping is very different to a full-on TLS connection - it may be there’s NAT or transparent proxying or similar on the mobile connection, that won’t show up that way.

If you want to send me a private message with some details like the hostname, and I should be able to diagnose a little better.

@hairydog, thanks for providing the info privately, that was invaluable!

A fair bit of diagnostics later, I’m fairly confident the issue is the connection being used, specifically Three 4G Mobile broadband - I’m able to replicate the same issue on a VM on the end of a Three connection, but only very intermittently, and only on that connection, not a separate DSL connection, or another mobile network.

It seems to be something that the network is doing with outgoing traffic, which is breaking some (but apparently not all) connections, which matches what I’ve personally experienced a few times in the last few months with Three.

I suspect it’s something related to their content filtering, so would probably suggest trying a VPN or another network to see if that helps.

Just for confirmation, here’s the output of sympl-ssl being run on freshly imaged Pi on the Mythic Beasts hostedpi.com domain:

root@sympl:~# sympl-ssl --verbose
Applying IPv6 only workaround...
* Examining certificates for sympl.hostedpi.com
	Current SSL set 0: self-signed for /CN=sympl.hostedpi.com, expires 2021-07-30 11:22:05 UTC
	The current set is no longer valid for this domain.
	No valid certificate sets found.
	Fetching a new certificate from LetsEncrypt.
	Requesting verification for sympl.hostedpi.com from https://acme-v02.api.letsencrypt.org/directory
	Successfully verified sympl.hostedpi.com
	Requesting verification for www.sympl.hostedpi.com from https://acme-v02.api.letsencrypt.org/directory
	Successfully verified www.sympl.hostedpi.com
	Successfully fetched new certificate and created set 1
	Rolled over to SSL set 1
Removed IPv6 only workaround

I tried a different APN, made no difference. The thing about this APN is that it gives a public IP that is routeable.

But I tried a VPN. I went for Windscribe because it is free and seems easy, and it seems to work OK. But I’m still getting
The current set is no longer valid for this domain.
No valid certificate sets found.
Fetching a new certificate from LetsEncrypt.
!! Failed: SSL_connect returned=1 errno=0 state=error: wrong version number

despite the routting being very different:
traceroute acme-v02.api.letsencrypt.org
traceroute to acme-v02.api.letsencrypt.org (172.65.32.248), 30 hops max, 60 byte packets
1 10.116.158.1 (10.116.158.1) 63.255 ms 63.206 ms 64.044 ms
2 185.212.168.131 (185.212.168.131) 64.149 ms 64.135 ms 64.121 ms
3 te-2-5-0.bb1.lon1.uk.m247.com (89.44.212.126) 63.883 ms 63.873 ms 63.860 ms
4 lonap.as13335.net (5.57.81.75) 63.956 ms 82.524 ms 63.890 ms

That idiot Trump has a lot to answer for. Three is really screwing up their networking.
They chose the best, most reliable and cheapest option: Huawei.
And now they’re struggling to refactor everything.

Back home after a few weeks away, I’ve changed the MTU on the router to 1400.
Since then, the SSL system has started working again. However, I don’t know if this is because Three have sorted their network out, or if the lower MTU fixed it.
Can you try again and see if it’s fixed for you on Three?

I’ve been seeing fewer issues when using Three recently, and HTTPS connections seem to be okay for me for the last few weeks, but I’ve also changed quite a few things locally, so can’t be entirely sure.

1 Like