I have a general question regarding HTTP challenge. ( acme v1 )
We already identified situations, where a HTTP challenge will fail
- server not reachable on port 80
- server not reachable for the domain
We recently got a response from a customer who had requested a certificate for foo.example.com.
The acoount was created successfully, and the challenge token was placed on the server. The token can be accessed via http://foo.example.com/.well-known/acme-challenge/xyz12345
So port 80 is open and the server can be reached for this domain.
Despite this, the challenge fails.
What other reasons aside from the reasons mentioned above can cause the challenge to fail?
What can I do to find out, what is going wrong?
There are a number of DNS-related issues that can occur, as well as IPv6 misconfiguration.
The best way to diagnose is to read/post the exact error message, or if you can get the ACME order/authz URL from your client’s debug logs, that is helpful too.
You can often figure out what the problem is by trying to issue a staging certificate from Certbot, even if you don’t have control of the domain. Issues relating to DNS and connectivity will still reveal themselves despite not having control over the domain’s webroot.
certbot certonly --manual --preferred-challenges http -d foo.example.com --dry-run
A misconfiguration on Nginx/Apache may also cause failure in challenge.
Thanks _az, did the test run.
This error was expected, because I do not have access to the customers server.
Apparently, there are no DNS related issues.
The server itself ( IBM Domino 9.0.1 ) does not have any rules enabled that would redirect the request. And also the challenge file is accessible without authentication.
You’re right, that indicates that there are probably no DNS/DNSSEC/IPv6 problems.
I think your best bet is to get the ACME client logs off your client’s server, or at least tell us what the domain is and one of the staff members here may be able to look up recent authorization attempts for you.
It’s not the type of problem that lends itself to guesswork very well .
Alex, I have contacted @cpu, but the hint for CAA was great.
a “dig caa foo.example.com” returns SERVFAIL which explains, why the challenge fails.
->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 28973
“dig caa example.com” return an empty CAA record.
I assume, @cpu will confirm it
Thanks again for your help!
I can confirm that the issue with the domain in question (that you provided in DM) returned a CAA error at the time of validation (on Jan 30th):
"Error":"connection :: DNS problem: query timed out looking up CAA for xxxxxx"
SERVFAIL result you shared above would also prevent issuance. Our CAA docs discuss both timeouts and SERVFAIl responses as errors that would prevent issuance.
@eknori - Is it possible the customer has changed nameserver since the 30th? I’m not able to reproduce the
SERVFAIL you saw above, or the timeout, and plugging the domain into http://unboundtest.com also saw a correct
NOERROR response for a CAA lookup. Perhaps the problem has been resolved on the customer end?
Client was able to fix the error.
Thanks for helping me!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.