no valid post 2024 ct_log urls the default ct_submit_log providers

[kbresin]

My entire automation broke once I generated my first certificate with an end date in 2024.

This is because line the two default (and many of the others) ct_submit_logs options only have start,end dates that go from 2020-01-01 through 2024-01-01.

Since it uses the "until_after" of a certificate, this causes the _get_ct_log to fail to find any valid urls for most of the configured ct_submit_log providers listed.

So it returns ct_log = None in fetch_sct, which results in raising a config error code:

    else:
        self._error('Unknown CT log: ', ct_log_name, '\n', code=ErrorCode.CONFIG)

[kbresin]

Also there is a typo in the start/end entries for the 4+ lets_encrypt_oak entries. they only have HH:MM (00:00) and the parsing logic expects HH:MM:SS

File "/opt/python3.9/lib/python3.9/_strptime.py", line 568, in _strptime_datetime tt, fraction, gmtoff_fraction = _strptime(data_string, format) File "/opt/python3.9/lib/python3.9/_strptime.py", line 349, in _strptime raise ValueError("time data %r does not match format %r" %

[plinss]

Thanks for the update, I'll get the default CT logs updated soon. In the meanwhile, note that you can specify your own CT log information in the config file: https://github.com/plinss/acmebot#certificate-transparency-logs

[plinss]

Fixed in fa847e5

[kbresin]

Thanks for the super fast turn around, that fixed it!

[kbresin]

It might be nice if there was a more specific error message in the case where a ct log submit source does have a specified config but no valid timeranges were found, as "Unknown CT log google_argon" ended up being a very confusing and misleading message.