Announcing the retirement of Sectigo Mammoth 2024 H1 Log effective January 29, 2024
Carlos Joan Rafael Ibarra Lopez
On January 9th 2024, Chrome's monitoring detected several SCTs that were not incorporated by the MMD on Mammoth 2024H1, including 2 that were not incorporated at all at the time of detection. We reported this to Sectigo and they started an incident investigation. Sectigo discovered that the log had experienced database corruption due to disk space issues. On January 11, Sectigo confirmed that they were not successful at recovering from the incident. Because of the failure to include submitted certificates in the log, we unfortunately have to retire Mammoth 2024H1.
Effective January 29, 2024, the Sectigo Mammoth 2024 H1 Log will transition to Retired, with the last ‘Qualified’ SCT having a timestamp no later than 1706486400, or 2024-01-29 00:00:00.000 in ISO 8601 format.
After January 29, 2024, SCTs from Sectigo Mammoth 2024 H1 will no longer count towards the CT Compliance requirements stating that at least one SCT must come from a CT Log that was Qualified, Usable, or ReadOnly at time of check. As such, after this point, it is no longer appropriate to serve SCTs from this Log in the TLS handshake, in OCSP responses, or embedded in certificates issued on-or-after 2024-01-29 00:00:00.000.
Embedded SCTs dated prior to 2024-01-29 00:00:00.000 will still satisfy CT Compliance requirements that permit SCTs to come from CT Logs that are Qualified, Usable, ReadOnly, or Retired at time of check; however, at least one other SCT must come from a non-Retired CT Log in order for the certificate to successfully validate in Chrome.
What does this mean for site operators?
If you are delivering SCTs embedded in the certificate, this should require no action on your part. All previously-issued certificates containing SCTs from these logs that complied with the Chrome CT Policy will continue to do so.
If you are currently serving SCTs via stapled OCSP, then your CA must take appropriate action to update their OCSP pipeline to ensure they are embedding a policy-satisfying set of SCTs. Once done, you must refresh the OCSP response stapled to the connections. Alternatively, you may choose to provide a policy-satisfying set of SCTs via another mechanism outlined in the Chrome CT Policy.
If you are currently delivering SCTs via a TLS extension, SCTs issued by these logs will no longer contribute towards CT Compliance. As such, you will need to update the SCTs included in the handshake to comply with the Chrome CT Policy in order to satisfy the requirements for SCTs delivered via TLS.
What does this mean for CAs?
If you are embedding SCTs in your certificates, SCTs from these logs for newly-issued certificates will no longer meet CT Compliance requirements stating that at least one SCT must come from a CT Log that was Qualified, Usable, or ReadOnly at time of check. To ensure that newly-issued certificates will be CT-compliant, you should update your CA’s CT log configuration to remove these logs while also ensuring that you are still logging to a policy-satisfying set of CT logs after the removal.
While it is not required by policy, CAs with existing certificates embedding SCTs from these logs may wish to proactively reissue affected certificates to increase the resilience of these certificates to possible future log incidents.
Finally, if you are embedding SCTs from these logs in your OCSP responses, you must issue new OCSP responses that replace these SCTs with new ones from a set of CT logs that satisfies the Chrome’s CT Policy. Your customers must then begin to serve these new responses or provide a policy-satisfying set of SCTs via another mechanism before the effective date above.
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.
Matt Palmer
> On January 9th 2024, Chrome's monitoring detected several SCTs that were
> not incorporated by the MMD on Mammoth 2024H1, including 2 that were not
> incorporated at all at the time of detection. We reported this to Sectigo
> and they started an incident investigation. Sectigo discovered that the log
> had experienced database corruption due to disk space issues. On January
> 11, Sectigo confirmed that they were not successful at recovering from the
> incident. Because of the failure to include submitted certificates in the
> log, we unfortunately have to retire Mammoth 2024H1.
>
>
> Effective January 29, 2024, the Sectigo Mammoth 2024 H1 Log will transition
> to Retired, with the last ‘Qualified’ SCT having a timestamp no later than
> 1706486400, or 2024-01-29 00:00:00.000 in ISO 8601 format.
that at least two[1] entries for which SCTs were issued have not been
incorporated, wouldn't it be prudent to make the last 'Qualified' SCT be
some time before the incident occurred? As it stands, it would be possible
for SCTs to be presented to Chrome, and accepted as valid, for entries that
were never logged. That, to me, seems like a bad idea -- the entire point
of an SCT is that it indicates that the certificate exists in the log.
- Matt
[1] As I understand it, there may be an unbounded set of other entries that
also meet this criteria, and there is no way to know for certain what
certificates those are, or even how many there are. Please correct me
if my understanding is incorrect.
Andrew Ayer
On Sat, 13 Jan 2024 00:11:34 +0000
Matt Palmer <mpa...@hezmatt.org> wrote:
> Given that the incident occurred on or around 2024-01-05, and it is
> known that at least two[1] entries for which SCTs were issued have
> not been incorporated, wouldn't it be prudent to make the last
> 'Qualified' SCT be some time before the incident occurred? As it
> stands, it would be possible for SCTs to be presented to Chrome, and
> accepted as valid, for entries that were never logged. That, to me,
> seems like a bad idea -- the entire point of an SCT is that it
> indicates that the certificate exists in the log.
>
> - Matt
Usable or ReadOnly at the *time of check*. No Mammoth 2024h1 SCT
will satisfy that requirement once the log transitions to Retired,
regardless of the disqualification timestamp. So even if a certificate
has an unincorporated Mammoth SCT, Chrome will have assurance that the
certificate is logged somewhere else.
The disqualification timestamp is used to decide whether an SCT from
a Retired log can count towards the minimum number of embedded SCTs.
The point this requirement is redudancy, to ensure certificates keep
working if a log fails. If the disqualification timestamp is set too
early, it will cause certificates to fail this check, defeating the
purpose. Rather, it should be set some time after the log has stopped
accepting new entries.
Regards,
Andrew