Introducing ctsubmit, a CT submission proxy

[Rob Stradling]

https://github.com/crtsh/ctsubmit

A REST API and web interface for submitting precertificate and certificate chains to CT logs and for collecting and linting the resulting Signed Certificate Timestamps (SCTs).

Designed to make it simple for any CA to operate a compliant, performant, fault-tolerant, scalable CT submission pipeline.

v0.0.1 prerelease available now.  Comments and collaboration welcome!

[Andrew Ayer]

Hi Rob,

It's great to see this! Thanks for building and open sourcing it.

The following feature gives me pause:

"Returns a TBSCertificate with the collected SCTs embedded as an SCT list extension, ready for signing."

This seems risky because it means a compromise of the ctsubmit service can lead to the signing of arbitrary data. Even if the CA operates ctsubmit themselves it's still a big increase in the CA's trusted computing base.

I think it would be much better if ctsubmit returned just the SCT extension, and the CA was responsible for constructing the TBSCertificate. While this is more work for the CA, and they could make a mistake, the impact of that is far less catastrophic than signing arbitrary data.

Regards,
Andrew

On Thu, 4 Jun 2026 12:10:32 -0700 (PDT)
"'Rob Stradling' via Certificate Transparency Policy"

> --
> You received this message because you are subscribed to the Google
> Groups "Certificate Transparency Policy" group. To unsubscribe from
> this group and stop receiving emails from it, send an email to
> ct-policy+...@chromium.org. To view this discussion visit
> https://groups.google.com/a/chromium.org/d/msgid/ct-policy/2b7f821e-1d7a-4cf9-ae22-779f24c10548n%40chromium.org.

[Rob Stradling]

Hi Andrew.  Thanks for that feedback.  I agree that it's always wise to validate external inputs when it's possible to do so.

ctsubmit also returns the "raw" add-pre-chain responses from the logs, which does enable CAs to do the SCT validation/linting and TBSCertificate construction themselves.

Perhaps the best way forward is to hide this ctsubmit feature (generating and returning the TBSCertificate plus ctlint results) behind a configuration flag, disabled by default; and then stress the dangers of "signing arbitrary data" in the documentation for that configuration flag.  WDYT?

---

From: ct-p...@chromium.org <ct-p...@chromium.org> on behalf of Andrew Ayer <ag...@andrewayer.name>
Sent: 05 June 2026 13:33
To: Rob Stradling <r...@sectigo.com>
Cc: 'Rob Stradling' via Certificate Transparency Policy <ct-p...@chromium.org>
Subject: Re: [ct-policy] Introducing ctsubmit, a CT submission proxy

 

Hi Rob, It's great to see this! Thanks for building and open sourcing it. The following feature gives me pause: "Returns a TBSCertificate with the collected SCTs embedded as an SCT list extension, ready for signing. " This seems risky because

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

Report Suspicious

 

ZjQcmQRYFpfptBannerEnd

Hi Rob,

It's great to see this! Thanks for building and open sourcing it.

The following feature gives me pause:

"Returns a TBSCertificate with the collected SCTs embedded as an SCT list extension, ready for signing."

This seems risky because it means a compromise of the ctsubmit service can lead to the signing of arbitrary data. Even if the CA operates ctsubmit themselves it's still a big increase in the CA's trusted computing base.

I think it would be much better if ctsubmit returned just the SCT extension, and the CA was responsible for constructing the TBSCertificate. While this is more work for the CA, and they could make a mistake, the impact of that is far less catastrophic than signing arbitrary data.

Regards,
Andrew

On Thu, 4 Jun 2026 12:10:32 -0700 (PDT)
"'Rob Stradling' via Certificate Transparency Policy"
<ct-p...@chromium.org

> wrote:

> https://urldefense.com/v3/__https://github.com/crtsh/ctsubmit__;!!J5K_pWsD!wjSnR1LtzwxPrJ0ptneSFmqUwKzLfJnFssHqJudOKoUZ7d0D2n9tAllFca2_rts0DMCehQEQYAN27_w$

> 
> A REST API and web interface for submitting precertificate and
> certificate chains to CT logs and for collecting and linting the
> resulting Signed Certificate Timestamps (SCTs).
> 
> Designed to make it simple for any CA to operate a compliant,
> performant, fault-tolerant, scalable CT submission pipeline.
> 
> v0.0.1 prerelease available now.  Comments and collaboration welcome!
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Certificate Transparency Policy" group. To unsubscribe from
> this group and stop receiving emails from it, send an email to
> ct-policy+...@chromium.org

. To view this discussion visit
> https://urldefense.com/v3/__https://groups.google.com/a/chromium.org/d/msgid/ct-policy/2b7f821e-1d7a-4cf9-ae22-779f24c10548n*40chromium.org__;JQ!!J5K_pWsD!wjSnR1LtzwxPrJ0ptneSFmqUwKzLfJnFssHqJudOKoUZ7d0D2n9tAllFca2_rts0DMCehQEQo5eWaas$.

-- 
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.
To view this discussion visit https://urldefense.com/v3/__https://groups.google.com/a/chromium.org/d/msgid/ct-policy/20260605083341.bd835fc8a0ef20e8ab850ae2*40andrewayer.name__;JQ!!J5K_pWsD!wjSnR1LtzwxPrJ0ptneSFmqUwKzLfJnFssHqJudOKoUZ7d0D2n9tAllFca2_rts0DMCehQEQC2gifP4$.

[Rob Stradling]

> Perhaps the best way forward is to hide this ctsubmit feature (generating and returning the TBSCertificate plus ctlint results) behind a configuration flag, disabled by default; and then stress the dangers of "signing arbitrary data" in the documentation for that configuration flag.  WDYT?

I've implemented this approach in https://github.com/crtsh/ctsubmit/pull/23 and tagged v0.0.2.