Closed imrejonk closed 3 years ago
Thanks for reporting this. This appears to be log misbehavior, which I will report to the ct-policy mailing list.
This log is considered qualified by Apple's Certificate Transparency program (https://valid.apple.com/ct/log_list/current_log_list.json) so I'm going to leave it in monitor.json for the time being so people are notified of the certificates which it contains.
That sounds like an appropriate solution. Thanks for taking the time to report this to ct-policy. I'll keep an eye on the mailing list.
It turns out RFC 6962 is ambiguous about what logs should do in this particular case. I just pushed a new release of Cert Spotter, 0.11, which works around the ambiguity and will prevent this error. If you can't immediately upgrade, you can remove the file logs/BZwB0yDgB4QTlYBJjRF8kDJmr69yULWvO0akPhGEDUo/0-47DEQpj8HBSa-_TImW-5JCeuQeRkm5NMpJWZG3hSuFU.json
from your .certspotter
directory to suppress the error.
We just updated to Cert Spotter 0.11, and I can confirm that we are no longer seeing the HTTP 400 error messages. Thanks for taking the time to resolve this issue!
The default monitor.json file contains a
DigiCert Yeti2022 Log #2
entry. This CT log currently returns HTTP 400 Bad Request errors, which are logged by certspotter like this:We are seeing these errors since around two weeks. This CT log is currently not present in Google's log_list.json. I am not sure what the best course of action is, but it might be a good idea to omit this log from the monitor.json file until the log can be used with Certspotter.