# Will you support Certificate Transparency?

**URL:** <https://community.letsencrypt.org/t/will-you-support-certificate-transparency/222>\
**Category:** Issuance Tech\
**Created:** [August 15, 2015, 2:52pm UTC](https://community.letsencrypt.org/t/will-you-support-certificate-transparency/222 "2015-08-15T14:52:05Z")\
**Posts on this page:** 1\
**Showing post:** 11

<div class="post-metadata">

**Author:** ![jsha](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jsha/32/12_2.png) [@jsha](https://community.letsencrypt.org/u/jsha)\
**Post date:** [August 18, 2015, 4:48pm UTC](https://community.letsencrypt.org/t/will-you-support-certificate-transparency/222/11 "2015-08-18T16:48:54Z")

</div>

It’s significantly more complicated than it sounds, actually. I’d encourage you to [read the relevant section of RFC6962](https://tools.ietf.org/html/rfc6962). In effect, the CA has to issue the certificate twice. First you generate a precertificate with a critical poison extension, then submit it to a CT log, receive the SCT, and then sign it again. There is potential for failure and delay at each step in the process, plus significant additional complexity, which is why the authors of the CT spec included easier options.

---

_[View the full topic](https://community.letsencrypt.org/t/will-you-support-certificate-transparency/222)._
