@user1234 said in PfSense ACME 0.1.23 Package Google Cloud DNS Question:

@jimp Logging into gcloud without any user interaction is definitely possible. If you would allow, in the pfSense GUI, for users to configure a service account key for Google Cloud DNS, that key could:

be written to disk and it's path saved in the GOOGLE_APPLICATION_CREDENTIALS environment variable. gcloud picks up on this environment variable to pinpoint the location of the credentials file, which it uses to authenticate all outgoing requests. Using this method, no change would be required in the acme-sh Google Cloud DNS script. More details in google cloud's documentation. be saved into an environment variable passed and then passed as an argument to the acme-sh Google Cloud DNS script which would use it to authenticate gcloud: echo $SERVICE_ACCOUNT_KEY | gcloud auth activate-service-account --key file -. Obviously, this would entail updating the acme-sh script to perform this action.

I'm new to this community and would love to contribute to see this integration happen. Of the above two solutions, which one would you find acceptable?

I was mistaken, the first method of authentication refers to using Google API SDKs. The second one, however, is valid. It is documented here.

The acme-sh wiki also mentions that gcloud will use the default configuration which they do not in any way alter. A gcloud configuration is a saved named preset of a SDK properties.

SDK properties can be set via:

gcloud itself, documented here. environment variables, documented here.

To summarize the above, in order to authenticate and configure gcloud so that the acme-sh script does not require running the interactive gcloud init, you would have to:

run echo ¨$GCP_SERVICE_ACCOUNT_KEY_VALUE¨ | gcloud auth activate-service-account --key-file -. Where GCP_SERVICE_ACCOUNT_KEY_VALUE contains the value of Google Cloud Service Account key file (creating service account keys). configure the required gcloud properties to run the commands used in the script. These properties most certainly include the GCP project value. Configuration can be performed either of the above described methods: gcloud config set; environment variables.

None of these steps are interactive. I work a lot with Google Cloud, their SDKs, services and APIs. While the acme-sh wiki Google Cloud DNS is correct to recommend gcloud init to perform authentication and configuration, this is most certainly, as documented by Google, not the only way to do it. CI / CD environments, similar to the use-case here, have a different flow, as I have explained above.

So, I will firstly create a PR to fix documentation in the acme-sh repository so that it is less confusing to people looking to set acme up for working with Google Cloud DNS in a non interactive manner.

Secondly, if there is any way I can help make the above changes to enable the Google Cloud DNS integration in pfSense ACME, I would love to lend a hand.

👍 @regexaurus

Alternative ways to kill the duck-bug :

Instead of the always needed SSH - so ok to have it set up ones : use the classic console access, as this should work to.

Or : install the System_Patches pfSense package, which exists for doing just that.
Now, if we can get our hand on raw the diff file (and get the paths correctly) its just a question of copying the commit ID URL and two more clicks (patching without a keyboard).

@lftiv Thanks so much for that! I had renamed the keys at some point since last renewal and was at my wits end why it wasn't working.
So sad that this is still a problem!

@jimp Thanks for the suggestion. I do get the following error on reboot with filesystem check, even after uninstalling the haproxy package in the GUI.

11:24:34 PHP ERROR: Type: 64, File: Standard input code, Line: 4, Message: require_once(): Failed opening required 'haproxy/haproxy.inc' (include_path='.:/etc/inc:/etc/inc/web:/usr/local/www:/usr/local/captiveportal:/usr/local/pkg:/usr/local/www/classes:/usr/local/www/classes/Form:/usr/local/share/pear:/usr/local/share/openssl_x509_crl/')

I just updated from 2.4.5 to 21.02 with an image from Netgate. I will try reinstalling it.

@appollonius333 said in Using ACME with Bind9 package and Cloudflare:

You think it will do any harm to use a public domain for my private network?

As long as the you own (= rented) the domain name : you have no choice.
You can only asks for certs for domain names for which you can prove that you control.

@appollonius333 said in Using ACME with Bind9 package and Cloudflare:

I hear people saying yes because it increases your attack surface but others also say no because they do not know where the 'domain' is aiming to. Also nobody knows the domain exempt me.

Yeah, there are also people that want phones without numbers.
An cars without licence plates.
Etc.
If you want to use a public 'thing', you have to conform to the usage rules of the public thing.
IP addresses and host names can't really be hidden.

Asking a cert from Letsencrypt for a domain name doesn't make that domain name publicly known, although it will figure on yet another (huge !) list ^^

Your domain name doesn't have to point to the IP of your WAN, or something like that.
But that's what I'm doing :
I have this my-domaine.net that I'm actually using just for my LAN, like pfSense, my NASes, printers and such. I'm not really using this domain name on the net. I have acme.sh asking for a wild car cert, so I can create host names with a cert like
pfsense.my-domaine.net, nas .my-domaine.net, printer1.my-domaine.net, printer2.my-domaine.net, airco.my-domaine.net etc. Now all these devices have https access.

I did create a sub domain like home.my-domaine.net on the name server (my own 'bind' based name servers) on the internet, have this sub domain pointing to my WAN IP (using DDNS if it's not static) so I can access my pfsense from else here, using OpenVPN. this is what I'm doing (and not related to acme).

Btw : lab.nl is a domain that is owned (rented) by some one. You can't use it.

@lrossi said in How to Install Certificates from PFsense to other servers?:

I tried to follow the videos from Lawrence Technologies for the HAProxy but for the life of me I couldn't make it work.

HAProxy uses a cert from the cert list.
Like the GUI select box for the acme cert :

6311c2fc-30e6-4683-90b0-73545be4e8ca-image.png

Like this :

e0d9f7a2-5d7e-4c3b-bde6-a251a00c1f2b-image.png

that should do it.

Btw : I'm not using ha-proxy myself.

aa4ad270-b4a6-4a6e-adf7-7d7d66ba2bda-image.png

As discussed here a month ago : Let's Encrypt Certificate Authority Expiring soon : do what has been suggested over there.

We have 2.5.0 now, the GUI warns us.
Still, up to use to use the buttons :

353c0e68-9a66-4784-92f2-2fde461dc2dd-image.png

@gschmidt
i would go for the haproxy-devel one.. that would be the 0.62 at this moment.

@flemmingss

Hi Flemmings,

I do the same and worked.
After you can change again to cname *.duckdns.org and renew certificate again.
now is working fine.

thanks to all

@mbentley said in Let's Encrypt Certificate Authority Expiring soon:

It doesn't have anything to do with a pfSense version or a plugin version - the timing is just a coincidence.

The only strange thing is that on 2.5.0 this causes a notification, but on 2.4.5 not.
Maybe is something that they added in the new version and that i haven't read yet in the changelog.

@gertjan said in Let's Encrypt Certificate Authority Expiring soon:

https://letsencrypt.org/certificates/

I literally just finished reading it!

So the "old" one is safe to delete it, that's the important thing!

Thanks to everyone!

@foolish86 :)Who gave me that tip was @Gertjan, thanks to him we both got our certificates.

Just to revisit this thread.... I was having problems renewing my Namecheap Let's Encrypt certificate using the manual method so figured I would give this a try. It was all quite easy - the request in namecheap for API key was instant so seemingly automatic.
You do have to whitelist the IP of the pfSense machine though... without having that IP in the whitelisted section of the namecheap API page results in an error when trying to issue the certificate. Other than that... all seems to work well - Thanks.

The HAProxy hint did the trick. For others searching, here is what I did on HAProxy config:

Defined a specific backend pointing on 127.0.0.1 with the port defined on ACME config On the frontend added an ACL to forward the requests for which path starts with /.well-know/... onto the previous backend

Seems to work fine.
Don't hesitate to suggest any improvement though.
In another hand I saw that it could be a small security breach, but I don't see the issue, I'd be interested to know.

Thanks for the help.

@tlex forget it I found it :P
2c8dc80d-eb3a-429c-8b8a-fecf788629d8-image.png

0f3482cf-3a71-4a17-82d4-5da3ab20a12b-image.png

You would want to raise that issue with the acme.sh project directly, since we do not maintain the code which interacts with DNS providers, they do.

https://github.com/acmesh-official/acme.sh/issues

@kiokoman Thank you!

The problem was that in my backend I wrote "localhost" instead of "127.0.0.1" as you. Fixing that it works!

@johnpoz yes it works well now, although the UI is well hidden. I had to click another tiny button to show the full settings for this DNS-Infomaniak, as you said it's not so intuitive but now that it works I won't touch it ever again so...
Thanks for your help!

@liangmicha feature request created https://redmine.pfsense.org/issues/11163

@amarand said in ACME with Siteground:

Is that not a feature that Let's Encrypt supports?

Your quiet close.
It's :
@gertjan said in ACME with Siteground:

The TXT filed will contain a challenge code to be put into the TXT field. This code is give to the acme script by Letsensrypt. For example : 'bmDWOCHFZRtOOCr_vU-mEfTIqA6i9ib0R3V6-RMF3FE'.

This bmD....................RMF3FE thing is generated randomly, and will be unique for every certificate request.
This proofs that you control right now - and not some time X in the past.
Note that, ones this test passed, it stays valid for one week.

@Gertjan thanks a lot!

The last paragraph about the '/etc/hosts' workaround in pfSense was incorrect; I forgot that '/etc/hosts' gets wiped periodically by pfSense. The real workaround is below:

If you have set the pfSense system-wide DNS servers to use OpenDNS/NextDNS/etc. and don't wish to change these in each individual DHCP range assignment, you can simply add 'Allowlist' entries for dns.google and cloudflare-dns.com in the web console for your DNS provider ('Allowlist' may be called something else but that is what NextDNS calls it). This will allow DNS validation to succeed for ACME. If you are concerned about clients circumventing your DNS provider due to whitelisting the Google and Cloudflare DNS names, you can always redirect all DNS traffic on your LAN to make sure it goes through your DNS provider:
https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.html

@jimp Indeed, the SAN addition works now. However, I'm still hoping to figure out why my second server doesn't create correct certificates. I have now removed the certificates and CA, but I ran into the LE rate limiting, so I'll try again later.

The last line shows the issue :

@fmohcine26 said in I did not pass Renewing certificate:

Error creating new order :: too many failed authorizations recently: see https://letsencrypt.org/docs/rate-limits/

Click and read the link.

0.6.9_2 Fixed my problem! Thanks for such a fast turn around!