3 ms·

But any CA can issue certificates for any domain in our current system. Sure, you can always manually inspect the certificate and see if the root CA is expected

But any CA can issue certificates for any domain in our current system. Sure, you can always manually inspect the certificate and see if the root CA is expected. But does anyone do that at all?

ploxiln 8y ago
I guess you could have an "internal network" browser config with _only_ the DoD CA root.
zjs 8y ago
Any CA can issue certificates for any domain, but they may not be permitted to do so. Certification Authority Authorization (CAA) DNS records can be used to indicate which CA is authorized to issue certificates for a domain. The CA/Browser Forum requires all certificate authorities to check CAA records prior to issuance.
- netheril96 8y ago
  > The CA/Browser Forum requires all certificate authorities to check CAA records prior to issuance. And what if a CA fails to check CAA records? Revoke their status as an authority? By then attackers may have already obtained highly confidential information from DoD sites.
move-on-by 8y ago
Isn't that what the DNS Certification Authority Authorization (CAA) DNS record [1] is supposed to solve? Combine that with certificate transparency enforced with the `Expect-CT` header [2] and its pretty locked down. If a CA does not respect the CAA record and issues anyways, the cert will be logged to a public log. Tools like CertSpotter [3] can be setup to give notifications when certs are created. If a cert is created that should not have, then you can get an alert about it and can begin the reporting and revocation process. If a cert is created without being written to a certificate transparency log, then browsers that support `Expect-CT` header should reject it with a big error message. This works in chrome, but not yet in firefox or safari [4]. [1] https://tools.ietf.org/html/rfc6844 https://tools.ietf.org/html/rfc6844 [2] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Expect-CT https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ex... [3] https://sslmate.com/signup?for=certspotter https://sslmate.com/signup?for=certspotter [4] https://invalid-expected-sct.badssl.com/ https://invalid-expected-sct.badssl.com/

But any CA can issue certificates for any domain in our current system. Sure, you can always manually inspect the certificate and see if the root CA is expected. But does anyone do that at all?

ploxiln 8y ago

I guess you could have an "internal network" browser config with _only_ the DoD CA root.

zjs 8y ago

Any CA can issue certificates for any domain, but they may not be permitted to do so. Certification Authority Authorization (CAA) DNS records can be used to indicate which CA is authorized to issue certificates for a domain. The CA/Browser Forum requires all certificate authorities to check CAA records prior to issuance.

netheril96 8y ago
> The CA/Browser Forum requires all certificate authorities to check CAA records prior to issuance. And what if a CA fails to check CAA records? Revoke their status as an authority? By then attackers may have already obtained highly confidential information from DoD sites.

move-on-by 8y ago

Isn't that what the DNS Certification Authority Authorization (CAA) DNS record [1] is supposed to solve? Combine that with certificate transparency enforced with the `Expect-CT` header [2] and its pretty locked down. If a CA does not respect the CAA record and issues anyways, the cert will be logged to a public log. Tools like CertSpotter [3] can be setup to give notifications when certs are created. If a cert is created that should not have, then you can get an alert about it and can begin the reporting and revocation process. If a cert is created without being written to a certificate transparency log, then browsers that support `Expect-CT` header should reject it with a big error message. This works in chrome, but not yet in firefox or safari [4]. [1] https://tools.ietf.org/html/rfc6844 https://tools.ietf.org/html/rfc6844 [2] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Expect-CT https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ex... [3] https://sslmate.com/signup?for=certspotter https://sslmate.com/signup?for=certspotter [4] https://invalid-expected-sct.badssl.com/ https://invalid-expected-sct.badssl.com/