5 ms·

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/ htt

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/ https://crt.sh/ Publishing all SSL certs for domains is kind of worse than some random email.

woodruffw 1y ago
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 1y ago
  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.
  - crabique 1y ago
    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 1y ago
    > 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.
  - woodruffw 1y ago
    > 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.
deleted 1y ago
[deleted]

woodruffw 1y ago

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 1y ago
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.
- crabique 1y ago
  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 1y ago
  > 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.
- woodruffw 1y ago
  > 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.

deleted 1y ago

[deleted]