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.
