Problems with webroorFTP method

[chudak]

Followed this example:
https://www.netgate.com/docs/pfsense/certificates/acme-validation.html#ftp-webroot

Used webroot FTP method, entered domain as sftp://xxx.ddns.net (tried without sftp:// as well)

Can ssh to my router from the internet as well as locally from router prompt with provided credentials.

However failing to issue certificate:

challenge_response_put ACME_XXX_TEST, xxx.ddns.net
FOUND domainitemFTP
[Tue Jan 15 17:21:27 PST 2019] Pending
[Tue Jan 15 17:21:29 PST 2019] Pending
[Tue Jan 15 17:21:31 PST 2019] Pending
[Tue Jan 15 17:21:33 PST 2019] Pending
[Tue Jan 15 17:21:36 PST 2019] Found domain http api file: /tmp/acme/ACME_XXX_TEST//httpapi/pfSenseacme.sh
[Tue Jan 15 17:21:36 PST 2019] xxx.ddns.net:Verify error:Fetching http://xxx.ddns.net/.well-known/acme-challenge/WKEcQg9vY8Q0Fgg4XWEt4sK-oZEtZFGkDVQTwPeIpwI: Timeout during connect (likely firewall problem)
[Tue Jan 15 17:21:36 PST 2019] Please check log file for more details: /tmp/acme/ACME_XXX_TEST/acme_issuecert.log

My pfSense router is is using self-signed CA at the moment.

Any clues appreciated!

Thx

[Gertjan]

Hi !

The answer is easy, it's stated in the log :
This file ".well-known/acme-challenge/WKEcQg9vY8Q0Fgg4XWEt4sK-oZEtZFGkDVQTwPeIpwI" should exist. It's created using the webroot method on your web server. Did you checked if file is really there ? Locate your web server's webroot directory, find the directory called ".well-known" and in there there should be a directory called "acme-challange". In the last you should find the file called "WKEcQg9vY8Q0Fgg4XWEt4sK-oZEtZFGkDVQTwPeIpwI" (and in the file you should find some kind of token).

The logs exists so you can check all this. You can do so - we can't ;)
And do not use the log shown on the screen. That one exists for pure amusement.
Use the log that was mentioned in screen-log lines : /tmp/acme/ACME_XXX_TEST/acme_issuecert.log

The LetEncrypt validating server will access this file using a simple http://xxx.ddns.net/.well-known/acme-challenge/WKEcQg9vY8Q0Fgg4XWEt4sK-oZEtZFGkDVQTwPeIpwI request.
The file wasn't found. It bailed out.

[chudak]

@gertjan

I think I moved ahead a bit but still incomplete win :(

I added NAT to open ports 22,80, 443 and was able to issue/renew certificate.

I see error:

[Wed Jan 16 13:11:55 PST 2019] new-authz error: {"type":"urn:acme:error:malformed","detail":"Error creating new authz :: Name does not end in a public suffix","status": 400}
[Wed Jan 16 13:11:55 PST 2019] Please check log file for more details: /tmp/acme/ACME_WAWONA_TEST/acme_issuecert.log

My router name is like pfsense.<blah>.<blah>

WTH??

[Gertjan]

Where is you webroot situation ? On what device ?

[chudak]

@gertjan

I am trying to issue ACME certificate on my pfsense router box

[Gertjan]

Then hat are you doing with NAT etc ?
the local webroot is ... local.

See here : https://www.netgate.com/docs/pfsense/certificates/acme-validation.html

This method works similar to FTP Webroot but with the files hosted on the firewall itself. This method cannot be utilized by the WebGUI web server as that would mean exposing the GUI to the Internet, which is a major security issue.
This method can, however, be used in conjunction with the HAProxy package to host the files on the firewall itself in some circumstances. See https://forum.netgate.com/post/677786 for details.

IMHO : Not a good solution.

[Grimson]

@chudak said in Problems with webroorFTP method:

Name does not end in a public suffix

Is pretty self-explanatory, you can't create LE certs for private TLDs.

[chudak]

@grimson said in Problems with webroorFTP method:

@chudak said in Problems with webroorFTP method:

Name does not end in a public suffix

Is pretty self-explanatory, you can't create LE certs for private TLDs.

So what @gertjan pointed to See here : https://www.netgate.com/docs/pfsense/certificates/acme-validation.html can NOT be used for local domains ?

Just to confirm ....

[chudak]

@chudak

I guess https://community.letsencrypt.org/t/can-i-create-a-cert-for-a-private-domain/27264

[Grimson]

https://letsencrypt.org/how-it-works/ to get a cert your domain needs to be properly registered in the public DNS system and reachable over the internet. Private TLDs will not work.

[chudak]

@grimson said in Problems with webroorFTP method:

TLD

Well, that's good news !

Painful but useful

Thank you !

[chudak]

@gertjan

To be frank, I think that the fact that Acme can’t be used for local TLD must be underlined in the docs more clearly !

[Gertjan]

Of course you can't ask for a certificate for a domain like network.local. or something like that.

The TLD should exist, or, said otherwise, should be able to resolved on the Internet (not only your LAN). The domain name should exists, or registered against one of the exiting registrars.

You have to buy (actually : rent) a real domain name, or at least control directly or underlying its nae servers (DNS), a service that most registrars offer these days.

Btw : If you use something like a DDNS read this : https://community.letsencrypt.org/t/letsencrypt-https-ssl-for-ddns-net/40263
Some famous laws do apply : because it's free things are extra complicated.
The "webroot method " can be used here.
This webroot, some Internet server, could be local - on your LAN, or elsewhere, as long as the A record of
yourdomaine.ddns.net
points to it.

Btw : This

@gertjan said in Problems with webroorFTP method:

Then hat are you doing with NAT etc ?

was me not understanding you.
You where right, you have to NAT if your web server (webroot) is local for you. Which means that your domain that point to your WAN IP will pass through ports like "443" so the LE server can gain access to the web server to do it's work.
This could be, in a worst case, be the GUI of pfSense. You can see above what has been said about that "solution".
You should NAT to an existing internal web server (the web root method).
This means that acme running on pfSense should place a directory structure and file on that web server. It will be using ssh or sftp so it can do it's magic.

[chudak]

@gertjan

I really want to make sure to get to the bottom of it!

See detail steps: https://pastebin.com/7imkJw6p

[jimp]

Using the webroot method, you'd need to expose your firewall GUI to the web directly, which is dangerous, and it would need to use HTTP not HTTPS, which is insecure for the firewall GUI. Don't do that. There are ways to hook it into haproxy like that, but it is still not ideal.

If you must use a web-based method on the firewall itself, try the "standalone" method instead. You'll probably want to run it on another port (e.g. 8080) and then port forward wan:80 to 127.0.0.1:8080, to avoid a conflict with other services on the firewall itself. There are docs around that describe how to do that in more detail.

tl;dr: You're going about it the wrong way, use a more appropriate method.

[chudak]

@jimp

Thx

Looks like this link is accurate and worked fine

https://blog.artooro.com/2017/02/16/quick-easy-lets-encrypt-setup-on-pfsense-using-acme/

I need to address error:

Potential DNS Rebind attack detected, see http://en.wikipedia.org/wiki/DNS_rebinding
Try accessing the router by IP address instead of by hostname.

Can you confirm that these steps correct to fix this issue, please?

Go to System > Advanced, Firewall/NAT tab. then you need to enable three options:

1. Pure NAT for NAT Reflection mode for port forwards
2. Enable NAT Reflection for 1:1 NAT
3. Enable automatic outbound NAT for Reflection

[chudak]

I checked Disable DNS Rebinding Checks and added the host name to Alternate Hostnames and it ... worked !

As @jimp suggested here https://forum.netgate.com/topic/38870/how-to-get-rid-of-potential-dns-rebind-attack-detected/3