  > One of the issues with sub-CAs (well, X509 certs in general) is that they
  > can be ghosts in that there's no way you'll ever get it as a response
  > on a TLS connection, so automated scanners on that won't find it.

Could you expand on this? I don't have a full grasp of what you're saying (I'm not super knowledgeable in CA stuff).

My understanding is that if something, like a browser, connects to a SSL site, they will either have or can obtain, one way or another, a complete chain all the way up to the root, so there can be no "ghost" certificate. And I would imagine a scanner could do all those same steps, and thus access all the same certs.

Is this a deficiency in scanner software? You seem to indicate it is a fundamental weakness in X509; I'm just trying to understand what.

Could you maybe describe a specific example of what you're describing?

▲ eqvinox 4 hours ago | parent | next [-]

In the most extreme case, you can just issue a certificate and not use it anywhere. If it leaks, it's still a security issue, because it's valid.

More realistically, especially with sub-CAs, they might only be used on e.g. corporate networks. TLS scanners may not be able to reach any of the hosts that uses such a cert. As the sibling post points out, clients checking for the cert in Certificate Transparency logs counters that (adding a requirement that the cert be publicly known, which TLS/X509 by itself very much does not have) — but of course this only helps if your client does CT…

▲

interroboink 4 hours ago | parent [-]

Ah okay, thanks. So to be concrete, something like automation running 'curl' on an internal network might see the full chain, including the weak cert, and be vulnerable, but scanners on the wider internet won't see it. I was confused by "...there's no way you'll ever get it as a response on a TLS connection..." — I guess you just meant a _public_ TLS connection. Or it could be otherwise installed on corporate machines' local cert bundles.

	▲	fc417fc802 21 minutes ago \| parent [-]
		Or it could be provided by a MitM on the public internet opportunistically only when the connecting client matches the fingerprint of curl and the connection originates from a particular ASN.

▲ gruez 4 hours ago | parent | prev [-]

If you're doing a MITM attack, you can selectively intercept certain clients, and only serve the compromised certificate in those cases only. Automated scanners won't pick that up. None of this actually works though, because browsers started mandating certificate transparency.

	▲	ranger_danger an hour ago \| parent [-]
		Please be careful with your phrasing, as there are MANY other critical things on this planet that use TLS certs which are not browsers, and some are extremely difficult/impossible to update. VPNs, embedded software (IoT, automotive, aerospace, medical, industrial etc.), business systems, you name it.