Ongoing CT Logging Mistakes by CAs

[Andrew Ayer]

More than a week after my posting to the ct-policy mailing list (https://groups.google.com/a/chromium.org/g/ct-policy/c/VGgpEj92dCk), I'm still observing multiple CAs issuing certificates that do not work in some browsers (including some Firefox releases that are less than 70 days old) due to using CT logs that are not broadly Usable. I've observed recent problematic certificates from the following CAs:

Certum
Disig
GDCA
HARICA
Microsec
NAVER
SECOM
SSL.com
SHECA
certSIGN
emSign

In addition, I've noticed CAs making the following mistakes when embedding SCTs from static-ct-api logs:

1. Not copying the extensions field from the add-pre-chain response to the SignedCertificateTimestamp struct. Example certificate: https://crt.sh/?sha256=fca93c51d43df77dbc27c733b57051168d1e4dd8c6e33ea23e1f739b6e348a26

2. Not base64-decoding the extensions field when copying it to the SignedCertificateTimestamp struct. Example certificate: https://crt.sh/?sha256=709f1be6bd195f17cd18954cfa219f245ee5ccf928dbbf4ca19c9ae9750eb0c7

These SCTs will have invalid signatures and not count towards the minimum SCT requirement.

CAs need to treat the extensions field just like the other base64-encoded fields in the add-pre-chain response (id and signature) - base64-decode it and copy it to the SignedCertificateTimestamp struct. This should be done with both RFC6962 and static-ct-api logs; there is no need for CAs to treat them differently (except for satisfying the requirement that at least one SCT come from an RFC6962 log).

Regards,
Andrew

[Andrew Ayer]

On Thu, 11 Dec 2025 20:56:03 -0500
Andrew Ayer <ag...@andrewayer.name> wrote:

> 2. Not base64-decoding the extensions field when copying it to the
> SignedCertificateTimestamp struct. Example certificate:
> https://crt.sh/?sha256=709f1be6bd195f17cd18954cfa219f245ee5ccf928dbbf4ca19c9ae9750eb0c7

crt.sh still hasn't ingested this certificate, so here's an alternative link to download it as PEM:
https://api.certspotter.com/v1/certs/709f1be6bd195f17cd18954cfa219f245ee5ccf928dbbf4ca19c9ae9750eb0c7.pem

[Jeremy Rowley]

Is this a problem though? 

I'm not sure any browser requires CT logging. The MS policy almost did but was changed before it became effective. 

Apple's policy is close but the stated consequence is: "Certificates that fail to comply with our policy will result in a failed TLS connection, which can break an app’s connection to Internet services or Safari’s ability to seamlessly connect." This is just fine for WebPKI that doesn't care about Apple connections. 

CT isn't required in the Chrome policy. 

Mozilla policy doesn't state that CT logging is required - just that if you do log a cert its a binding intent to issue that cert. 

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20251211205603.8bd87602a610e93b33a3e290%40andrewayer.name.

[Alvin Wang]

Hello Andrew,

Thanks for sharing!  Today, SHECA received feedback from a customer regarding a CT alert issue with older versions of Chrome. This issue has now been resolved, and SHECA has temporarily disabled the log servers with a "qualified" status. The certificate issuance process is currently using three "usable" log servers: Nimbus2027, Tiger2027h1, and Elephant2027h1.

SHECA has reissued certificates for some of the affected customers.

CT demo site: cttest.certtools.cn
Certificate Transparency Policy Analyzer shows that the SCT in the current SHECA certificate is normal.

Thank you again for your support.
Alvin.Wang
SHECA

[Andrew Ayer]

On Fri, 12 Dec 2025 09:31:44 -0700
Jeremy Rowley <rowl...@gmail.com> wrote:

> Is this a problem though?
>
> I'm not sure any browser requires CT logging. The MS policy almost
> did but was changed before it became effective.
>
> Apple's policy is close but the stated consequence is: "Certificates
> that fail to comply with our policy will result in a failed TLS
> connection, which can break an app's connection to Internet services
> or Safari's ability to seamlessly connect." This is just fine for
> WebPKI that doesn't care about Apple connections.
>
> CT isn't required in the Chrome policy.
>
> Mozilla policy doesn't state that CT logging is required

I never said that this was a BR / root store policy violation.

But that doesn't mean it's not a problem. The affected CAs clearly weren't intending to issue unlogged certificates that don't need to work in browsers, as every affected certificate has SCTs. When the subscriber receives the certificate and finds it doesn't work in all browsers, that's presumably going to be a problem for them. <https://status.globalsign.com/incidents/49ndl5hz24h2> and Alvin's reply confirm that this has been causing subscriber impact. So, I thought CAs would want to know about it, and I think not all CAs are subscribed to ct-policy.

I also think that maybe it *should* be a root store policy violation if a certificate has an SCT extension but doesn't comply with CT policy. Root stores have an interest in avoiding breakage when they make changes. Unfortunately, without incident reports being required, there's no way to be sure the root cause is being addressed so that changes will be safer in the future.

Regards,
Andrew

[Jeremy Rowley]

Yeah - that makes sense. I agree with you that it should be a violation. There’s a difference between not intending to include CT and including CT incorrectly.

[Rob Stradling]

> I never said that this was a BR / root store policy violation.

I agree that neither the TLS BRs nor any root store policies require an SCT List extension to be present in any leaf certificates.  However, for every case where an SCT List extension is present in a leaf certificate...

> I also think that maybe it *should* be a root store policy violation if a certificate has an SCT extension but doesn't comply with CT policy.

...TLS BR 7.1.2.11.3 (Signed Certificate Timestamp List) requires:

"If present, the Signed Certificate Timestamp List extension contents MUST be an OCTET STRING containing the encoded SignedCertificateTimestampList, as specified in RFC 6962, Section 3.3.  Each SignedCertificateTimestamp included within the SignedCertificateTimestampList MUST be for a PreCert LogEntryType that corresponds to the current certificate."

https://datatracker.ietf.org/doc/html/rfc6962#section-3.3 requires that:

"The SCT data corresponding to the end-entity certificate from at least one log must be included in the TLS handshake, either by using an X509v3 certificate extension as described below..."

So, in my view, it is already a TLS BR violation to include an incorrectly-encoded SCT or a for-the-wrong-certificate SCT in an SCT List extension within a leaf certificate.

Both categories of mistake that you mentioned - not copying, and not base64-decoding, the SCT extensions - are examples of incorrectly-encoded SCTs in an SCT List extension within a leaf certificate, so they are TLS BR policy violations (and, therefore, they are also root store policy violations).

> I'm still observing multiple CAs issuing certificates that do not work in some browsers (including some Firefox releases that are less than 70 days old) due to using CT logs that are not broadly Usable.

It's worth noting that SCTs from logs that are Qualified (but not yet Usable) do contribute towards CT policy compliance.  So even if it did become "a root store policy violation if a certificate has an SCT extension but doesn't comply with CT policy", that still wouldn't solve the usability problem of Qualified SCTs being embedded before the log is broadly Usable.

Anticipating which logs will become broadly Usable (and when), and determining which logs actually are broadly Usable right now, across all of the CT-enforcing platforms, is a hard problem right now: one vendor's CT log list doesn't distinguish between Qualified, Usable, and ReadOnly; another vendor's CT log list sometimes takes many months longer than expected to move logs from Qualified to Usable.

---

From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> on behalf of Andrew Ayer <ag...@andrewayer.name>
Sent: 12 December 2025 17:26
To: Jeremy Rowley <rowl...@gmail.com>
Cc: dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Subject: Re: Ongoing CT Logging Mistakes by CAs

 

On Fri, 12 Dec 2025 09: 31: 44 -0700 Jeremy Rowley <rowleylaw@ gmail. com> wrote: > Is this a problem though? > > I'm not sure any browser requires CT logging. The MS policy almost > did but was changed before it became effective. 

ZjQcmQRYFpfptBannerStart

This Message Is From an Untrusted Sender

You have not previously corresponded with this sender.

Report Suspicious

 

ZjQcmQRYFpfptBannerEnd

On Fri, 12 Dec 2025 09:31:44 -0700
Jeremy Rowley <rowl...@gmail.com

> wrote:

> Is this a problem though?
> 
> I'm not sure any browser requires CT logging. The MS policy almost
> did but was changed before it became effective.
> 
> Apple's policy is close but the stated consequence is: "Certificates
> that fail to comply with our policy will result in a failed TLS
> connection, which can break an app's connection to Internet services
> or Safari's ability to seamlessly connect." This is just fine for
> WebPKI that doesn't care about Apple connections.
> 
> CT isn't required in the Chrome policy.
> 
> Mozilla policy doesn't state that CT logging is required

I never said that this was a BR / root store policy violation.

But that doesn't mean it's not a problem. The affected CAs clearly weren't intending to issue unlogged certificates that don't need to work in browsers, as every affected certificate has SCTs. When the subscriber receives the certificate and finds it doesn't work in all browsers, that's presumably going to be a problem for them. <https://urldefense.com/v3/__https://status.globalsign.com/incidents/49ndl5hz24h2__;!!J5K_pWsD!xqGTsO7CEYdlODDI-tZ7mEDGKH6veCtNPS_kr2sJjT1I58NqfvqKA3UjlCd5VIuTWma35g2rfHYPX8U$> and Alvin's reply confirm that this has been causing subscriber impact. So, I thought CAs would want to know about it, and I think not all CAs are subscribed to ct-policy.

I also think that maybe it *should* be a root store policy violation if a certificate has an SCT extension but doesn't comply with CT policy. Root stores have an interest in avoiding breakage when they make changes. Unfortunately, without incident reports being required, there's no way to be sure the root cause is being addressed so that changes will be safer in the future.

Regards,
Andrew

-- 
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion visit https://urldefense.com/v3/__https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20251212122617.3155fa43ed3049ffaa81a28a*40andrewayer.name__;JQ!!J5K_pWsD!xqGTsO7CEYdlODDI-tZ7mEDGKH6veCtNPS_kr2sJjT1I58NqfvqKA3UjlCd5VIuTWma35g2rtfS7Z1E$.

[Filippo Valsorda]

I feel like it would be great if CAs that encoded invalid SCTs could proactively file incident reports, regardless of whether we conclude they are required to do so or not.

It’s clearly an unintentional technical outcome that the community could learn from, and I trust that root programs would have more confidence in a CA that takes the issue seriously and formulates an effective remediation plan, than in one that avoids filing the incident report.

To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/MW4PR17MB4729252D77B355DDB26E5920AAAFA%40MW4PR17MB4729.namprd17.prod.outlook.com.