Skip to main content

4.1. Add Chain to Log

4.1. Add Chain to Log​

POST https://<log server>/ct/v1/add-chain

Inputs:

  • chain: An array of base64-encoded certificates. The first element is the end-entity certificate; the second chains to the first and so on to the last, which is either the root certificate or a certificate that chains to a known root certificate.

Outputs:

  • sct_version: The version of the SignedCertificateTimestamp structure, in decimal. A compliant v1 implementation MUST NOT expect this to be 0 (i.e., v1).

  • id: The log ID, base64 encoded. Since log clients who request an SCT for inclusion in TLS handshakes are not required to verify it, we do not assume they know the ID of the log.

  • timestamp: The SCT timestamp, in decimal.

  • extensions: An opaque type for future expansion. It is likely that not all participants will need to understand data in this field. Logs should set this to the empty string. Clients should decode the base64-encoded data and include it in the SCT.

  • signature: The SCT signature, base64 encoded.

If the "sct_version" is not v1, then a v1 client may be unable to verify the signature. It MUST NOT construe this as an error. (Note: Log clients don't need to be able to verify this structure; only TLS clients do. If we were to serve the structure as a binary blob, then we could completely change it without requiring an upgrade to v1 clients.)

Last updated on