4 ms·

A company like Postmark should have just given them a free account on the condition they mentioned them at the bottom of emails or something It's a valuable se

A company like Postmark should have just given them a free account on the condition they mentioned them at the bottom of emails or something It's a valuable service for the average person to get these emails without having to set up separate monitoring

bravesoul2 1y ago
At least there is this: > For those who would like to continue receiving expiration notifications, we recommend using a third party service such as Red Sift Certificates Lite (formerly Hardenize). Red Sift’s monitoring service providing expiration emails is free of charge for up to 250 certificates. More monitoring options can be found here.
- jojobas 1y ago
  They could just include a local notifier in their scripts, would probably satisfy the majority of users.
  - kevincox 1y ago
    I don't think this is nearly as effective of a solution. It stops working if the script is crashing before hitting the notification, it doesn't work if you break your email setup (which for an email that almost never sends is likely to go unnoticed forever) it also fails if you accidentally stop running a script or remove the certificate from your config entirely.
    - jojobas 1y ago
      You could have a weekly canary email as well.
      - weird-eye-issue 1y ago
        Yeah and people could just use rsync instead of Dropbox
        jojobas 1y ago
        Of course, whenever it's possible.
jaas 1y ago
A free account for sending emails would not have changed the decision because it doesn't solve this: "Providing expiration notification emails means that we have to retain millions of email addresses connected to issuance records. As an organization that values privacy, removing this requirement is important to us." Now there is no contact information associated with issuance records.
- mystraline 1y ago
  If they're that worried about having some random email associated, then perhaps they shouldn't also publish all certs they cut for domains? https://crt.sh/ https://crt.sh/ Publishing all SSL certs for domains is kind of worse than some random email.
  - woodruffw 1y ago
    That’s how CT works. They can’t not publish end-entity certificates to CT logs. (But also, even if they could avoid this somehow: the entire point of a public CA is to publish end entity certificates. The “I want a public certificate while keeping a subdomain secret” model was never particularly coherent.)
    - mystraline 1y ago
      The "I want basic encryption for this subdomain but not announce it to the world" seems rather sane as well. I dont need cert transparency either. I just needed encryption... Which a self-signed would be fine. But the internet powers that be deem self-signed as 'evil'. And more webtech requires SSL (like you, websockets). Can't even use it locally without SSL. Paying $x00 for a SSL from some commercial vendor is laughable these days, unless you need a code cert or a onioncert.
      - crabique 1y ago
        Get a wildcard for the apex domain/higher-level subdomain, the "secret" subdomain will be covered implicitly. If you don't want the certificate to be in the CT logs, your only options are a private CA or things like CF Origin certificate, depending on how the domain is intended to be accessed. It's not the end user that "needs" CT, it is a mechanism to ensure no shady CA can misissue a certificate without being caught. Requirements like that are written in blood (see Symantec).

bravesoul2 1y ago

At least there is this: > For those who would like to continue receiving expiration notifications, we recommend using a third party service such as Red Sift Certificates Lite (formerly Hardenize). Red Sift’s monitoring service providing expiration emails is free of charge for up to 250 certificates. More monitoring options can be found here.

jojobas 1y ago
They could just include a local notifier in their scripts, would probably satisfy the majority of users.
- kevincox 1y ago
  I don't think this is nearly as effective of a solution. It stops working if the script is crashing before hitting the notification, it doesn't work if you break your email setup (which for an email that almost never sends is likely to go unnoticed forever) it also fails if you accidentally stop running a script or remove the certificate from your config entirely.
  - jojobas 1y ago
    You could have a weekly canary email as well.
    - weird-eye-issue 1y ago
      Yeah and people could just use rsync instead of Dropbox
      - jojobas 1y ago
        Of course, whenever it's possible.

jaas 1y ago

A free account for sending emails would not have changed the decision because it doesn't solve this: "Providing expiration notification emails means that we have to retain millions of email addresses connected to issuance records. As an organization that values privacy, removing this requirement is important to us." Now there is no contact information associated with issuance records.

mystraline 1y ago
If they're that worried about having some random email associated, then perhaps they shouldn't also publish all certs they cut for domains? https://crt.sh/ https://crt.sh/ Publishing all SSL certs for domains is kind of worse than some random email.
- woodruffw 1y ago
  That’s how CT works. They can’t not publish end-entity certificates to CT logs. (But also, even if they could avoid this somehow: the entire point of a public CA is to publish end entity certificates. The “I want a public certificate while keeping a subdomain secret” model was never particularly coherent.)
  - mystraline 1y ago
    The "I want basic encryption for this subdomain but not announce it to the world" seems rather sane as well. I dont need cert transparency either. I just needed encryption... Which a self-signed would be fine. But the internet powers that be deem self-signed as 'evil'. And more webtech requires SSL (like you, websockets). Can't even use it locally without SSL. Paying $x00 for a SSL from some commercial vendor is laughable these days, unless you need a code cert or a onioncert.
    - crabique 1y ago
      Get a wildcard for the apex domain/higher-level subdomain, the "secret" subdomain will be covered implicitly. If you don't want the certificate to be in the CT logs, your only options are a private CA or things like CF Origin certificate, depending on how the domain is intended to be accessed. It's not the end user that "needs" CT, it is a mechanism to ensure no shady CA can misissue a certificate without being caught. Requirements like that are written in blood (see Symantec).