4 ms·

They've done mass revocations in the past. There was one about a year ago from what I remember. So whatever study could be done, likely already has been. The qu

They've done mass revocations in the past. There was one about a year ago from what I remember. So whatever study could be done, likely already has been. The question now is whether the issue is sever enough to warrant that action.

fullstop 5y ago
I feel that you've missed the joke. Also, there is no way, at all, that they are going to revoke nearly all of their certs because they were valid for 1 second longer than they should have been. It would mark the end of Let's Encrypt if they did. We've lived with certs that were valid for a second longer than they should have been since the inception of Let's Encrypt, and three months won't kill anyone. edit follows: When they revoked 3% of their certificates, not all of them were able to renew in time due to physical server limitations. The renewals required server administrators to forcibly renew their certificates, and the email address associated with the certificate was contacted to let them know. It would be an unmitigated disaster if 185 million certificates were suddenly revoked.
- tingletech 5y ago
  Let's Encrypt has capacity to reissue all certificates in 24 hours. I think this is why you are supposed to run certbot every day. https://letsencrypt.org/2021/02/10/200m-certs-24hrs.html https://letsencrypt.org/2021/02/10/200m-certs-24hrs.html
  - fullstop 5y ago
    They have the physical infrastructure to do so, but you've missed this part of article you linked: > In order to get all those certificates replaced, we need an efficient and automated way to notify ACME clients that they should perform early renewal. Normally ACME clients renew their certificates when one third of their lifetime is remaining, and don’t contact our servers otherwise. We published a draft extension to ACME last year that describes a way for clients to regularly poll ACME servers to find out about early-renewal events. We plan to polish up that draft, implement, and collaborate with clients and large integrators to get it implemented on the client side. Running certbot daily will currently do nothing. It won't think that the certificate needs to be replaced since it has not yet reached the limit required to renew.
    - mholt 5y ago
      > Running certbot daily will currently do nothing. It won't think that the certificate needs to be replaced since it has not yet reached the limit required to renew. Yep, this. Clients need to be built to support it. I know this is from the linked article and not from you, but: > In order to get all those certificates replaced, we need an efficient and automated way to notify ACME clients that they should perform early renewal. This is already possible. It's called OCSP stapling, and it's what Caddy (and CertMagic) does by default, automatically. When Caddy sees from OCSP that the certificate is revoked, it will automatically replace it.
      - benburwell 5y ago
        Wouldn't clients then only become aware that they need to replace their certs after they've been revoked? I think the desire here would be for a mechanism to alert clients to obtain a new certificate before their current certificate is revoked and becomes invalid. edit: formatting
        mholt 5y ago
        > Wouldn't clients then only become aware that they need to replace their certs after they've been revoked? A certificate that is going to be revoked is as good as revoked. There is no "almost untrusted, but not quite yet" gray area (unless you're talking about expiration dates, which some browsers allow leniency on; but we're talking about revocation, where we know there was a problem or misissuance, whereas expiration is mainly a passive safeguard against indefinite trust). So, once a client sees a "Revoked" OCSP status, it can replace the certificate immediately, before the previous, valid OCSP response expires.
  - kroeckx 5y ago
    The article you point to does not mention anything about certificate transparency. They do not only depend on their own CT log to issue certificates, but also on CT logs run by external parties to issue a certificate. Google's current policy still seems to require them to use 1 Google log, and 1 other non-Google log given the lifetime. They seem to use 1 Google log, and 1 other random log, including their own. I'm doubt the logs will be able to keep up.

fullstop 5y ago

I feel that you've missed the joke. Also, there is no way, at all, that they are going to revoke nearly all of their certs because they were valid for 1 second longer than they should have been. It would mark the end of Let's Encrypt if they did. We've lived with certs that were valid for a second longer than they should have been since the inception of Let's Encrypt, and three months won't kill anyone. edit follows: When they revoked 3% of their certificates, not all of them were able to renew in time due to physical server limitations. The renewals required server administrators to forcibly renew their certificates, and the email address associated with the certificate was contacted to let them know. It would be an unmitigated disaster if 185 million certificates were suddenly revoked.

tingletech 5y ago
Let's Encrypt has capacity to reissue all certificates in 24 hours. I think this is why you are supposed to run certbot every day. https://letsencrypt.org/2021/02/10/200m-certs-24hrs.html https://letsencrypt.org/2021/02/10/200m-certs-24hrs.html
- fullstop 5y ago
  They have the physical infrastructure to do so, but you've missed this part of article you linked: > In order to get all those certificates replaced, we need an efficient and automated way to notify ACME clients that they should perform early renewal. Normally ACME clients renew their certificates when one third of their lifetime is remaining, and don’t contact our servers otherwise. We published a draft extension to ACME last year that describes a way for clients to regularly poll ACME servers to find out about early-renewal events. We plan to polish up that draft, implement, and collaborate with clients and large integrators to get it implemented on the client side. Running certbot daily will currently do nothing. It won't think that the certificate needs to be replaced since it has not yet reached the limit required to renew.
  - mholt 5y ago
    > Running certbot daily will currently do nothing. It won't think that the certificate needs to be replaced since it has not yet reached the limit required to renew. Yep, this. Clients need to be built to support it. I know this is from the linked article and not from you, but: > In order to get all those certificates replaced, we need an efficient and automated way to notify ACME clients that they should perform early renewal. This is already possible. It's called OCSP stapling, and it's what Caddy (and CertMagic) does by default, automatically. When Caddy sees from OCSP that the certificate is revoked, it will automatically replace it.
    - benburwell 5y ago
      Wouldn't clients then only become aware that they need to replace their certs after they've been revoked? I think the desire here would be for a mechanism to alert clients to obtain a new certificate before their current certificate is revoked and becomes invalid. edit: formatting
      - mholt 5y ago
        > Wouldn't clients then only become aware that they need to replace their certs after they've been revoked? A certificate that is going to be revoked is as good as revoked. There is no "almost untrusted, but not quite yet" gray area (unless you're talking about expiration dates, which some browsers allow leniency on; but we're talking about revocation, where we know there was a problem or misissuance, whereas expiration is mainly a passive safeguard against indefinite trust). So, once a client sees a "Revoked" OCSP status, it can replace the certificate immediately, before the previous, valid OCSP response expires.
- kroeckx 5y ago
  The article you point to does not mention anything about certificate transparency. They do not only depend on their own CT log to issue certificates, but also on CT logs run by external parties to issue a certificate. Google's current policy still seems to require them to use 1 Google log, and 1 other non-Google log given the lifetime. They seem to use 1 Google log, and 1 other random log, including their own. I'm doubt the logs will be able to keep up.