Following the announced rollout of the retirement of Google's non-temporally sharded logs, Google became aware of a set of certificates that no longer met Chrome's CT Policy, causing visitors to sites using those certificates to encounter TLS errors.
To temporarily mitigate this issue, Chrome is transitioning the following logs to ReadOnly, effective immediately:
Google 'Icarus' log (https://ct.googleapis.com/icarus/)
Google 'Pilot' log (https://ct.googleapis.com/pilot/)
Google 'Rocketeer' log (https://ct.googleapis.com/rocketeer/)
Google 'Skydiver' log (https://ct.googleapis.com/skydiver/)
Chrome is further investigating the impact of the previous retiring of these logs, and will work to mitigate that impact before retiring these logs again. However, we do still expect to Retire these logs (and expect Google to turn them down) in the near future.
While we are not yet sure of the timeline, members of the CT ecosystem should immediately remove reliance on these logs, and sites using impacted certificates should replace those certificates as soon as possible.
Note that this change will break an invariant of the Chrome CT state machine that Retired logs never transition to another state besides Rejected. Consumers of the log lists may wish to ensure that their tooling can handle this change.
Once we have completed our investigation, we will update ct-policy@ with a more concrete retirement timeline as well as much of a postmortem as we are able to provide publicly.
What does this mean for site operators?
This change should ensure that all previously-issued certificates containing SCTs from the impacted logs will validate properly in Chrome.
While all certificates will validate for now, it is still our intent to retire these logs. If you are serving certificates that embed SCTs from the above logs, we strongly encourage you to work with your CA to obtain new certificates with an updated set of SCTs. Your CA will ensure that newly-issued certificates use non-Retired and non-ReadOnly logs.
If you are currently serving SCTs via OCSP, then your CA must take appropriate action to update their OCSP pipeline to include a set of SCTs that meets the requirements outlined in the Chrome CT Policy. Once done, you must refresh the OCSP response stapled to the connection. Alternatively, you may choose to provide a policy-satisfying set of SCTs via another delivery mechanism.
What does this mean for CAs?
CAs should ensure that SCTs included in logs or provided from OCSP responses are including at least one SCT from a CT log that was Qualified, Usable, or ReadOnly at time of check. While certificates relying on the logs above currently meet these requirements, CAs are strongly encouraged to move off of these logs as soon as possible to ensure that you are still providing a policy-satisfying set of logs after the upcoming retirement.
CAs with existing certificates embedding SCTs from these logs are also encouraged to proactively reissue affected certificates to increase the resilience of these certificates to possible future log incidents.
If you are embedding SCTs from these logs in your OCSP responses, you must issue new OCSP responses with a new set of SCTs that meet the Chrome CT Policy requirements. Your customers must then begin to serve these new responses or provide a policy-satisfying set of SCTs via another mechanism.
What does this mean for Log Operators?
If you are operating a CT log not listed in the above Retirement announcement, you do not need to take any action.