Unable to establish SSL connection?

[The Eternal February]

Setting the scene: I've got a rather Heath Robinson (US=Rube Goldberg) combination .bat and .pl script that I can fire off to get my current nation API information/etc via wget, in (what I hope is!) suitably throttled to not annoy the API gods. No apparent complaints, anyway, except occasionally when I've double-tapped the starting icon (and in its current incarnation the batching/scripting attempts to catch such refusals, anyway, to let me know I might have done this sort of thing, plus a few other bits and pieces in the code to additionally try to stop me before it even gets that far), and I've always resisted the urge to have it happen by potentially error-prone scheduling without my even asking of it.

No unusual problems last night(/early this morning), as per the stored log of a given transaction:

--2020-03-29 00:11:28-- https://www.nationstates.net/cgi-bin/ap ... l_February
Resolving http://www.nationstates.net... 104.25.62.43, 104.25.61.43
Connecting to http://www.nationstates.net|104.25.62.43|:443... connected.
WARNING: cannot verify http://www.nationstates.net's certificate, issued by `/C=US/ST=CA/L=San Francisco/O=CloudFlare, Inc./CN=CloudFlare Inc RSA CA-1':
Unable to locally verify the issuer's authority.
WARNING: certificate common name `sni.cloudflaressl.com' doesn't match requested host name `www.nationstates.net'.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Date: Sun, 29 Mar 2020 00:11:34 GMT

...and then the rest of the header, and the XML page in its own separate file.
The Cloudflare stuff is usual, I find, when employing the wget method. That's not an issue I think I need to care about.

I've never actually seen a need to hack that issue away for this particular situation (it's set to plough on anyway and ignore it, the above request being entirely without meaningful security issues), though I've now started to have another look at the wget params I use, anyway and perhaps I could see if there's a fresher version of the GNU wget (or other) that I can use - or maybe just switch over to Perl's own internal socket-setting, if that's better, rather than (as now) just automate the system-level command calling with it and then reading the files so grabbed.

Today, though:

--2020-03-29 14:50:14-- https://www.nationstates.net/cgi-bin/ap ... l_February
Resolving http://www.nationstates.net... 104.25.62.43, 104.25.61.43
Connecting to http://www.nationstates.net|104.25.62.43|:443... connected.
OpenSSL: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
Unable to establish SSL connection.

That's the entire log, and the 'saved page' file is null-sized obviously.
The headline time there is BST (as I presume a successful return header would have reported), our clocks having gone forward. Seems no obvious reason why that should change how things work.

Tried a few other places (manually tried addresses I'd just been reading in a browser*, but exact same format of wget command) and no complaints, but also didn't hit Cloudflare with anything I tried.

* - The URI does return Ok on each and every browser I try, so it isn't a cmplete and utter blanket fault over my connection route, but I don't fancy rewriting to use a firefox.exe/whatever call as my gateway utility for any number of reasons I could mention.

It could just be time/long-overdue to do an actual efficient (but still throttled!) rewrite of the whole job lot in monolithic Perl/Python/whatever or even something intended to be compilable. Perhaps with a nice GUI front-end/etc. But I might need to know I'm not subject to something outside my control (Cloudflare?) having changed overnight (or not, if it is unawareness of DST that caused it) so I don't just hit the same problems anyway no matter how I usefull try to converse with the API.

Thoughts? About the overnight error, ideally, though no doubt there are other comments to be made about my approach.

[[violet]]

SSL is such a nightmare. It could be a bunch of things, but my first guess is that there's no overlap between the SSL protocols offered by your script and the SSL protocols supported by CloudFlare - since these change fairly often over time as cryptographic standards evolve. So possibly you were relying on an old one that CloudFlare have recently dropped support for. If this is the case, upgrading your system to newer versions might help.

[The Eternal February]

Aye, I feared it might be something like that, even though some of the stuff I've been using are only 12 years old*, and the hardware it runs on is almost post-Millenium! I'd actually be personally happy in this instance falling back and completely eschewing SSL, but of course if I do I know that it'll get "HTTP/1.1 301 Moved Permanently"ed to the HTTPS address and thus failure.

* - I have socks older than that. In fact I probably have very few socks that aren't!

(Yes, I see the need to continually improve things. We have to strive to defeat entropy and thus the inevitable heat-death of the universe, after all!)

Right, off to find something newer but just as nice to use, I suppose, at least as a stop-gap.

/merges back into the forum undergrowth...

[Bowzin]

SSL is such a nightmare.

How do I like a post?