@RyanM said in Sharing wildcard cert internally: Or is there something more automated? It is possible to SSH into pfSense from 'where ever' using 'what ever' doing 'what ever'. Concrete example : I have a desktop PC executing a program that logs in, retrieves the config, and saves it on the PC every day - I found this program on this forum, I didn't make it myself. See the acme package (the manual => the script itself) for details how to retrieve cert details. Typically, the script you write for reach device should run ones a day. It should get the validity date/time of the cert being used on that device. Then it should do a TLS connection to pfSense, port 443. retrieve the cert details, extract the validity date/time. Compare the two, and if the latter is more recent, execute a "files copy" and restart locally the services that are using the newly installed cert. Btw : automating is only possible for those who know how it all 'works'. For those who don't or don't want to know : the manual way : exporting from pfSense and importing else where works also very well. Btw : I copy my acme/pfSense wildcard cert to a couple of local printers on my Syno diskstation every 60 days. Not really needed, I admit.

@viktor_g I will update it as soon as possible.

Also, I gave it 2700 seconds to sleep, albeit the "spinning gear" stops before that and updates the renewal button to a broken link with "issue/renew" ---- Could the system time out before the sleep time is completed?

UPDATE: I have run some tests and by creating symlinks: ln -s ./\*.ImportantDomain1.comnsupdate_acme-challenge._1.OnlyAcmeUpdateDomain.com.key ./\*.ImportantDomain1.comnsupdate_1.OnlyAcmeUpdateDomain.com.key ln -s ./\*.ImportantDomain1.comnsupdate_acme-challenge._1.OnlyAcmeUpdateDomain.com.server ./\*.ImportantDomain1.comnsupdate_1.OnlyAcmeUpdateDomain.com.server ln -s ./ImportantDomain1.comnsupdate_acme-challenge._1.OnlyAcmeUpdateDomain.com.key ./ImportantDomain1.comnsupdate_1.OnlyAcmeUpdateDomain.com.key ln -s ./ImportantDomain1.comnsupdate_acme-challenge._1.OnlyAcmeUpdateDomain.com.server ./ImportantDomain1.comnsupdate_1.OnlyAcmeUpdateDomain.com.server I can successfully receive certificates. Therefore there is a bug in scripts. Could you please let me know where should I report this BUG to be corrected in next version of package?

What is interesting - I can setup and issue a certificate for a new DDNS name, but re-issue for the existing fails ...

Hi there, unfortunately I was not able to resolve the issue and switched to "Standalone HTTP server" method. This works, I would like to use the domain method, but all that I tried, failed. It seams strange to me that only we have this issue, or only we are trying to use this method with FreeDNS. I have another site for example that I can't open the necessary ports for the "Standalone HTTP server" to work. In that case I have to use the domain method. I'm still interested in this working but as nobody else reported an issue I doubt that it will be looked at soon. I hope I'm wrong though.

@karlisp said in Copy certificate to remote server: but cant seem to find how to generate private and public ssh key that will be used to communication between firewall and server Strange Because that one is also needed to access pfSense using it's SSH access. The ssh password method is meant to be used only ones, to be forbidden afterwards, with : [image: 1597243965394-371e3693-64a5-4bc7-8f69-0c7905ea0b6d-image.png] See the pfsense manual, or about a million other sources on the net about how to create them, where what to place what etc. This info is valid for everything that is accessible with "ssh". Use a tool of your choice to create a (the) key(s) and cut and pasted it here : [image: 1597244940603-a751ab92-5a7a-4a3f-afcc-2002aaa12d16-image.png] ( the admin user settings of pfSense, at the bottom of the page ) About the scripts : many have already made something up, using some shell script. So many OS's exists, like the desktop ones, and OS's for devises likes printers, NAS's etc etc etc. It boils down as copying a file often the network - putting the file 'on the right place' - and signalling / restarting the services that uses these files == the new certs. For myself : when acme did it's job, every 60 days, I receive a mail. I added to the bottom of the mail : "As an admin, do your jobs, and extract these 2 files from pfSense, to put them in the 2 NAS's et 2 network printers." Not a bad thing, actually, as it takes 5 minutes, and I'm paid to do ^^ I have a "root" access for my Syno NAS's, but I do not have such a ssh access for the printers, so the GUI way is the only way anyway.

I have narrowed down the problem. I switched to a staging certificate and renewed one domain and it worked. I added a second domain and it won't work. I removed the first domain, left the second, and it worked. Seems to be a problem with multi-domain certificates. Edit: All domains renew with the staging account, but won't renew on the production account. Possible I may have to wait a few days or a week for my rate limit to clear

@Gertjan Hmm. I desabled my "HTTP to HTTPS" NAT rule (created as in the video i posted), and it worked. LE_Root_Cert Renewing certificate account: LE_Cert server: letsencrypt-staging-2 /usr/local/pkg/acme/acme.sh --issue -d '*.XXX.top' --dns 'dns_namesilo' --home '/tmp/acme/LE_Root_Cert/' --accountconf '/tmp/acme/LE_Root_Cert/accountconf.conf' --force --reloadCmd '/tmp/acme/LE_Root_Cert/reloadcmd.sh' --log-level 3 --log '/tmp/acme/LE_Root_Cert/acme_issuecert.log' Array ( [path] => /etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin/ [PATH] => /etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin/ [Namesilo_Key] => 74XXXX30 ) [Fri Jul 17 18:21:16 CEST 2020] Single domain='*.XXX.top' [Fri Jul 17 18:21:16 CEST 2020] Getting domain auth token for each domain [Fri Jul 17 18:21:18 CEST 2020] Getting webroot for domain='*.XXX.top' [Fri Jul 17 18:21:18 CEST 2020] Adding txt value: GXCXXXtQY for domain: _acme-challenge.XXX.top [Fri Jul 17 18:21:20 CEST 2020] Successfully added TXT record, ready for validation. [Fri Jul 17 18:21:20 CEST 2020] The txt record is added: Success. [Fri Jul 17 18:21:20 CEST 2020] Let's check each dns records now. Sleep 20 seconds first. [Fri Jul 17 18:21:40 CEST 2020] Checking XXX.top for _acme-challenge.XXX.top [Fri Jul 17 18:21:41 CEST 2020] Domain XXX.top '_acme-challenge.XXX.top' success. [Fri Jul 17 18:21:41 CEST 2020] All success, let's return [Fri Jul 17 18:21:41 CEST 2020] Verifying: *.XXX.top [Fri Jul 17 18:21:44 CEST 2020] Success [Fri Jul 17 18:21:44 CEST 2020] Removing DNS records. [Fri Jul 17 18:21:44 CEST 2020] Removing txt: GXXXXQY for domain: _acme-challenge.XXX.top [Fri Jul 17 18:21:46 CEST 2020] Successfully retrieved the record id for ACME challenge. [Fri Jul 17 18:21:47 CEST 2020] Successfully removed the TXT record. [Fri Jul 17 18:21:47 CEST 2020] Removed: Success [Fri Jul 17 18:21:47 CEST 2020] Verify finished, start to sign. [Fri Jul 17 18:21:47 CEST 2020] Lets finalize the order, Le_OrderFinalize: https://acme-staging-v02.api.letsencrypt.org/acme/finalize/14XXX77 [Fri Jul 17 18:21:48 CEST 2020] Download cert, Le_LinkCert: https://acme-staging-v02.api.letsencrypt.org/acme/cert/faXXXdc [Fri Jul 17 18:21:49 CEST 2020] Cert success. -----BEGIN CERTIFICATE----- MIIXXX XXXX XXXXM4s= -----END CERTIFICATE----- [Fri Jul 17 18:21:49 CEST 2020] Your cert is in /tmp/acme/LE_Root_Cert//*.XXX.top/*.XXX.top.cer [Fri Jul 17 18:21:49 CEST 2020] Your cert key is in /tmp/acme/LE_Root_Cert//*.XXX.top/*.XXX.top.key [Fri Jul 17 18:21:49 CEST 2020] The intermediate CA cert is in /tmp/acme/LE_Root_Cert//*.XXX.top/ca.cer [Fri Jul 17 18:21:49 CEST 2020] And the full chain certs is there: /tmp/acme/LE_Root_Cert//*.XXX.top/fullchain.cer [Fri Jul 17 18:21:49 CEST 2020] Run reload cmd: /tmp/acme/LE_Root_Cert/reloadcmd.sh IMPORT CERT LE_Root_Cert, /tmp/acme/LE_Root_Cert/*.XXX.top/*.XXX.top.key, /tmp/acme/LE_Root_Cert/*.XXX.top/*.XXX.top.cer update cert![Fri Jul 17 18:21:49 CEST 2020] Reload success However, I changed from staging to production, and it did not work. Same as before

Hetzner : it could be as easy as coping this file https://github.com/acmesh-official/acme.sh/blob/master/dnsapi/dns_hetzner.sh into /usr/local/pkg/acme/dnsapi/ , with all the other dns_ files. Because you use Hetzner, you know all about how Hetzner works. Something special can be seen at the top 4 lines of the file : #!/usr/bin/env sh # #HETZNER_Token="sdfsdfsdfljlbjkljlkjsdfoiwje" # This means : obtain the token from Hetzner, and place it in the file. And you remove the leading '#'.

No complicated terms are needed. Try this no-i p acme ** You find your answer on the very first link. The article is filled with the words 'purchase' here, 'purchase' there and you'll ask : where is the acme term. Knowing that a script called acme could be used to get certs from LetsenScrypt. So, take the second link :Let’s Encrypt Certificate with DNS verification with No-IP and read on ... the answer is at the end. Remove "-ip" to leave you with "no". Btw : if no-ip could be used with Letsenncrypt cert (renewal) they would have stated that as a huge advantage - right at the top of their support/faq/manual.

Nothing changed on their side. Neither acme, recently. Time to check the acme log, see if it really creates / updates the TXT record ?!

If you want to access via IP and not have your browser scream at you.. Just create your own certs using local CA you can create on pfsense. Then trust that.. That is what I do.. So I can access pfsense with its fqdn sg4860.local.lan or its IP.. or even the old name I use to use pfsense.local.lan [image: 1591622337124-ownca.jpg] And since created before they started changing the max life, mine are good for 10 years ;)

@asche said in Unable To Renew Certs Since last ACME package Update: NO, I do not use CARP nor sync nor HAProxy Sync (all are off / disabled) If you dont sync to anywhere, then you probably don't have anything to restart 'remotely', so yes delete that action. You might want to restart the local haproxy service and webgui though. Use the example "shell command" options for that.

This : [image: 1590676949534-8b9ee9dd-7485-4377-94cf-6d9dcf35c229-image.png] is the Let'senscrypt' intermediate certificat, not the certificate you received from Letsenscrypt. When you inspect the sit's (pfSense) cert with a normal browser like FF, you'll see the 3 of them : [image: 1590677099494-0ebbb6d7-b950-415a-9e97-965374ce960b-image.png] Yours is the most left one. Like mine : 4096 .... But hey, even 2048 will do for decades ...... although you have to trach it after 90 days max. edit : also .... the details of the cert you showed last for some 15 months .... that's not the 90 days max duration Letsencrypt is advertising with ;)

@PiBa I believe that the reference to the cert was valid. If memory serves me correctly, there were validation problems with the acme-challenge or missing txn parameters for acme's Domain SAN list / DNS-[provider] method. Perhaps that caused an empty cert file. The ^M remains as before, and now Let's Encrypt successfully verifies the domain.

@jimp Easy, thx!

Finally got time to go back to the certificates and I can confirm that the latest update has fixed my issue. Thanks much appreciated.

If you are on 2.4.4-p3, then 0.6.5 is the latest version you can safely install. You must upgrade to 2.4.5 to get the latest packages. Installing 2.4.5 packages on 2.4.4-p3 is dangerous.

The issue was definitely with ZoneEdit. I re-edited the nameservers in ZoneEdit, saved, and after a while Quad9 and Cloudflare DNS servers were serving up HE's nameservers.