Most active commenters
  • weird-eye-issue(4)
  • jojobas(3)

←back to thread

181 points zdw | 18 comments | | HN request time: 1.722s | source | bottom
1. weird-eye-issue ◴[] No.44421562[source]
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

replies(2): >>44421824 #>>44422549 #
2. bravesoul2 ◴[] No.44421824[source]
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.

replies(1): >>44422431 #
3. jojobas ◴[] No.44422431[source]
They could just include a local notifier in their scripts, would probably satisfy the majority of users.
replies(1): >>44422446 #
4. kevincox ◴[] No.44422446{3}[source]
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.
replies(1): >>44429098 #
5. jaas ◴[] No.44422549[source]
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.

replies(2): >>44422597 #>>44422793 #
6. mystraline ◴[] No.44422597[source]
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/

Publishing all SSL certs for domains is kind of worse than some random email.

replies(2): >>44422690 #>>44422733 #
7. woodruffw ◴[] No.44422690{3}[source]
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.)

replies(1): >>44422789 #
8. ◴[] No.44422733{3}[source]
9. mystraline ◴[] No.44422789{4}[source]
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.

replies(3): >>44422893 #>>44422970 #>>44423162 #
10. weird-eye-issue ◴[] No.44422793[source]
It didn't need to be a requirement
replies(1): >>44423179 #
11. crabique ◴[] No.44422893{5}[source]
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).

12. jcranmer ◴[] No.44422970{5}[source]
> I just needed encryption... Which a self-signed would be fine. But the internet powers that be deem self-signed as 'evil'.

Self-signed certificates don't actually provide useful encryption, since they are trivially MITM-able.

13. woodruffw ◴[] No.44423162{5}[source]
> The "I want basic encryption for this subdomain but not announce it to the world" seems rather sane as well.

Not really: we learned a hard lesson decades ago that encryption isn’t especially meaningful unless you know who you’re encrypting to. Self-signed certificates are the classic “your communications are secure, but you’re talking with satan” example.

As others have said: if you want to keep a specific subdomain label out of CT, you can issue a wildcard certificate instead. But the Web PKI as a whole is correct in not letting you do encrypted communication with a service without having some established notion of that service’s identity.

14. addandsubtract ◴[] No.44423179{3}[source]
Neither is sending emails :)
replies(1): >>44423577 #
15. weird-eye-issue ◴[] No.44423577{4}[source]
Yeah, but nobody said it was a requirement

But it was obviously valuable enough for them to be doing it for over a decade

I remember it being helpful to me personally when I was using LE when it first came out

16. jojobas ◴[] No.44429098{4}[source]
You could have a weekly canary email as well.
replies(1): >>44430505 #
17. weird-eye-issue ◴[] No.44430505{5}[source]
Yeah and people could just use rsync instead of Dropbox
replies(1): >>44439487 #
18. jojobas ◴[] No.44439487{6}[source]
Of course, whenever it's possible.