[jaas]

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.

[weird-eye-issue]

It didn't need to be a requirement

[addandsubtract]

Neither is sending emails :)

[weird-eye-issue]

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

[mystraline]

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.

[woodruffw]

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]

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.

[woodruffw]

> 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.

[crabique]

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).

[jcranmer]

> 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.