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 <https://sslmate.com/labs/ct_policy_analyzer/>shows that the SCT in the current SHECA certificate is normal. Thank you again for your support. Alvin.Wang SHECA [image: 7c08070f5b22fcc08d5cf2b22005f0be.png] On Friday, December 12, 2025 at 9:56:09 AM UTC+8 Andrew Ayer wrote: > 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 > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/d2b2edf3-cd95-4ee0-b65d-1344d096f0a7n%40mozilla.org.
