Hi,
We issue a certificate for a subdomain only through the DNS-01 challenge (the _acme-challenge CNAME that fly certs setup shows), before any A/AAAA record exists. For security we want the CAA to allow only Fly’s Let’s Encrypt account and only DNS-01, as RFC 8657 allows:
0 issue “letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/5417499; validationmethods=dns-01”
With this record (we tried both orders of the two parameters), fly certs check --json returns CAA_RECORD_MISSING_FLY (“CAA records for Let’s Encrypt are missing Fly’s account URI”) and no certificate is issued. Public resolvers and the authoritative name servers serve exactly this one CAA record.
When we briefly changed the record to exactly your remediation text:
0 issue “letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/5417499”
the certificate was issued within about a minute (dns_configured: true). After we restored the record with validationmethods=dns-01, the certificate is still served, but fly certs check again shows “Awaiting configuration”, the certificate as pending_validation, and the same error.
Questions:
- Can your CAA check accept accounturi together with other RFC 8657 parameters, such as validationmethods=dns-01? If not today, is it planned?
- With the strict record in place, will the automatic renewal still be attempted through DNS-01, or will this check block it?
- While the certificate shows pending_validation, will it keep being served, or can it be withdrawn?
- Do you use only this one Let’s Encrypt account for all issuance and renewals?
- If another organization adds the same hostname to its own app, can it get a certificate without our _acme-challenge, _fly-ownership or AAAA record?
We would rather not drop validationmethods=dns-01: the name will sit behind a TCP passthrough proxy, and we want DNS-01 to be the only way a certificate can be issued for it. Happy to share the hostname and app name privately.
Thanks!