@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.
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.
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).
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.
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.
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.
@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!
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.
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:
@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.
We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.
Subscribe to our Newsletter
Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.