Boulder: Embed SCT receipts in certificates

[rugk]

Please add certificate information to issued certificates (or OCSP respones).
As even StartSSL/WoSign do this, you should also be able to do it. Including them in the cert (or OCSP respones) is the easiest way to do this and does not rely on the web admin to do anything.

[rolandshoemaker]

OCSP responses already contain SCT receipts and work is underway to embed them in certificates.

[rolandshoemaker]

Uh, my bad, apparently we don't include receipts in OCSP responses. I was pretty sure we merged code to do that but apparently not.

Changing title to reflect the current plan which is embedding receipts in certificates.

[rolandshoemaker]

Side note: usefulness of this feature (at least based on Chromium policy) is minimal until we can find a non-Google CT log that will accept our certificates.

[rugk]

ctlog.api.venafi.com accepts your certificates AFAIK.

[mygithuber]

Yes, pls refer to:
https://www.venafi.com/blog/venafi-supports-google-certificate-transparency-ca-agnostic-log-and-monitor
https://www.venafi.com/blog/need-for-certificate-transparency

[Knight1]

Currently I push all my certs to:

ct.googleapis.com/pilot
ct.googleapis.com/aviator
ct.googleapis.com/rocketeer
ct.googleapis.com/icarus only DST-Root X3 and ISRG Root X1
ctlog.wosign.com
plausible.ct.nordu.net
ctlog.api.venafi.com

All of them accepts the certificates issued from Let's Encrypt.

[rugk]

ctlog.wosign.com does not AFAIK or - especially now - it is not trusted by Chrome anyway.
I don't know about plausible.ct.nordu.net though.

[tdelmas]

If https://www.chromium.org/Home/chromium-security/certificate-transparency is up to date, ctlog.wosign.com is trusted but not plausible.ct.nordu.net

[Knight1]

https://crt.sh/?a=1

ctlog.wosign.com is in the M54 Release see https://bugs.chromium.org/p/chromium/issues/detail?id=605415
plausible.ct.nordu.net has a high number of logged certs see crt.sh link above. They are right after the 3 google main logs and befor Symantecs ct log. But indeed not included in Google Chromium.

[rugk]

I just doubt ctlog.wosign.com will stay in there for a long time as of the latest happenings.

[Knight1]

If booth of StartCom and WoSign reapply for the NSS inclusion they need two logs. My last test cert from them used Aviator and Pilot. But this is a bad decission since they have there own log. But indeed Google made a new log just for Let's Encrypt "Icarus" but Let's Encrypt don't use them currently.

[rugk]

Icarus is not mentioned on the official site.

[Knight1]

This is correct because it is still in the 90 days monitoring phase. The Chrome Policy is planned for October 2017 so there is plentiful time over. https://bugs.chromium.org/p/chromium/issues/detail?id=632753

Google is trying to put load from the three main CT Logs see https://groups.google.com/a/chromium.org/forum/#!msg/ct-policy/2ZL4tSCwbYU/xcck3xZ8BQAJ

Icarus is currently Let's Encrypt only. So the only question is which CT log is able to withstand the load from Let's Encrypt which is not operated by Google or ISRG. The active cert count is growing and we need a stable log for this.

[Knight1]

Icarus und Skydriver have passed the monitoring phase on Nov 3 and are now going it's way through canary, beta and then stable. See https://chromium.googlesource.com/chromium/src.git/+/403c8359bdc2b635d480a80329c41be422583c1f
https://bugs.chromium.org/p/chromium/issues/detail?id=632753#c14

I would appreciate it if Let's Encrypt is setting up there own log. But I think it would be better for the community to have a log which is not operated from a CA, Organization or something else. I think it would be the best to use a community driven, open and auditable (registered association) log which is financed from the CA's which want there certificated added there. What do you think about this?

[rugk]

What do you think about this?

Why not let a NGO host such a log? EFF, what do you say?
Although the EFF is of course already affiliated with Let's Encrypt, so it would not be 100% independent. 😒
And of curse it would be hard for an NGO with a limited amount of money to fulfill all the strict (availability) requirements Google has…

[jsha]

Most likely if one of EFF or Let's Encrypt were to operate a CT log, it would be Let's Encrypt. That way Let's Encrypt could manage that log's availability as part of Let's Encrypt's own availability. However, as you point out, it's another significant cost of time for Let's Encrypt staff, that we're not currently prepared to commit to. So we're still looking for a third-party log to submit to.

That said, we are starting to design the process to submit precertificates so we can embed SCTs in certificates, and plan to implement before next October.

[rugk]

Maybe add this to https://letsencrypt.org/upcoming-features/?

[ScottHelme]

Is there an updated ETA for this?

[Knight1]

Currently they are only pushing the CT's to Icarus so they need the second external provided CT Log.

[Knight1]

https://clicky.ct.letsencrypt.org/ct/v1/get-roots 👍

[Knight1]

I was able to get a sct :3
But there is a BIG backlog https://crt.sh/monitored-logs
Tree Size 22950848
Backlog 18450487

[rolandshoemaker]

__It should be noted:__ this log exists for testing CT infrastructure and deployment designs, it should not be considered production quality, nor expected to maintain strict long term consistency. We will not be requesting Chrome inclusion for this log.

[Ayesh]

https://clicky.ct.letsencrypt.org/ct/v1/get-roots

AFAIK, this is in addition to Google's pilot and rocketeer, Venafi, and Filippo's.

[J0WI]

This would also be a requirement to support the upcomming Expect-CT header:
https://github.com/httpwg/http-extensions/blob/master/draft-ietf-httpbis-expect-ct.md

[hickford]

This would also be a requirement to support the upcoming Expect-CT header

See also https://gist.github.com/sleevi/08e578719d92d9a5a3c2e1d59839b77e

With proposals like Expect-CT, it may be that server operators want to opt-in to CT, even without their CA's support, and so need work from the server operator.

The ranking of best to worst ways to deploy CT on a server today are:

1. Embedded within the certificate (Requires the CA to support)
2. Embedded within an OCSP response (Requires the CA to support, requires robust OCSP support)
3. Served as part of the TLS extension
   
   
   
   1. Dynamically obtained by the server (similar to OCSP)
   
   
   2. Statically configured by a file
   
   

[Knight1]

There is a commit for "Implement IssuePrecertificate." which is planned to be deployed @ Planned Start: 8/24/2017 11:00am (-0600)
https://github.com/letsencrypt/boulder/commit/d2291f6c5ac129e417758f4ee5cfaa19a600d598

Is there an eta when the staging is flipping the bit for this? @jsha

[alex]

@Knight1 I believe this commit introduces code for issuing a precertificate, but it doesn't completely wire up the flow of issuing a precert, obtaining SCTs, and then embedding them in the final cert, so AFAIK there isn't anything to flip the bit on yet.

[cpu]

@alex @Knight1 That's correct. The work isn't finished and there isn't an ETA to enable it in staging.

[axelu]

Just to clarify, LE plans to only support SCTs embedded in certificates, but not in OCSP responses, correct?

[jsha]

For now, yes. It's the simplest approach that will work for all of our users.

[rugk]

Is there any ETA?

[wiktor-k]

@rugk I'm not an employee of Let's Encrypt but there is ETA here: https://letsencrypt.org/upcoming-features/

Embed SCT receipts in certificates
ETA: February, 2018

[dominic-p]

Not to be "that guy" but it's February. :) Do we have an ETA on this?

[wiktor-k]

I suppose they are busy with rolling out ACME v2 and wildcards... :)

[ScottHelme]

I look forward to an update :)

[Knight1]

https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/wHILiYf31DE

End of April 2018 is not that easy since they are currently in the ACMEv2 and this does not include it nor the staging environment. But they are still on it

https://github.com/letsencrypt/boulder/commit/9e23edf850a2e36f0143bac0a0556594665568be
https://github.com/letsencrypt/boulder/pull/3422
https://github.com/letsencrypt/boulder/pull/3414

[jsha]

We're working hard on it, but will probably not land this in production before the end of February. Still, we are very much aware of the upcoming deadline and committed to meeting it. Thanks for the enthusiasm everyone! :-)

[mdebski]

Hi, I see that you recently upgraded boulder past this commit, but I don't see it live in production yet. Is this expected (e.g. it needs flag flip)?

[thestinger]

https://community.letsencrypt.org/t/signed-certificate-timestamps-embedded-in-certificates/57187

[hickford]

@thestinger Great news! Thanks for sharing

Let’s Encrypt has always submitted certificates to Certificate Transparency1 logs. However, it hasn’t provided proof of that in the certificates. Starting soon, we will provide that proof by embedding Signed Certificate Timestamps (SCTs) in each newly issued certificate. These are signed assertions by log operators that we have submitted that certificate to their log, and it will soon be incorporated. Our policy will be to include one SCT from a Google log and one SCT from a non-Google log, following Chrome’s CT Policy2.

No action is required from Let’s Encrypt subscribers. This will happen automatically for newly issued and renewed certificates. When Chrome begins enforcing its CT policy in April3, it will be for certificates issued after April 30, 20182. So if you currently have a certificate in place, there is no need to renew it early. It will continue to be valid, and when your next automated renewal rolls around, your certificate will have SCTs in it.

If you would like to take advantage of the security benefits of certificate transparency, you can monitor your domains using a CT monitoring tool like SSLMate’s Cert Spotter10, Hardenize’s CT monitoring9, or Facebook’s CT monitoring tool4. These tools can send you a notification when certificates are issued for your domains.

SCT embedding is already enabled in our staging environment. We will enable it in production in the next week or so; we’ll post an update here, and there will be an update on https://letsencrypt.status.io/.

[science]

Glad that this issue is resolved. FYI the URL in the prior message is 404 at the moment. https://letsencrypt.status.io/16

[georgeperez]

@science The "16" is the number of times the link has been clicked on Discourse. They just meant that when SCT embedding goes live a notice will be posted on the status page.

[jsha]

I've edited @hickford's comment to fix the URL, which succumbed to a copy-paste bug as @georgeperez describes.