CAA fail for domain with no CAA record and no SERVFAIL


#1

Hi team, we are seeing the following error returned:

403 urn:acme:error:caa: Error creating new cert :: Rechecking CAA: While processing CAA for theworkflowexpert.inmotionnow.com: CAA record for theworkflowexpert.inmotionnow.com prevents issuance

However the domain theworkflowexpert.inmotionnow.com does not appear to have a CAA record, and we don’t get a SERVFAIL when doing a query, so it’s not really clear how we can fix this. Any tips from the Boulder logs as to what might be going wrong?

Thanks
Mark


#2

unboundtest also returns no problems:

https://unboundtest.com/m/CAA/theworkflowexpert.inmotionnow.com/74KN4C33

Query results for CAA theworkflowexpert.inmotionnow.com

Response:
;; opcode: QUERY, status: NOERROR, id: 49502
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;theworkflowexpert.inmotionnow.com.	IN	 CAA

;; ANSWER SECTION:
theworkflowexpert.inmotionnow.com.	300	IN	CNAME	live-inmotionnow-theworkflowexpert.pantheonsite.io.
live-inmotionnow-theworkflowexpert.pantheonsite.io.	600	IN	CNAME	fe1.edge.pantheon.io.

;; AUTHORITY SECTION:
edge.pantheon.io.	0	IN	SOA	ns-644.awsdns-16.net. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

#3

A CAA record exists for inmotionnow.com:

0 issuewild "godaddy.com"
0 issue ";"
0 issuewild "starfieldtech.com"
0 iodef "mailto:support@inmotionnow.com"

CAA records are “inherited” by subdomains if they have no CAA record of their own. If you have sufficient control over the subdomain to add your own CAA record on it, you can get around this, but otherwise, you (or whoever controls the domain) would need to change or remove the CAA record on inmotionnow.com.


#4

As @pfg points out (thanks!) the problem is with the parent domain of "theworkflowexpert.inmotionnow.com". A common point of confusion with UnboundTest is that it doesn’t implement the CAA checking algorithm that Boulder uses, it only recreates single queries. This makes sense since it’s a vanilla Unbound instance and Unbound wouldn’t have any need to implement the CAA checking algorithm defined for CAs since it isn’t a CA :slight_smile: To match Boulder’s CAA enforcement you need to manually drive UnboundTest to do a series of queries the same way that Boulder does. E.g. one for theworkflowexpert.inmotionnow.com and then one for inmotionnow.com.


#5

I think we still have some work to do with this error message. I would have expected it to say:

“Error creating new cert :: Rechecking CAA: While processing CAA for theworkflowexpert.inmotionnow.com: CAA record for inmotionnow.com prevents issuance”

I opened https://github.com/letsencrypt/boulder/issues/3171 for this to try and iterate. Apologies, I thought we had fixed this better in https://github.com/letsencrypt/boulder/issues/3094


#6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.