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



  • [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?


  • Rebel Alliance Developer Netgate

    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.



  • @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?



  • @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.



  • 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?



  • 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 ,  ;)


  • Rebel Alliance Developer Netgate

    @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.



  • 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.

    1. 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.

    2. Under "Services / Acme / Certificate options: Edit" it's easy to miss the small little "+" for RootFolder under Domain SAN list.
      Here's the spot!
      Domain SAN list small plus
      Ensure that the directory is specified.

    3. 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.