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
Is there a firewall or anything ? can you āwgetā from other locations ?
nope, i can get to the wget from a pc behind the router
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 ?
yes, iām able to get files from other places with wget
Can you get the same file from github ?
wget https://raw.githubusercontent.com/certbot/certbot/master/certbot-auto
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
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
Personally I wrote getssl to automatically obtain and install certs on remote servers / routers etc. - itās one of the bash alternate clients
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.
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
Seems I decided to add the part about the wget key at the same time 
Letās see if that solves his problem.
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 )
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 Also it could be a (transparent) proxy on the way that actually fails to accept LE cert and closes the connection abruptly.
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 ?
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
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 
Aha, so indeed a tomato variety wget then
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
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
tomato can definitely do ssl. i have a StartSSL cert there now. works just fine
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)