skip to content

Your research portal must deliver signed certificate timestamps to TLS clients — which three delivery paths does Certificate Transparency define?

level: seniorimportance: should knowfreq 45%

answer

  1. three carriers, one requirement each way
  2. in the certificate, in the handshake, in the status response
  3. clients all three, servers at least one
  4. embedded is frozen at issuance
  5. server returns extension type 18

basics

~20 s

Three: an SCT list embedded in the certificate as an X.509 extension at OID 1.3.6.1.4.1.11129.2.4.2, the signed_certificate_timestamp TLS extension (type 18) returned by the server, and an SCT list carried inside a stapled certificate status response.

solid answer

~40 s

The embedded path puts an SCT list in the certificate itself, at OID `1.3.6.1.4.1.11129.2.4.2`; the authority does it at issuance and the server operator configures nothing, but the set is frozen into the signed bytes. The handshake path uses the `signed_certificate_timestamp` TLS extension, extension type 18: the client offers it in its ClientHello and the **server** returns the list — in TLS 1.3, in the extensions of its Certificate message. The third path carries an SCT list inside a stapled certificate status response, riding machinery the operator may already run for freshness. RFC 6962 requires TLS clients to implement **all three** mechanisms and servers to implement **at least one** — so which one you use is your choice, and clients must cope with any of them.

code

pseudocode · 12 lines
pseudocode
collected = empty list

collected.append_all(certificate_extension(leaf_certificate, "1.3.6.1.4.1.11129.2.4.2"))
collected.append_all(tls_extension(handshake, "signed_certificate_timestamp"))
collected.append_all(stapled_status_response_extension(handshake))

usable = empty list
for each sct in collected:
    if policy_recognises(sct.log_id) and verify(sct, log_public_key(sct.log_id)) then
        usable.append(sct)

if policy_satisfied_by(usable, leaf_certificate) then continue else fail_connection

go deeper

for a junior

Recall that the timestamps usually travel inside the certificate itself, so most operators serve them without configuring anything at all.

for a middle

Name all three carriers and say who inserts each, including that the server — not the client — returns the list when the TLS extension is used.

for a senior

Show the operational trade: the embedded set is frozen at issuance, while the other two paths buy changeability at the price of state that must survive renewal and every front end.

for a principal

Decide where transparency evidence lives across an estate with several entry points, and who owns keeping it in step when certificates or accepted logs change.

## Why three, and not one Signed certificate timestamps have to reach the client during the connection, and the three parties who could supply them — the issuing authority, the server, and whatever machinery already answers status queries — have different constraints. Certificate Transparency therefore defines three delivery mechanisms rather than mandating one, and splits the requirement asymmetrically: **RFC 6962 requires TLS clients to implement all three mechanisms, and servers to implement at least one.** Read that carefully, because it is the shape of the whole design. The burden of universal support sits on the client; the server picks whichever path fits its deployment. ## Path one: inside the certificate An **SCT list extension** at OID `1.3.6.1.4.1.11129.2.4.2` in the certificate's v3 extensions. - Inserted by the issuing authority at issuance, after logging a precertificate. - Costs the server operator nothing: serve the certificate and the timestamps travel with it, through any intermediary, in any protocol version. - Frozen at issuance. Changing which logs are cited — because a log was distrusted, or a client policy changed — means obtaining a new certificate. - This is why most publicly trusted certificates today carry their timestamps inline. ## Path two: the TLS handshake extension The `signed_certificate_timestamp` extension, **extension type 18**. - The **client** offers the extension in its ClientHello to indicate it will accept timestamps this way. The **server** supplies the actual SCT list. Getting that direction backwards is the most common error in describing this path: a client never supplies timestamps to a server. - In TLS 1.3 the server returns the list in the extensions of the **Certificate** message, so it is bound to the certificate it belongs to; earlier versions carry it as a server hello extension. - The timestamps live in server configuration, not in the certificate, so the set can be updated without reissuing. - The cost is state: something has to fetch the timestamps, store them, serve them, and keep them in step with certificate renewal. If the handshake terminates at an intermediary, that intermediary is what has to serve them. ## Path three: inside a stapled status response An SCT list carried as an extension of a stapled certificate status response. - Useful where an operator already staples status for freshness reasons: the timestamps ride a channel that is already being maintained and refreshed. - Like path two, it can be updated without a new certificate. - Like path two, it depends on the server actually stapling — a client that receives no stapled response receives no timestamps this way. The stapling mechanism and the status-response format itself are a separate subject from transparency; here it is simply a carrier. ## Choosing | | embedded extension | TLS extension | stapled status response | |---|---|---|---| | who inserts | the issuing authority | the server or its front end | whatever staples the response | | change without reissuing | no | yes | yes | | server configuration needed | none | timestamps held and served | stapling already working | | survives an intermediary | yes, it is in the certificate | only if that intermediary serves it | only if that intermediary staples | For a portal team the practical reading is: if your certificates arrive with timestamps embedded, you are done and there is nothing to operate. You reach for the other two paths when you need to change the timestamp set without touching the certificate, or when your certificates do not come with them embedded. ## The client side, and one retired header A client that enforces CT policy collects timestamps from every path it received them on, verifies each signature against the public key of the log named by its `log_id`, discards any from a log its policy does not recognise, and then applies its policy — commonly a minimum count from independently operated logs, with more expected of longer-lived certificates. Those counts come from browser root-programme policy, not from the RFC, and they change over time independently of it. A site could once ask clients to enforce and report CT for it using the `Expect-CT` response header. That header is **retired**: it is no longer honoured, and CT enforcement for publicly trusted certificates is now driven by client policy rather than by anything the site declares. Naming it as retired is correct; treating it as a control you can deploy is not. ## Failure modes worth recognising - **Timestamps served, none recognised.** Every timestamp came from a log the client's policy does not accept, so the count is zero. The fix is which logs are cited, not how they are delivered. - **Connection works one way, fails another.** A front end serves the TLS extension while a different entry point does not, so behaviour depends on which path the client took. - **Renewal drops them.** A stored timestamp set is not refreshed with the certificate, and stale timestamps no longer match the certificate they are offered with.

  • Which of the three delivery paths can you change without obtaining a new certificate?
    The TLS extension and the stapled status response, because in both cases the timestamps are served by you at handshake time and live in configuration. The embedded SCT list extension is inside the signed certificate, so changing it means reissuing. That is the main reason an operator would take on the configuration burden of the other two.
  • What became of the Expect-CT response header?
    It let a site ask clients to enforce transparency for it and to report violations to an endpoint. It is retired and no longer honoured: enforcement for publicly trusted certificates is now decided by client policy rather than declared per site. Teaching it as a current control is a defect; naming it as retired is accurate.
  • The handshake terminates at a front end rather than at the portal's own servers. Where do the timestamps have to be?
    Wherever the certificate is presented. The front end is the peer performing the handshake, so if timestamps are embedded in the certificate they travel automatically, and if you rely on the TLS extension or a stapled response, that front end is what must hold and serve them. A correctly configured origin behind it changes nothing.

saying these in an interview costs you the question

  • Thinks timestamps can only be embedded in the certificate.
  • Says the client supplies the timestamp list to the server in the handshake.
  • Believes a server has to implement all three delivery paths.
  • Assumes a stapled status response can only carry revocation status.
  • Thinks changing which logs you cite never requires a new certificate.
  • Treats the retired Expect-CT header as a control you can still deploy.