New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Embed SCT receipts in certificates #2244

Closed
rugk opened this Issue Oct 12, 2016 · 43 comments

Comments

Projects
None yet
@rugk

rugk commented Oct 12, 2016

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

This comment has been minimized.

Contributor

rolandshoemaker commented Oct 12, 2016

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

@rolandshoemaker

This comment has been minimized.

Contributor

rolandshoemaker commented Oct 13, 2016

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 rolandshoemaker changed the title from Add CT information to issues certificates to Embed SCT receipts in certificates Oct 13, 2016

@rolandshoemaker

This comment has been minimized.

Contributor

rolandshoemaker commented Oct 13, 2016

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

This comment has been minimized.

rugk commented Oct 13, 2016

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

@Knight1

This comment has been minimized.

Knight1 commented Oct 25, 2016

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

This comment has been minimized.

rugk commented Oct 26, 2016

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

This comment has been minimized.

Contributor

tdelmas commented Oct 26, 2016

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

This comment has been minimized.

Knight1 commented Oct 26, 2016

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

This comment has been minimized.

rugk commented Oct 26, 2016

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

@Knight1

This comment has been minimized.

Knight1 commented Oct 26, 2016

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

This comment has been minimized.

rugk commented Oct 26, 2016

Icarus is not mentioned on the official site.

@Knight1

This comment has been minimized.

Knight1 commented Oct 26, 2016

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

This comment has been minimized.

Knight1 commented Nov 11, 2016

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

This comment has been minimized.

rugk commented Nov 11, 2016

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

This comment has been minimized.

Contributor

jsha commented Nov 11, 2016

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

This comment has been minimized.

rugk commented Nov 12, 2016

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

@ScottHelme

This comment has been minimized.

ScottHelme commented Jan 29, 2017

Is there an updated ETA for this?

@Knight1

This comment has been minimized.

Knight1 commented Jan 29, 2017

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

@Knight1

This comment has been minimized.

Knight1 commented May 3, 2017

@Knight1

This comment has been minimized.

Knight1 commented May 3, 2017

image
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

This comment has been minimized.

Contributor

rolandshoemaker commented May 3, 2017

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

This comment has been minimized.

Ayesh commented May 3, 2017

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 comment has been minimized.

J0WI commented Jun 2, 2017

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 comment has been minimized.

hickford commented Jul 10, 2017

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
  4. Dynamically obtained by the server (similar to OCSP)
  5. Statically configured by a file
@Knight1

This comment has been minimized.

Knight1 commented Aug 24, 2017

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

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

@alex

This comment has been minimized.

Contributor

alex commented Aug 24, 2017

@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

This comment has been minimized.

Member

cpu commented Aug 24, 2017

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

@axelu

This comment has been minimized.

axelu commented Oct 18, 2017

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

@jsha

This comment has been minimized.

Contributor

jsha commented Oct 18, 2017

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

@rugk

This comment has been minimized.

rugk commented Oct 18, 2017

Is there any ETA?

@wiktor-k

This comment has been minimized.

wiktor-k commented Oct 18, 2017

@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

This comment has been minimized.

dominic-p commented Feb 14, 2018

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

@wiktor-k

This comment has been minimized.

wiktor-k commented Feb 14, 2018

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

@ScottHelme

This comment has been minimized.

ScottHelme commented Feb 14, 2018

I look forward to an update :)

@Knight1

This comment has been minimized.

Knight1 commented Feb 14, 2018

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

9e23edf
#3422
#3414

@jsha

This comment has been minimized.

Contributor

jsha commented Feb 14, 2018

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! :-)

@jsha jsha closed this in #3521 Mar 12, 2018

jsha added a commit that referenced this issue Mar 12, 2018

Add SCT embedding (#3521)
Adds SCT embedding to the certificate issuance flow. When a issuance is requested a precertificate (the requested certificate but poisoned with the critical CT extension) is issued and submitted to the required CT logs. Once the SCTs for the precertificate have been collected a new certificate is issued with the poison extension replace with a SCT list extension containing the retrieved SCTs.

Fixes #2244, fixes #3492 and fixes #3429.
@mdebski

This comment has been minimized.

Contributor

mdebski commented Mar 19, 2018

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)?

@hickford

This comment has been minimized.

hickford commented Mar 21, 2018

@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

This comment has been minimized.

science commented Mar 30, 2018

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

@georgeperez

This comment has been minimized.

georgeperez commented Mar 30, 2018

@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

This comment has been minimized.

Contributor

jsha commented Mar 30, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment