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