4 ms·

If your certificate was issued after the start of the incident but before Let's Encrypt suspended issuance, then the certificate is currently not working in Chr

by agwa 3y ago

If your certificate was issued after the start of the incident but before Let's Encrypt suspended issuance, then the certificate is currently not working in Chrome or Safari. This incident wasn't just about downtime, it was also about issuing non-functional/non-compliant certificates.

mholt 3y ago
Is this because the certs were revoked? (Revocation is broken ;P) Caddy staples Valid OCSP responses to all certificates that have an OCSP responder, so if browsers aren't accepting that, then arguably the clients are broken, because that response is valid until a few days from now. But before the 100% valid and trusted OCSP staple expires, Caddy will get a new staple that presumably says Revoked, and replace them right away before browsers would ever see a Revoked status. (Revocation is broken ;P)
- agwa 3y ago
  No, it's because the SCTs in the certificate have invalid signatures.
  - mholt 3y ago
    Ah, that makes sense! I wonder if we should be doing some basic sanity checks on newly obtained certificates in Caddy, and treat this as a failure, and try the next configured CA instead. (Obviously SCT signatures will require some external resource so we would have to weigh that a bit more, maybe make it configurable...) Issue opened here to discuss, though it does sound troublesome/tedious: https://github.com/caddyserver/certmagic/issues/240 https://github.com/caddyserver/certmagic/issues/240
    - agwa 3y ago
      Yeah, the question is how far you want to go. To be safe against every possible CA screwup, you basically have to re-implement every browser's entire certificate validation engine and run certificates through each one. That would obviously be very hard, and could do more harm than good if it falls out-of-sync with browsers.
    - toast0 3y ago
      It would make sense to try to check this, if there's a reasonable way to access a database of trusted certificate logs. If not, it's going to be tricky; I wouldn't fail a certificate that had a SCT from an unknown log, because it might be valid and you don't know. Etc.

by agwa 3y ago

mholt 3y ago

Is this because the certs were revoked? (Revocation is broken ;P) Caddy staples Valid OCSP responses to all certificates that have an OCSP responder, so if browsers aren't accepting that, then arguably the clients are broken, because that response is valid until a few days from now. But before the 100% valid and trusted OCSP staple expires, Caddy will get a new staple that presumably says Revoked, and replace them right away before browsers would ever see a Revoked status. (Revocation is broken ;P)

agwa 3y ago
No, it's because the SCTs in the certificate have invalid signatures.
- mholt 3y ago
  Ah, that makes sense! I wonder if we should be doing some basic sanity checks on newly obtained certificates in Caddy, and treat this as a failure, and try the next configured CA instead. (Obviously SCT signatures will require some external resource so we would have to weigh that a bit more, maybe make it configurable...) Issue opened here to discuss, though it does sound troublesome/tedious: https://github.com/caddyserver/certmagic/issues/240 https://github.com/caddyserver/certmagic/issues/240
  - agwa 3y ago
    Yeah, the question is how far you want to go. To be safe against every possible CA screwup, you basically have to re-implement every browser's entire certificate validation engine and run certificates through each one. That would obviously be very hard, and could do more harm than good if it falls out-of-sync with browsers.
  - toast0 3y ago
    It would make sense to try to check this, if there's a reasonable way to access a database of trusted certificate logs. If not, it's going to be tricky; I wouldn't fail a certificate that had a SCT from an unknown log, because it might be valid and you don't know. Etc.