Full Certificate Transparency by 30th April

Help
1

Hi LE,

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

Stebson

2

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

The work to embed SCTs is still happening, though.

1 Like
3

Issue has already been closed 4 days ago:
https://github.com/letsencrypt/boulder/issues/2244

Pull request was merged:
https://github.com/letsencrypt/boulder/pull/3521

Waiting for availability on staging.

1 Like
4

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:
                            49:B2:49:F7:B5:69:D8:C7:BC:AB:3F:5C:C1:F3:6E:64
                Timestamp : Jan 18 14:33:49.909 1970 GMT
                Extensions: none
                Signature : ecdsa-with-SHA256
                            30:44:02:20:5C:A5:08:0E:D3:44:DD:88:BA:93:FA:53:
                            9B:6E:FA:B9:3C:C5:5F:06:85:9E:29:F4:34:0A:72:1E:
                            F6:3E:52:9D:02:20:31:C0:D4:D2:A7:45:2E:71:B9:AD:
                            80:CA:25:B0:BF:45:A3:B5:F5:BB:79:A8:9D:18:E1:9A:
                            15:DB:63:A0:9E:15
            Signed Certificate Timestamp:
                Version   : v1(0)
                Log ID    : B0:CC:83:E5:A5:F9:7D:6B:AF:7C:09:CC:28:49:04:87:
                            2A:C7:E8:8B:13:2C:63:50:B7:C6:FD:26:E1:6C:6C:77
                Timestamp : Mar 16 19:51:50.667 2018 GMT
                Extensions: none
                Signature : ecdsa-with-SHA256
                            30:45:02:20:5E:F7:E6:33:22:86:93:EE:50:62:95:73:
                            14:57:FF:07:A2:A0:64:A5:3E:DD:15:93:20:2B:EA:27:
                            BD:E9:83:33:02:21:00:86:52:F6:9D:D6:D3:23:3F:57:
                            29:B8:A9:2C:18:07:79:24:24:D3:C4:3A:67:A0:B8:63:
                            35:B9:C6:75:2C:42:F6
3 Likes
5

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?

Cheers,
sahsanu

5 Likes
6

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

1 Like
7

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.

4 Likes
8

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

1 Like
9

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