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. On Thu, Dec 11, 2025 at 6:56 PM Andrew Ayer <[email protected]> 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/20251211205603.8bd87602a610e93b33a3e290%40andrewayer.name > . > -- 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/CAFK%3DoS_yqPjgYA2eKcBEvbKOVwv3MhPH8%3DrUKq%2B9bAaOUpoD3A%40mail.gmail.com.
