Troubleshoot Certonly: --standalone works but --manual not working

1

Please help me figure what is the most possible cause. --standalone works while --manual does not so it is may not be DNS or port problem. I followed the instruction in manual and even curl to make sure the SimpleHTTPServer is working.

{u’status’: u’invalid’, u’validationRecord’: [{u’url’: u’http://test00.chimne.com/.well-known/acme-challenge/Zal6Ocv5e9xelgzJsianOPHU3e0B7zkZQsnGwiaNdwI’, u’hostname’: u’test00.chimne.com’, u’addressUsed’: u’59.189.187.139’, u’port’: u’80’, u’addressesResolved’: [u’59.189.187.139’]}], u’keyAuthorization’: u’Zal6Ocv5e9xelgzJsianOPHU3e0B7zkZQsnGwiaNdwI.AUiNSxTBzJ1vz2D39ZBtbDoNeMmtiWnlvLygg72hUEk’, u’uri’: u’https://acme-v01.api.letsencrypt.org/acme/challenge/gZFdlCX2y01sXqN8y0_C18gYRnlJ-PFgVvp6iHpBX0w/2957220’, u’token’: u’Zal6Ocv5e9xelgzJsianOPHU3e0B7zkZQsnGwiaNdwI’, u’error’: {u’type’: u’urn:acme:error:connection’, u’detail’: u’Could not connect to http://test00.chimne.com/.well-known/acme-challenge/Zal6Ocv5e9xelgzJsianOPHU3e0B7zkZQsnGwiaNdwI’}, u’type’: u’http-01’}

2

If you put some sort of test file in the /.well-known/acme-challenge/ directory, can you access that file in a web browser?

3

Yes, I can access that file.

  • Any file in the /.well-known/acme-challenge can be accessed in web browser.

  • I am testing with staging --server https://acme-staging.api.letsencrypt.org/directory, but tried with production once or twice and the result is the same.

  • I had tried using the the instruction from MANUAL, using python’s SimpleHTTPServer

  • I had tried using my server nginx and enable both 443 and 80 to serve the challenge.

  • I had tried both replying in content-type: application/octet-stream and text/plain.

  • The MANUAL HTTP-01 will perform a self-verify. Had the file isn’t in the folder, it will throw error before even notify the api to perform the challenge.

  • The weird thing is the STANDALONE can work.

After going through the official client’s code. There is no difference in STANDALONE and MANUAL method of responding to the challenge. The only difference MANUAL requires my intervention which might take 1 or 2 seconds, whereas STANDALONE is immediate. Is it possible whether the 1 or 2 seconds make the api unable to perform the challenge?

4

More info. There is access in the logged. From the user agent, it is the client’s self-verify. The API did not try to access.

59.189.187.139 - - [26/Dec/2015:13:32:58 +0800] “GET /.well-known/acme-challenge/1AA0ZmRt409hM-nktdBZlL2-ip6QdbY8fwLgt9PYNTs HTTP/1.1” 200 - 87 “-” “python-requests/2.9.1” “-”

Since STANDALONE is using its own programmatic web server. I am unable to log easily, I can’t use a proxy (that can log) since I can’t change the port 80 in STANDALONE unless I edit the code. Not that it can’t be done, but not easy.

Again. Since STANDALONE works, all possibility of DNS misconfiguration and port blocking are omitted.

5

Come on,

tcpdump -s 1500 -Ani $interface port 80

and you should be able to see the HTTP flying around.

6

Were you using standalone mode with tls-sni-01? This uses port 443 and TLS as opposed to 80/HTTP.

The fact that self-verify (i.e. local access) works and that you don’t see any requests from the CA server in your logs indicates there’s an issue with your firewall blocking port 80, or a WAF disallowing requests from external IPs to .well-known. I would recommend trying to request the challenge URL through a proxy (e.g. Tor) and see if that works.