Full Certificate Transparency by 30th April


Hi LE,

Will you be able to provide full Certificate Transparency for all issued certs by the 30th of April?



I believe Let’s Encrypt already fully logs all certificates.

The work to embed SCTs is still happening, though.


Issue has already been closed 4 days ago:

Pull request was merged:

Waiting for availability on staging.


Obviously available on staging now, got certificate with two SCT:

        CT Precertificate SCTs:
            Signed Certificate Timestamp:
                Version   : v1(0)
                Log ID    : DD:99:34:FC:A5:E7:24:80:C9:56:68:7D:81:34:99:08:
                Timestamp : Jan 18 14:33:49.909 1970 GMT
                Extensions: none
                Signature : ecdsa-with-SHA256
            Signed Certificate Timestamp:
                Version   : v1(0)
                Log ID    : B0:CC:83:E5:A5:F9:7D:6B:AF:7C:09:CC:28:49:04:87:
                Timestamp : Mar 16 19:51:50.667 2018 GMT
                Extensions: none
                Signature : ecdsa-with-SHA256


Hi @tob,

I’ve just created one and it has the same timestamp as yours for one of the signed certificate timestamp Timestamp : Jan 18 14:33:49.909 1970 GMT which seems wrong. @cpu, could you please take a look?



We’ll take a look, thanks for the report.


Our staging infrastructure submits to a faked-out test log, ct-test-srv, which we also use in our continuous integration pipeline. That test log was generating incorrect timestamps (Unix epoch seconds instead of milliseconds). This would not affect generation of SCTs against a real log that was returning accurate timestamps, but it reveals that a misbehaving could lead Boulder to generate certificates with nonsensical timestamps. I’ve submitted a PR to add better checks in Boulder and in our automated tests: https://github.com/letsencrypt/boulder/pull/3570. Thanks for flagging this @tob and @sahsanu!

BTW, if you are interested in why one of the embedded SCTs is correct: Our staging environment also submits to Google’s “testtube” log, which generates correct timestamps.

Our staging environment should now be producing certificates whose embedded SCTs have correct timestamps.


Can confirm this:
Log ID : DD:99:34:FC:A5:E7:24:80:C9:56:68:7D:81:34:99:08:
Timestamp : Mar 17 06:15:27.769 2018 GMT
Log ID : B0:CC:83:E5:A5:F9:7D:6B:AF:7C:09:CC:28:49:04:87:
Timestamp : Mar 17 06:15:28.690 2018 GMT


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.