2

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.

1 Answer 1

1

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.

ADDED: You say you are using XCA; I assume you mean this which is a GUI for OpenSSL, and per this manual page accepts additional extensions in the same format as an OpenSSL config file (for req or x509 or ca). The "text" information in your Q is mostly textual representations of data that is not actually textual: you have the timestamp as decimal and in a display form, which you must convert; the logid in hex (apparently, though you mangled it) (and also the leaf hash, which you don't need), and the signature mostly in hex (ditto) plus the two algorithm names. And it happens your signature is the same length as my example from the other Q (0x47=71 bytes) so for this instance you can use the same length fields I showed (but for other log entries = precerts you will often have to change them). Also your sigalg is the same as my example; that is more likely to remain true because AFAICT most logs now use ECDSA-SHA256, although other algorithms are permitted. Thus:

  1. go to the 'advanced' tab of cert (or CSR) input, click edit

  2. enter ct_precert_scts=DER:

  3. enter (in order) the pieces I put in fixed-on-blue format above EXCEPT replace my logid with yours (in hex and NOT mangled), my timestamp with 182c4788384 (which is yours converted to hex), and my signature data with yours (ditto, keeping the prefix length); but don't put spaces between the hexit-pairs as I used for display, instead either replace by colon or delete. You may prefer to prepare this in some other tool like notepad and then copy&paste; if so you can combine #2 into this

  4. click validate

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.

8
  • 1
    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? Aug 25, 2022 at 5: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. Aug 25, 2022 at 5: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. Aug 29, 2022 at 1: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. Sep 17, 2022 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. Sep 20, 2022 at 6:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .