This complicated setup worked in October, but now I’m getting this back-
{
"type": "dns-01",
"status": "invalid",
"error": {
"type": "urn:acme:error:connection",
"detail": "DNS problem: query timed out looking up CAA for gslb454647.ilabs.io",
"status": 400
},
I can verify that the acme challenge TXT record exists on the ilabs.io nameservers, so I’m concerned that it’s checking the gslb.ilabs.io nameserver instead, but I don’t know. I’m also not totally sure if this should work.
I don’t see any reason why that wouldn’t work in general. Your issue seems to be with the gslb454647.ilabs.io nameservers aren’t responding to CAA queries. These are mandatory checks now for all public CAs (as of mid-September 2017), so the timeout will block issuance. You may want to check on what’s going on there to start.
The gslb.ilabs.io nameservers are internal testing things that get turned on and off, I’m trying to clarify that (if?) the whole flow should be independent of them, since gslb454647.ilabs.io lives on the top level.
ilabs.io itself is hosted on Route53, which is supposed to support CAA, and this whole flow works for dozens of other domains in ilabs.io, before and after this particular set of records stopped working. They don’t have SANs that are CNAMEs to subdomains with independent nameservers though.