If they're that worried about having some random email associated, then perhaps they shouldn't also publish all certs they cut for domains?
Publishing all SSL certs for domains is kind of worse than some random email.
Publishing all SSL certs for domains is kind of worse than some random email.
(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.)
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.
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).
Self-signed certificates don't actually provide useful encryption, since they are trivially MITM-able.
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.