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