Ah yes, then you do have a NAT router. But the MiSTer should also "just work" from behind that device, as long as it gets a locally unique 192.168.xxx.xxx address. This could only really go wrong if another device on the same segment uses the MiSTer's MAC address, like a second MiSTer on the same network could do.
Plugging the MiSTer into the wall directly will only work if you set its MAC address to be the same as your router's public interface. In that case the MiSTer device will simply impersonate the router to the upstream switch and you'll be put into the same upstream VLAN directly. As long as you're not using PPPoE or Radius/802.1x authentication before you get a connection, chances are quite high that the ISP determines your device from its MAC address and puts it in a VLAN based on that. But let's not go there. It's unsafe to give a MiSTer a publically routable IP with no firewalling in front of it. Stick with your router.
From behind your NAT router, given that you have a working 192.168.xxx.xxx address on the MiSTer, you should be able to at least connect locally. You confirmed that as connectivity to your CIFS shares apparently does work and remote connectivity is also there. So what remains for me as a logical culprit would be DNS. Can the MiSTer, once connected behind the NAT router, resolve a hostname that it doesn't know about yet? You can test that with ping. It may fail the actual ping because ICMP tends to get blocked a lot on the internet, but at least it should give you an IP address for the other side that it's sending packets to. If it gets to that stage, DNS works.
Looking into the script itself.. What I'm seeing the downloader script do, is pull the cacert.pem file from a hard-coded location:
https://curl.se/ca/cacert.pem. That URL is behind a CDN from Fastly so the target IP changes all the time but it should be nothing special, just a plain HTTPS-request. I can even download that file from work, with their strict firewall/security crud going on. Do make sure that the file you pull from there is unmangled by things like Windows line endings, character encoding fudgery etc. if you download it on another computer than the MiSTer itself. The easiest way to prevent this is to cd into /etc/ssl/certs on your MiSter itself and then wget the file directly.
The script uses that file to validate the upstream URL's it connects to and the errors you're seeing are the script complaining that A) the cacert.pem file is somehow corrupt and B) it's unable to correct the situation.
What it tries to do at step B, is simply delete the file. Since you're running as root, permissions can't be the issue here. The script, however, is not smart enough to deal with missing directories. Are you 100% positive that /etc/ssl/certs is an existing directory on your MiSTer and that the cacert.pem file is in there? Couldn't hurt to limit permissions to 755 on the file itself and change the owner to root since some tools tend to check on that (even if redundant on MiSter).
I don't have my MiSTer handy right now (at work.. lunch break) but I'll see if I can reproduce the issue on mine tonight and what's needed to fix it.
