Add support for printing SCT extension data

[marten-seemann]

Tiled transparency logs use SCT extensions to encode the position of the certificate in the CT log.

This PR makes no attempt to decode the SCT extension (same as OpenSSL). It just makes us stop pretending that SCT extensions don't exist.

openssl output:

        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Subject Key Identifier:
                DD:D6:A2:71:0E:43:4D:69:B6:C2:1A:FF:3A:5E:E1:9B:25:9F:12:B0
            X509v3 Authority Key Identifier:
                9B:CE:E9:3E:53:61:D9:C5:7B:56:8F:6F:15:D1:C6:D3:AA:D9:1C:D9
            X509v3 Subject Alternative Name:
                DNS:localhost
            1.3.6.1.4.1.37476.9000.64.1:
                0......acme-da..
            CT Precertificate SCTs:
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 98:74:49:A3:22:91:E3:69:6C:B0:02:00:D2:9D:39:7A:
                                21:B2:4E:3A:EA:31:F5:73:7E:FF:DE:0C:34:89:9C:1F
                    Timestamp : Aug 15 14:40:11.012 2025 GMT
                    Extensions: 00:00:05:00:00:00:04:18
                    Signature : ecdsa-with-SHA256
                                30:65:02:30:28:59:89:A5:68:B8:9B:61:D7:E0:41:2D:
                                F6:27:39:09:3B:FF:3E:D8:42:3E:2C:EA:39:22:F8:8A:
                                A8:D0:15:EE:B0:DE:50:6F:5E:3F:74:AF:8F:94:FC:B8:
                                CA:FF:15:58:02:31:00:F2:4B:39:AC:59:25:DE:7E:2D:
                                0B:02:59:6A:D6:6A:85:B2:68:E7:61:D2:72:0D:E8:0E:
                                D4:DF:DA:22:78:0B:C3:08:E9:98:C6:18:8C:08:66:F3:
                                A9:D0:08:6A:C8:D6:CD

step output:

        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage:
                Server Authentication, Client Authentication
            X509v3 Subject Key Identifier:
                DD:D6:A2:71:0E:43:4D:69:B6:C2:1A:FF:3A:5E:E1:9B:25:9F:12:B0
            X509v3 Authority Key Identifier:
                keyid:9B:CE:E9:3E:53:61:D9:C5:7B:56:8F:6F:15:D1:C6:D3:AA:D9:1C:D9
            X509v3 Subject Alternative Name:
                DNS:localhost
            X509v3 Step Provisioner:
                Type: ACME
                Name: acme-da
            RFC6962 Certificate Transparency SCT:
                SCT [0]:
                    Version: V1 (0x0)
                    LogID: mHRJoyKR42lssAIA0p05eiGyTjrqMfVzfv/eDDSJnB8=
                    Timestamp: Aug 15 14:40:11.012 2025 UTC
                    Extensions:
                      00:00:05:00:00:00:04:18
                    Signature Algorithm: SHA256-ECDSA
                      30:65:02:30:28:59:89:a5:68:b8:9b:61:d7:e0:41:2d:f6:27:
                      39:09:3b:ff:3e:d8:42:3e:2c:ea:39:22:f8:8a:a8:d0:15:ee:
                      b0:de:50:6f:5e:3f:74:af:8f:94:fc:b8:ca:ff:15:58:02:31:
                      00:f2:4b:39:ac:59:25:de:7e:2d:0b:02:59:6a:d6:6a:85:b2:
                      68:e7:61:d2:72:0d:e8:0e:d4:df:da:22:78:0b:c3:08:e9:98:
                      c6:18:8c:08:66:f3:a9:d0:08:6a:c8:d6:cd

[hslatman]

Looks OK, but would be good to include a test cert. Could be the one you used in the test above, or one from web PKI.

Was triggered by the RFC6962 prefix in RFC6962 Certificate Transparency SCT, as that seems to be the first where we don't use X509v3, but apparently we already had that, so it's OK. Scratch that; we have some Sigstore "domain" extensions too. I suppose we should be using something like Smallstep for our own ones instead, but that's for another time.

[marten-seemann]

Looks OK, but would be good to include a test cert.

Any hint how to regenerate the test certificates? sigstore2.cert.pem contains an SCT, but there's no CSR (and the SCT is not usually added via CSR anyway), so I'm not sure how to add an extension to that value there.

[hslatman]

Any hint how to regenerate the test certificates? sigstore2.cert.pem contains an SCT, but there's no CSR (and the SCT is not usually added via CSR anyway), so I'm not sure how to add an extension to that value there.

Can't you use the cert you used for testing the output? If not directly, maybe it can be done using some packages from our crypto repo with a fake CA signing a cert with a fake SCT?

There's this generator: https://github.com/smallstep/certinfo/blob/master/test_certs/make-certs.sh. It doesn't generate all test files, though. I remember for Sigstore I did an actual signing operation and put the cert here. It was the quickest way to get an example Sigstore cert that way.

[marten-seemann]

Can't you use the cert you used for testing the output?

Sure, I can do that. I thought we wanted to have something more "official", but we only care about the SCT extension in this test, so this should be fine.

[hslatman]

Part of what certinfo (through step certificate inspect) is used for is inspecting certs in the wild, so it's actually not that bad to have some of those in here 🙂