30

If I understand correctly, Certification Authority Authorization DNS records are used to specify which certificate authorities are allowed to issue certificates for a given domain. If that record exists and a CA is not listed on it, that CA must refuse to issue a certificate for the domain.

However, this doesn't seem to protect against vulnerabilities in the CA. If any trusted authority doesn't implement CAA properly, or if an authority's private keys are breached, then CAA doesn't help.

My question is, why don't browsers check CAA records? If the certificate given was not issued by a CA authorized in the record, then it would consider the certificate invalid. This would greatly increase security by reducing the list CAs that must be trusted to only the ones the website owner chooses to trust.

I understand that HPKP is also used to prevent bad certificates. However, it only works with HTTP, and it requires either trusting the first certificate received for a site, or trusting a third-party preload list.

So is this something that browsers could implement, or am I missing something here?

Improve this question

2 Answers 2

Reset to default
32

I just found the answer in RFC 6844, DNS Certification Authority Authorization (CAA) Resource Record:

A set of CAA records describes only current grants of authority to issue certificates for the corresponding DNS domain. Since a certificate is typically valid for at least a year, it is possible that a certificate that is not conformant with the CAA records currently published was conformant with the CAA records published at the time that the certificate was issued. Relying Applications MUST NOT use CAA records as part of certificate validation. [emphasis mine]

Basically, it is not the purpose of CAA to describe which certificates are currently valid for a domain. If a certificate is issued when the CA is on the record, and the record is later removed, then the certificate should remain valid until it expires (or is revoked).

Validation of certificates in the browser (or Relying Application) through DNS appears to be the purpose of DANE, or DNS-Based Authentication of Named Entities, specified in RFC 6698. Unfortunately, DANE is not widely implemented.

Improve this answer
1
  • 2
    Objectively, this comment does not answer the question of "WHY" due to its lack of the word "BECAUSE" or anything synonymous with that word. See my answer for the reason "WHY".
    – 8vtwo
    Aug 29, 2021 at 21:20
-2

Browsers are not allowed to check CAA records because it would decrease Root CA trust and strengthen end-user trust, thereby reducing the power of Root CAs and help to fix what is currently a broken trust system.

Real SSL security would allow end users (not website headers) to pin the security certificate they trust because they could verify it from multiple locations, or validate it in person, etc.

Even if they were able to check via DNS if the cert is legitimate, while not perfect, this still reduces the need to trust the Root CA because the user who controls the domain is the "end user" relative to the viewing "end user" (barring any DNS exploits)

Browser makers do not want users to have this power because it would disrupt the system of false "trusted" signers (which don't deserve our trust and have done nothing to earn it).

The current CA system is designed to issue bad certs on demand through their lower certificate authorities (due to its current ease of issuance). CAA records are made for the Root Certificate Authorities so they can know who is abusing issuance allowing them to either take action or allow it.

CAA does nothing to strengthen the security of users online. It is not "for us".

This is why it is impossible to get SSL certificate information in browser extensions. Otherwise, we could just implement this system ourselves and never worry about "trusted" certificate authorities again.

Improve this answer
6
  • 3
    That's a lot of accusations and claims. Do you have any proof or anything to back up these claims that this is the intent?
    – schroeder ♦
    Aug 28, 2021 at 21:34
  • And your logic does not hold. Yes, it would be convenient for you if browsers permitted this function, but that's simply not what the purpose is. All in all, this is just a wild conspiracy theory based on a missed opportunity you see. And in all this, you don't address the issue raised by the accepted answer: that things change over time, so 'pinning' has to account for that, too.
    – schroeder ♦
    Aug 28, 2021 at 21:39
  • The accepted answer does not answer the question.
    – 8vtwo
    Aug 29, 2021 at 18:09
  • Real SSL security would allow end users (not website headers) to pin the security certificate they trust This would be an absolute disaster. Have you heard of pinning suicide? This is would cause pinning suicide on a massive scale. Even sophisticated users who think they know what they're doing would get this wrong. The resulting chaos would actually make MITMs much more likely to succeed.
    – President James K. Polk
    Sep 24, 2021 at 23:07
  • Not "just" SSL pinning like it's some kind of babies toy, but a real system that can analyze the different parts of ALL the certificate (and 3rd parties too) and see if there are any disparate changes that don't make sense and can build a security threat score based on how badly the certificates changed since last seen and the WAY they've changed. The firefox plugin "Certificate Watch" has the right idea, and it just stays green most of the time until there's a problem.
    – 8vtwo
    Sep 26, 2021 at 0:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .