Install Lets Encrypt on tomato USB


#1

Hi

I tried the generic linux way but i get this error when i run wget

wget https://dl.eff.org/certbot-auto
Connecting to dl.eff.org (173.239.79.196:443)
wget: error getting response: Connection reset by peer

ANy ideas why? i tried this on a browser & it seems to work just fine


#2

Is there a firewall or anything ? can you ‘wget’ from other locations ?


#3

nope, i can get to the wget from a pc behind the router


#4

sorry, I should have been more precise. I meant can you use wget to obtain a file from elsewhere e.g. wget google.com and it just fails for wget https://dl.eff.org/certbot-auto ? (which would indicate a firewall issue ) or can you get files from everywhere other than certbot ?


#5

yes, i’m able to get files from other places with wget


#6

Can you get the same file from github ?

wget https://raw.githubusercontent.com/certbot/certbot/master/certbot-auto


#7

yes, i was able to do this

i also tried wget from a linux box inside the network & it failed there to.

but the github link works just fine


#8

i think the best way to install this on a router will be to generate these on a linux box & then transfer them over. since the router run a minihttpd & a micro version of linux, not sure if all dependencies can be installed. moreover its 5+ Mb in size


#9

Personally I wrote getssl to automatically obtain and install certs on remote servers / routers etc. - it’s one of the bash alternate clients


#10

The difference between your attempt to get the Certbot from EFF and from Github could be that EFF uses LE certificate, while Github uses DigiCert.

Considering that the last build of TomatoUSB is dated 2010, you might need to update CA bundle on that Linux for your connection to anything LE-secured started working.

P.S. Wget allows you to disable certificate checks with –no-check-certificate, even though normally it is not such a good idea.


#11

Hello @mobizent,

As @leader said, maybe it is a CA issue. I don’t recommend this but you could try to bypass the check certificate:

wget --no-check-certificate https://dl.eff.org/certbot-auto

Cheers,
sahsanu


#12

Seems I decided to add the part about the wget key at the same time :slight_smile: Let’s see if that solves his problem.


#13

An invalid SSL cert doesn’t usually give the error

Connecting to dl.eff.org (173.239.79.196:443)
wget: error getting response: Connection reset by peer

An invalid cert usually gives

ERROR: invalid certificate
requested host name ‘domain.com’.
To connect to domain.com insecurely, use `–no-check-certificate’.

I’d suspect the error is more likely to be routing or something to that specific IP (hence suggesting an alternate download connection )


#14

I would also expect the response to be different, but it’s worth a shot - we don’t really know what sort of possibly custom-built tomato-variety wget might be there :slight_smile: Also it could be a (transparent) proxy on the way that actually fails to accept LE cert and closes the connection abruptly.


#15

Just throwing another idea out there - could it be that EFF has too strict a set of cipher suite or protocol requirements for the archaic wget? I saw someone else mention it’s like 6 years old, and I saw in another thread older versions of wget were too dumb to grok SAN (which was invented like eight years ago), maybe they can also be too old to know how to speak TLS 1.0, or do AES rather than RC4, or whatever? It might not even understand SHA2 family hashes? I think if client & server can’t agree on some protocol requirements the whole SSL/TLS session just gets torn down so that there’s no chance you think everything is OK which might give this “Connection reset” error.

If that’s a real problem, obviously the EFF doesn’t want to drive their whole site’s requirements back to the bad old days of RC4 over SSL 3.0 with SHA1, but maybe a special “download certbot for old crappy systems” URL could be put up, either by the EFF or a volunteer since it shouldn’t be the main download site but just for people running software that’s older than South Sudan ?


#16

Very good thinking there, @tialaramex It could be the case of mismatching ciphers indeed, similar to how you could try using old PuTTY to SSH to Debian Jessie and would not be able to, unless upgraded PuTTY or inserted a legacy cipher into sshd.conf :slight_smile:


#17

this doesnt work on tomato as its based on busybox i guess.

wget: unrecognized option `–no-check-certificate’

But the wget –no-check-certificate https://dl.eff.org/certbot-auto worked on an ubuntu machine which it failed in earlier

so 50% success :wink:


#18

Aha, so indeed a tomato variety wget then :slight_smile:

There was an interesting commit related to busybox wget and dated 2010 too:

--- a/networking/wget.c
+++ b/networking/wget.c
@@ -546,6 +546,8 @@ int wget_main(int argc UNUSED_PARAM, char **argv)
 		"passive-ftp\0"      No_argument       "\xff"
 		"header\0"           Required_argument "\xfe"
 		"post-data\0"        Required_argument "\xfd"
+		/* Ignored (we don't do ssl) */
+		"no-check-certificate\0" No_argument   "\xfc"
 		; 

So perhaps it just can’t do SSL at all :slight_smile:

And it seems not much (though something) changed about that since - https://git.busybox.net/busybox/plain/networking/wget.c

In OpenWRT you could fix it by installing the normal wget with opkg. I believe Tomato should have something similar (ipkg) which might get you some modern wget/curl installed. Try googling for wget .ipk


#19

tomato can definitely do ssl. i have a StartSSL cert there now. works just fine


#20

I’m not saying that Tomato can’t do SSL per se. I’m just stating that busybox wget could not do SSL in 2010 (and dropped some options too) and that today it can do it only by calling a helper it seems (such as openssl s_client) :slight_smile: