0

I have deployed a Certificate Transparency (CT) log server that uses Google's CTFE (named "certificate-transparency-go" on Github) and Trillian Projects. And I have issued a pre-certificate, submitted to my own CT log server.

I have this text information from the server (some information has been removed):

Uploading pre-certificate to log
Uploaded chain of 4 certs to V1 log at http://<removed>/<removed>, timestamp: 1661153608580 (2022-08-22 15:33:28.58 +0800 CST)
LogID: 400cb51cb037bad42********ba4b12e073
LeafHash: 376da8b2be20b0426d5e*********8fa00d78b9e570cc5a88af0490e9e2
Signature: Signature: Hash=SHA256 Sign=ECDSA Value=304502206419ae26edf93a*******************032022100b8353a9a49d0b12*********e521fd21dfabd17969d8fc17302421

But I have not found the solution to embed this information in a X.509 Certificate Extension (OID is "1.3.6.1.4.1.11129.2.4.2"). As far as I know, this information should be encoded as HEX OCTET_STRING, but I don't know what I should do to make it work.

For now, my own CT log server is not trusted, but I still want to add it to my certificate.

Note that I'm using a private PKI, so Mozilla, Apple and Microsoft will not trust my root certificate.

Shireheart
  • 350
  • 1
  • 7
Levi Marvin
  • 1
  • 1

1 Answers1

0

All X.509v3 extension values are encoded outermost as OCTET STRING -- that's in the syntax definition -- which contains a DER encoding usually of an ASN.1 structure; but (v1) SCTList in RFC6962 is encoded using the TLS-formerly-SSL forms defined in e.g. RFC5246 section 4 applied to the list structure shown in 3.3, whose element(s) is(are) the SignedCertificateTimestamp structure shown on the same page just above that link, and thus needs to be wrapped in an extra layer of OCTET STRING.

As an example, https://stackoverflow.com/questions/69205710/modifying-extension-list-in-x509-certificate-using-openssl-in-c inserts an SCTList extension into a cert using OpenSSL -- after deleting the poison extension of the precert, which is irrelevant here. It uses a (correctly) pre-encoded value for the SCTList extension provided by the OP, which when de-base64-ed and displayed in hex for humans, breaks down as follows:

 04 81 7a 00 78 00 76 00 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 00 00 01 66 7b cf f0 d0
 00 00 04 03 00 47 30 45 02 21 00 ca 24 f3 d0 85
 6a a3 7b 5a d0 ab e4 f4 eb 1d 22 36 52 d3 ee b5
 fb d6 4d b7 54 f6 64 86 6f d0 0b 02 20 7e 1c 0d
 2b b8 b3 7a ad 1f 1c 09 6e ec 7b 98 46 39 af ca
 6e 75 45 17 65 35 68 5d e7 42 d0 76 ee

04 81 7a DER header for 'extra' OCTET STRING containing 0x7a bytes

00 78 length of SCTList

00 76 length of only SCT entry in list -- in real use the CA would get SCTs from multiple logs and put them all into one list, but you have only one DIY log so like OP you would only have one entry

00 version

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 logid

00 00 01 66 7b cf f0 d0 timestamp

00 00 length of extensions -- if nonzero would be followed by actual extension data

04 03 SignatureAndHashAlgorithm from RFC5246 for SHA256-with-ECDSA (note RFCs 8422 and 8446 changed TLS to a single combined scheme rather than independent hash and 'pure' signature components, but AFAICT that isn't applied to CT)

00 47 length of signature 30 45 02 21 ... 02 20 ... ECDSA signature in ASN.1 DER encoding (SEQUENCE of two INTEGERs) specified in RFC3279 -- note for a 256-bit curve this will normally vary in the range 70-72 (0x46-0x48) bytes but will sometimes (rarely) be shorter

What form(s) of this information you need to give your CA software, in particular whether part(s) or all of this must be in hex, are up to your software, which you didn't identify or describe.

Also you might want to know there is a new v2 spec as of last year -- I have no clue whether, when and how it will be supported by the software you're using, but it uses data that is basically equivalent in concept but different in a number of details.

dave_thompson_085
  • 9,759
  • 1
  • 24
  • 28
  • Thanks for you help! I'm sorry about I have not provide more information. I used OpenSSL to generate certificate, So I have to add these information to config file of OpenSSL. Do you know how to do that? – Levi Marvin Aug 25 '22 at 05:03
  • I'm using the CA software named XCA is based OpenSSL, so if I want to add the SCT List extension, I need to write it be the format that supported by OpenSSL config. – Levi Marvin Aug 25 '22 at 05:07
  • Levi: If you are or it is using _commandline_ openssl, the config for that doesn't support SCTList; it does support arbitrary ASN.1 structures but not TLS ones, so you must put the entire encoding in hex (as you guessed), like (given 1.0.2 up) `ct_precert_scts=DER:04817a0078007600b0cc83e5a5f97d6b...`. If using _library_ need much more details to answer. – dave_thompson_085 Aug 29 '22 at 01:51
  • dave_thompson_085: Hello Dave, Is there any way that I can encoding SCT Information to HEX? I just have the text SCT information. – Levi Marvin Sep 17 '22 at 12:23
  • Levi: If your text information is sufficient to construct the binary structure defined in the RFC and shown in the example I cited and quoted, converting to hex is trivial. Otherwise no. – dave_thompson_085 Sep 20 '22 at 06:30