ACME / Let's Encrypt - "Verify error:Fetching: Timeout"

riahc3

[Fri Mar 16 19:32:28 CET 2018] mydomain.duckdns.org:Verify error:Fetching http://mydomain.duckdns.org/.well-known/acme-challenge/333333333JoEjWHijuBIs-fBJkpj7PJy_LLL0OdxH5I: Timeout

Thats the error I am getting.

Further logs:

[Fri Mar 16 19:32:29 CET 2018] responseHeaders='HTTP/1.1 100 Continue
Expires: Fri, 16 Mar 2018 18:32:29 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache

HTTP/1.1 400 Bad Request
Server: nginx
Content-Type: application/problem+json
Content-Length: 144
Boulder-Requester: 31278434
Expires: Fri, 16 Mar 2018 18:32:29 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache
Date: Fri, 16 Mar 2018 18:32:29 GMT
Connection: close

'
[Fri Mar 16 19:32:29 CET 2018] response='{"type":"urn:ietf:params:acme:error:malformed","detail":"Unable to update challenge :: The challenge is not pending.","status": 400}'
[Fri Mar 16 19:32:29 CET 2018] code='400'

Im using the webroot FTP method

sftp://mydomain.duckdns.org
myusername
mypassword (Why is this in plain text and isnt a password field?)
/usr/local/www/.well-known/acme-challenge/

I connected using Filezilla to sftp://mydomain.duckdns.org using the same myusername to /usr/local/www/.well-known/acme-challenge/ and I can write in that folder.

If I open a web browser and I got to http://mydomain.duckdns.org/.well-known/acme-challenge/333333333JoEjWHijuBIs-fBJkpj7PJy_LLL0OdxH5I, it downloads the file.

What is wrong?

jimp

The timeout would indicate that acme.sh was unable to reach that domain.

Is mydomain.duckdns.org pointing to the firewall itself? Forwarded using NAT maybe? If so, the firewall itself may not be able to complete that request because of how it's handled. It may work in your browser due to NAT reflection, for example, that would not apply to traffic from the firewall itself.

You might need a host override on the firewall to resolve that name to your own local web server.

riahc3

@jimp:

Is mydomain.duckdns.org pointing to the firewall itself?

Yes.

I can reach it from the outside world as well…

@jimp:

You might need a host override on the firewall to resolve that name to your own local web server.

How do I do this?

Gertjan

@riahc3:

I can reach it from the outside world as well…

Ok, you can, but the server from Letsencrypt (and probably any visitor from the net) , can't - the message was :
@riahc3:

[Fri Mar 16 19:32:28 CET 2018] mydomain.duckdns.org:Verify error:Fetching http://mydomain.duckdns.org/.well-known/acme-challenge/333333333JoEjWHijuBIs-fBJkpj7PJy_LLL0OdxH5I: Timeout

Btw : I can't neither : http://mydomain.duckdns.org/.well-known/acme-challenge/333333333JoEjWHijuBIs-fBJkpj7PJy_LLL0OdxH5I

This
@riahc3:

I connected using Filezilla to sftp://mydomain.duckdns.org using the same myusername to /usr/local/www/.well-known/acme-challenge/ and I can write in that folder.

means you are using the web server used by the pfSense GUI.

This means that this test should succeed :
@jimp:

Is mydomain.duckdns.org pointing to the firewall itself? Forwarded using NAT maybe?

You should be able to visit the web GUI of pfSense from the Internet.
You understood why this method is not advised at all ? See Webroot Local Folder here https://doc.pfsense.org/index.php/ACME_package#Webroot_Local_Folder
It's very dirty/dangerous method, because a firewall and NAT rule should be put in place every time every time before renewing.
This means the method will stay manual. Not a good idea neither.

So, basically :
If mydomain.duckdns.org doesn't resolve to an IP - one you control,
And if behind this IP isn't running a web server on port 80,
And if on this web server, in the web root directory (== /usr/local/www/ = webroot of the pfSense GUI) isn't this directory and sub directory ".well-known/acme-challenge/"
And if in this last directory isn't a file called "333333333JoEjWHijuBIs-fBJkpj7PJy_LLL0OdxH5I"
And if the contents of this file isn't the secret key (it is put there by the acme script),
Then verification failed.

And it failed.

edit :
@riahc3:

I can reach it from the outside world as well…

So you can "visit" and see the content, the secret key, of this file also :
http://mydomain.duckdns.org/.well-known/acme-challenge/333333333JoEjWHijuBIs-fBJkpj7PJy_LLL0OdxH5I
?

Test from the outside - use your smartphone (not wifi connected), not from LAN.

riahc3

Damn, I put por 89 instead of 80 in my firewall.

My fault.

So although the cert is downloaded I see, does it get autoinstalled?

Gertjan

Did you check ?
Here : System => Certificate Manager => Certificates

If, for example, you actually use the certificate, like here System => Advanced => Admin Access then you should read again the settings page for your acme settings page :

Actions list
Used to restart webserver processes after this certificate has been renewed
Examples:

Restart the GUI on this firewall: Select "Shell Command" and enter /etc/rc.restart_webgui
Restart HAProxy on this firewall: Select "Shell Command" and enter /usr/local/etc/rc.d/haproxy.sh restart
Restart a local captive portal instance: Select "Restart Local Service" and enter captiveportal zonename replacing zonename with the zone to restart.
Restart the GUI of an HA peer: Select "Restart Remote Service" and enter webgui. This utilizes the system default HA XMLRPC Sync Settings.

I'll bet everything is clear now , ;)

jimp

@riahc3:

@jimp:

You might need a host override on the firewall to resolve that name to your own local web server.

How do I do this?

Go into the DNS Resolver or DNS Forwarder, whichever you use, and add an override that points that name to your local web server. Then anything local that tries to hit that hostname will go directly and will not need to pass through NAT.

lifeboy

I'm posting this response simply to add to the information here on the configuration of the acme plugin to successfully create/renew a Let'sEncrypt certificate. I had quite a struggle to get it to work and also got a timeout error message.

It seems essential that port 80 is open for the pfSense web interface. Under "System / Advanced / Admin Access" the WebGUI redirect" tickbox must not be ticked, to allow port 80 to be redirected to port 443. If this is ticked, port 80 does not respond and the certbot script to fails.
Under "Services / Acme / Certificate options: Edit" it's easy to miss the small little "+" for RootFolder under Domain SAN list.
Here's the spot!

Ensure that the directory is specified.
Lastly, I have created a firewall rule that allows port 80 access to "this firewall" in the WAN rules. I did this before I discovered point 1 above, so it may not be required, but I'm not going to delete my cert now to test it again :-)

Hope that helps future finders of this thread.