5 ms·

You are supposed to be able to revoke the certificate you misissue. LetsEncrypt automated the certificate creation, which resulted in very large number of cert

You are supposed to be able to revoke the certificate you misissue. LetsEncrypt automated the certificate creation, which resulted in very large number of certificate issued. But at the same time, it should be possible to revoke them all. If the revocation mechanism doesn't scale as much as the creation, this is a huge problem. This time, the misissued certificates probably won't cause large issues. But they are misissued nevertheless and should be revoked. If they are not revoked because it would be too complex and will break WebPKI, then what will happen when a larger issue happen that require the revocation ?

ceejayoz 5y ago
> If they are not revoked because it would be too complex and will break WebPKI, then what will happen when a larger issue happen that require the revocation ? As here, the severity of the issue should be weighed against the severity of revocation. "Half the internet needs to manually renew some certs early" is a reasonable approach if there's something risking exposure of sensitive data. It's not for "the certificate is valid for an extra second".
- schoen 5y ago
  By the way, following an earlier issue that did result in revocations, Certbot added logic where the certificate will automatically be renewed early if an OCSP check shows it is no longer valid. That means that early revocations may not cause outages for sites that are successfully using automated renewal with Certbot. Of course, those sites are a minority and possibly not even a plurality, but in theory revocation can be made a smaller burden over time as more sites are using automation successfully. I also know there are tons of Let's Encrypt users who are still using a completely manual workflow. Some of them just don't understand some part of the automation concept, while others have devices and/or operating systems where they simply can't automate certificate renewal, because they couldn't install any software that would facilitate it.
  - lilyball 5y ago
    Doesn’t that mean the cert is already invalid by the time certbot notices, so you already have an outage? And if certbot is running daily then that outage could be up to 24 hours.
    - mholt 5y ago
      Not if the last valid OCSP response is stapled to the certificate. Of course, clients can ignore that and use their own revocation lists/logic, which sometimes get pushed faster than OCSP responses. (Or clients can just block any certificates/CAs they want to, really.)
    - patrakov 5y ago
      Technically, yes. However, if the certificate is used with With HAproxy or any other solution that provides a stapled OCSP response from some kind of cache (e.g. as a file updated by cron), it is possible to avoid the outage completely by fetching the fresh OCSP response every day, and not updating the on-disk copy if it says "bad". This way, the old but still valid copy is served to customers while the system takes the necessary steps to renew the certificate.
    - schoen 5y ago
      There was an idea we discussed of "intent to revoke", but it ended up looking like a quite a bit of work for a small benefit, so the situation is as mholt describes. :-) For this specific reason, Certbot is recommended to run twice per day, and that is the default behavior in OS Certbot packages as well as the more recent official snap package. Further to mholt's point, not all clients will enforce OCSP at all, while if you're using stapling, the client is being told about the last-valid OCSP response, so the outage would probably be a fairly small minority of clients in either case.
      - kiwijamo 5y ago
        I know of at least one OS Certbot package where the check is only done weekly--FreeBSD. Would be interested to know if the twice-daily approach is the default in other OS packages.

ceejayoz 5y ago

> If they are not revoked because it would be too complex and will break WebPKI, then what will happen when a larger issue happen that require the revocation ? As here, the severity of the issue should be weighed against the severity of revocation. "Half the internet needs to manually renew some certs early" is a reasonable approach if there's something risking exposure of sensitive data. It's not for "the certificate is valid for an extra second".

schoen 5y ago
By the way, following an earlier issue that did result in revocations, Certbot added logic where the certificate will automatically be renewed early if an OCSP check shows it is no longer valid. That means that early revocations may not cause outages for sites that are successfully using automated renewal with Certbot. Of course, those sites are a minority and possibly not even a plurality, but in theory revocation can be made a smaller burden over time as more sites are using automation successfully. I also know there are tons of Let's Encrypt users who are still using a completely manual workflow. Some of them just don't understand some part of the automation concept, while others have devices and/or operating systems where they simply can't automate certificate renewal, because they couldn't install any software that would facilitate it.
- lilyball 5y ago
  Doesn’t that mean the cert is already invalid by the time certbot notices, so you already have an outage? And if certbot is running daily then that outage could be up to 24 hours.
  - mholt 5y ago
    Not if the last valid OCSP response is stapled to the certificate. Of course, clients can ignore that and use their own revocation lists/logic, which sometimes get pushed faster than OCSP responses. (Or clients can just block any certificates/CAs they want to, really.)
  - patrakov 5y ago
    Technically, yes. However, if the certificate is used with With HAproxy or any other solution that provides a stapled OCSP response from some kind of cache (e.g. as a file updated by cron), it is possible to avoid the outage completely by fetching the fresh OCSP response every day, and not updating the on-disk copy if it says "bad". This way, the old but still valid copy is served to customers while the system takes the necessary steps to renew the certificate.
  - schoen 5y ago
    There was an idea we discussed of "intent to revoke", but it ended up looking like a quite a bit of work for a small benefit, so the situation is as mholt describes. :-) For this specific reason, Certbot is recommended to run twice per day, and that is the default behavior in OS Certbot packages as well as the more recent official snap package. Further to mholt's point, not all clients will enforce OCSP at all, while if you're using stapling, the client is being told about the last-valid OCSP response, so the outage would probably be a fairly small minority of clients in either case.
    - kiwijamo 5y ago
      I know of at least one OS Certbot package where the check is only done weekly--FreeBSD. Would be interested to know if the twice-daily approach is the default in other OS packages.