search

smallstep / certificates

🛡️ A private certificate authority (X.509 & SSH) & ACME server for secure automated certificate management, so you can use TLS everywhere & SSO for SSH.
https://smallstep.com/certificates
Apache License 2.0
6.4k stars 420 forks source link

Validate request based on CAA DNS record #887

Open mpiscaer opened 2 years ago

mpiscaer commented 2 years ago

What would you like to be added

For example the ACME validation process does not check for the CAA record of the Domain name

Why this is needed

To validate if the request is valid and authorized to make the request.

dopey commented 2 years ago

Hey @mpiscaer thanks for reporting the issue. Apologies that it's taken me so long to get back to you. We have a weekly triage for new open issues, but at our last meeting no one had experience with CAA records so we had to punt until I had the chance to do some research. We're regrouping again tomorrow and I'll update with the result of that discussion.

For posterity, Boulder does validate against the CAA record: https://github.com/letsencrypt/boulder/issues/1231.

dopey commented 2 years ago

Following up - I'm going to brain dump our internal discussion here.

  1. step-ca is used as a private CA for private PKI. While Let's Encrypt and other public CAs should verify against CAA records, the expectations from private CAs may be different.
  2. If we were to implement this check it would need to be configurable for all provisioners or authority wide.
  3. We are weary to introduce a new feature that likely won't be easily understood by many users. I've been working closely to PKI for a while now, and I had to look up how CAA records are used.
  4. Even if the authority is enforcing it, authority administrators could always circumvent the rule by changing the configuration. So we wouldn't actually be standards compliant.
  5. To address a similar use case, we are releasing a feature called "allow/deny ACLs". At an authority level you will be able to say "this authority can only sign requests for these domain names" and/or "this authority cannot sign requests for these domain names". We believe that this is concept more natural to the expected behavior of an internal CA.

We care deeply about what we've built and how it fits into the broader ecosystem. We also go out of our way to be standards compliant when we think it makes sense. But, there's enough nuance here that we don't think it makes sense in this case. Let us know what you think!

gclawes commented 9 months ago

Just to bump this up a bit, CAA records (and specifically the RFC 8657 ACME-CAA extension) have come up in relation to a rather well publicized traffic interception attack:

https://notes.valdikss.org.ru/jabber.ru-mitm/ https://www.devever.net/~hl/xmpp-incident https://snikket.org/blog/on-the-jabber-ru-mitm/