datacenter.iers.org SSL: CERTIFICATE_VERIFY_FAILED (Column year failed to convert: invalid literal for int() with base 10: '<!')

UPDATE: Update to astropy v5.0.4 or later.

This sounds so familiar. Do you recall, @mhvk or @eteq ? This is causing remote data job failure.

urllib.error.URLError: <urlopen error Verification of TLS/SSL certificate at
https://datacenter.iers.org/data/9/finals2000A.all failed:
this can mean either the server is misconfigured or your local root CA certificates
are out-of-date; in the latter case this can usually be addressed by installing
the Python package "certifi" (see the documentation for astropy.utils.data.download_url)
or in both cases you can work around this by passing allow_insecure=True,
but only if you understand the implications; the original error was:
[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed:
Hostname mismatch, certificate is not valid for 'datacenter.iers.org'. (_ssl.c:1131)>

Example log: https://github.com/astropy/astropy/runs/5695135215?check_suite_focus=true

[bjweiner]

Hi, I really would like to have a conversation about how to design the iers module so this does not keep happening. I found that setting the iers.conf.auto_max_age = None parameter did not work to suppress this out of range error, contrary to the documentation.

I believe that the high precision IERS A data is needed strictly to track the UT1-UTC difference, which is always less than 1 second. 1 second of time does matter for accurately pointing a telescope, but not so much for making telescope schedules with e.g. astroplan. Every time the iers module fails irrecoverably, multiple people at multiple telescopes go into panic mode in the middle of the night. It is my opinion that iers should fall back to low precision mode by default rather than having to set extra variables to bypass critical errors. I don’t know whether the best place to discuss this is here or on the astropy-dev slack workspace, but I would like to address this issue systematically rather than patching it around the edges.

[bjweiner]

This is causing astroplan to not work. There really needs to be a way to fall back gracefully to a lower time accuracy mode, rather than raising errors in astropy.iers that the user cannot resolve. I know that the code appears to contain fallbacks, but in practice they are not working. I can post the sequence of error messages if anyone finds it useful (not sure this thread is the right place).