Wyvern 2026h1 contains certificates beyond expiry range

[Andrew Ayer]

According to Wyvern 2026h1's log application, the expiry range is:

Start Inclusive: 2026-01-01 00:00:00 UTC
End Exclusive: 2026-07-01 00:00:00 UTC

However, since yesterday I have detected over 3,000 certificates with expiration dates beyond this range. For example, the certificate at index 154761761 expires at 2026-07-01 15:56:53 UTC.

Is this a log misconfiguration or is the application wrong?

Regards,
Andrew

[Rick Roos]

Hi Andrew,

Thanks for bringing this to our attention.  It does appear the original application in the chromium bug ticket had a typo for the End Exclusive dates for the Wyvern 2026h1, Wyvern 2026h2, Sphinx 2026h1, and Sphinx 2026h2 logs.  The logs have always been configured to stop accepting entries for the h1 logs on July 7th and Jan 7th for the h2 logs and thus have entries up to those dates.

I've updated the tickets here:

https://issues.chromium.org/issues/353924009

https://issues.chromium.org/issues/354025369

We find it prudent to not change the logs configuration and keep them at what they have always been set at and to wait for feedback on the next steps on how this can be corrected.

Thanks,

Rick

--
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/20250530091849.78ef80dfb6bd5012dc323038%40andrewayer.com.

[Andrew Ayer]

On Fri, 30 May 2025 12:56:37 -0600
Rick Roos <rick...@gmail.com> wrote:

> We find it prudent to not change the logs configuration and keep them
> at what they have always been set at and to wait for feedback on the
> next steps on how this can be corrected.

I tried picking a few sites at random which are serving certificates expiring past 2026-07-01 00:00:00 UTC and embedding SCTs from Wyvern 2026h1, and when I try connecting to them from Safari in iOS, I get a certificate error. For example, https://monarchtherapycenter.net

It appears Apple clients are enforcing the expiry range and won't consider these SCTs compliant. I vaguely remember Apple confirming this behavior at one point.

I assume it's going to take a while for any updates to the log list to propagate to clients. Therefore, it's probably more prudent for you to change the configuration to match the original ranges.

CAs which have been submitting precertificates to these logs without any regard to their stated certificate expiry ranges should review their practices and replace any impacted certificates.

Regards,
Andrew

[Rick Roos]

Hey Andrew,

We had more internal discussions and we agree with your assessment that reconfiguring the logs will help those CAs that are inadvertently submitting pre-certificates past the dates that a browser may accept the SCT as valid.  We just finished reconfiguring the logs so they now reject certificates that are not within the published date ranges at https://www.gstatic.com/ct/log_list/v3/log_list.json.

Again, thanks for your feedback.

Rick

[Clint Wilson]

On May 30, 2025, at 12:39 PM, Andrew Ayer <ag...@andrewayer.name> wrote:

On Fri, 30 May 2025 12:56:37 -0600
Rick Roos <rick...@gmail.com> wrote:

We find it prudent to not change the logs configuration and keep them
at what they have always been set at and to wait for feedback on the
next steps on how this can be corrected.

I tried picking a few sites at random which are serving certificates expiring past 2026-07-01 00:00:00 UTC and embedding SCTs from Wyvern 2026h1, and when I try connecting to them from Safari in iOS, I get a certificate error.  For example, https://monarchtherapycenter.net

It appears Apple clients are enforcing the expiry range and won't consider these SCTs compliant.  I vaguely remember Apple confirming this behavior at one point.

This is correct and expected behavior currently. I’ve confirmed the Log List (https://valid.apple.com/ct/log_list/current_log_list.json) is configured with the temporal interval specified at the time of submission to the Apple CT Program.

Thank you!

-Clint

I assume it's going to take a while for any updates to the log list to propagate to clients.  Therefore, it's probably more prudent for you to change the configuration to match the original ranges.

CAs which have been submitting precertificates to these logs without any regard to their stated certificate expiry ranges should review their practices and replace any impacted certificates.

Regards,
Andrew

--
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/20250530123911.9d02bab87501379202934e7f%40andrewayer.name.

[Andrew Ayer]

On Fri, 30 May 2025 16:04:36 -0600
Rick Roos <rick...@gmail.com> wrote:

> We had more internal discussions and we agree with your assessment
> that reconfiguring the logs will help those CAs that are
> inadvertently submitting pre-certificates past the dates that a
> browser may accept the SCT as valid. We just finished reconfiguring
> the logs so they now reject certificates that are not within the
> published date ranges at
> https://www.gstatic.com/ct/log_list/v3/log_list.json.

Sounds good. In the end, there were 5070 out-of-range precertificates logged to Wyvern 2026h1, and 9 logged to Sphinx 2026h1. All issued by GoDaddy.

Regards,
Andrew

[Andrew Ayer]

On Fri, 30 May 2025 16:27:15 -0700
"'Clint Wilson' via Certificate Transparency Policy"

<ct-p...@chromium.org> wrote:

> > It appears Apple clients are enforcing the expiry range and won't
> > consider these SCTs compliant. I vaguely remember Apple confirming
> > this behavior at one point.
>
> This is correct and expected behavior currently. I've confirmed the
> Log List (https://valid.apple.com/ct/log_list/current_log_list.json)
> is configured with the temporal interval specified at the time of
> submission to the Apple CT Program.

Thanks for (re)confirming this Clint! Is the lower bound of the range also enforced client-side?

Regards,
Andrew

[Clint Wilson]

That is also correct (for reference: https://github.com/apple-oss-distributions/Security/blob/3dab46a11f45f2ffdbd70e2127cc5a8ce4a1f222/trust/trustd/CertificateTransparency.m#L223-L234)

Cheers,

-Clint