I fixed the text and added some links to the rate limit pages. Thanks!

@jimp, that solved it. Thanks for the quick solution.

Strange that a test cert with Buypass explicitly mentioned not being in the supported 'prime256 ' after creating a 256bit curve setting then 🤔
I have to test again it seems!

Similary happens to me time ago with duckdns and wildcar certificate, i really no worry any more about it... i receive the certificate so all is well.. i will check on the next and last renew...

Do it even easier:

Run acme package on FW1 (I assume it's a CARP cluster with syncing?) and let it create a certificate for both names (fw1.xxx AND fw2.xxx). When it's done, select the cert for the webui. Then login to FW2 and select it, too, as certificates get synchronized automatically (if selected) to the secondary. There choose the same certificate as WebUI cert and be done :)

Just check that you configure the acme service on fw1 to restart its own webserver after renewal AND via remote the service on fw2 (see the help for this)!

Greets

If you update to the latest version of the ACME package, the patch is included. You will no longer need that max_input_vars workaround.

Hi guys

Apologies, it appears to have been a transient error. Put all of the information in the same fields later in the day and it generated the certificates fine.

0_1550629984785_acme Config.png

Well we all have our own opinions.
For me it is simpler:

I don`t need special settings I don`t need any scripts I can do it out of the box Didn`t fail once (except long times because of acme.sh bug)

If netgate can include that script and integrate it, that would be cool :)

HAProxy wouldn't have anything to do with DNS-Manual. Maybe you mean standalone mode? Nothing else would conflict with HAProxy.

If you want to use ACME and HAProxy there are much better ways to integrate them, like https://forum.netgate.com/post/677786 -- that uses webroot instead of standalone and requires no special actions once it's setup.

@gertjan
Yes, I know the requirement to demand a wild car certificate domaine.tld

.domaine.tld, but I am detecting many errors, on the other hand, I am not planning using my base domain at this time to publish and protect some services using my base domain name.
I read about the alias mode, added to my dns _acme-challenge IN CNAME _acme-challenge.b1c54cu.duckdns.org.

bicsa.co.cu
_acme-challenge IN CNAME _acme-challenge.b1c54c0cu.duckdns.org.

ibicsa.co.cu
_acme-challenge IN CNAME _acme-challenge.ib1c54c0cu.duckdns.org.
these domains under duckdns.org exist ... but I am detecting these errors, when I request a wildcard certificate for domaine.tld, * .domaine.tld / *. domaine.tld, so if a certificate for * .domaine.tld covers My hosts under * .domaine.tld alone (no base domain) they are fine, it works for me,
but in this case I get the certificate for * .domaine.tld fine! hurra! but in the end I see the error:
@gertjan
Yes, I know the requirement to demand a wild car certificate domaine.tld

.domaine.tld, but I am detecting many errors, on the other hand, I am not planning using my base domain at this time to publish and protect some services using my base domain name.
I read about the alias mode, added to my dns _acme-challenge IN CNAME _acme-challenge.b1c54cu.duckdns.org.

bicsa.co.cu
_acme-challenge IN CNAME _acme-challenge.b1c54c0cu.duckdns.org.

ibicsa.co.cu
_acme-challenge IN CNAME _acme-challenge.ib1c54c0cu.duckdns.org.
these domains under duckdns.org exist ... but I am detecting these errors, when I request a wildcard certificate for domaine.tld, * .domaine.tld / *. domaine.tld, so if a certificate for * .domaine.tld covers My hosts under * .domaine.tld alone (no base domain) they are fine, it works for me,
but in this case I get the certificate for * .domaine.tld fine! hurra! but in the end I see the error:
[Thu, 7 February 10:58:35 CST 2019] Failed to extract the domain.
[Thu, 7 February 10:58:35 CST 2019] Error rm webroot api for the domain: dns_duckdns
related in the other post
https://forum.netgate.com/topic/140381/error-rm-webroot-api-for-domain-dns_duckdns
You tell me that the error is an error or error in aceme.sh?
the error described for you, I see that error before in some test "netnsupdate.key is illegible"
related in the other post
https: //forum.netgate.com/topic/140381/error-rm-webroot-api-for-domain-dns_duckdns.
You tell me that the error is an error or error in aceme.sh? si u or some developer most repair the problem.
I've seen the error described for you, many times read read change, compare etc but nothing, by now get a *.mydomain.net without base domain is my solution.
What I can do?
thanks

@luisenrique said in /usr/local/pkg/acme/acme_command.sh importcert:

thus removing headaches using third-party scripts

The acme package could be considered as a third party script
Ok, true, it has been developed by someone who happens to know pfSense pretty well.

The thing is : the acme package is build own the existent acme freebsd package, and a boatload of GUI and other glue ware. If @jimp decides to remodel the package, your 'solution' will be broken.

I advise you to use parts of the present (acme) code to make your own "insert cert" script.

Btw : check out the code (acme.inc) : the cert should exists already :

($cert['descr'] == $certificatename)

thus the cert description / name should already exists, and then it's updated.

@netgate-james said in Strange things happening in ACME standalone server validation:

/tmp/acme/ACME-HUPER-STAGE/acme_issuecert.log

[Sat Feb 2 23:26:34 +08 2019] response='{"type":"urn:ietf:params:acme:error:malformed","detail":"Unable to update challenge :: authorization must be pending","status": 400}' [Sat Feb 2 23:26:34 +08 2019] code='400'

@chudak said in Last time updated?:

Everything worked perfectly, CA renewed.

So you're good !

The acme package is not related to the firewall (rules) what so ever. That's up to you.

great work as always :)

@apundir said in Certificate with multiple SAN from two different DNS accounts result in failure:

Can I contribute to nsupdate script as patch? I do understand we'll have to store different key/secret under different keys and use them contextually in every DNS operation. I did look into Submitting a Pull Request via Github page and did browse pfSense/FreeBSD-ports on github but couldn't find acme there. Looks like I am looking into wrong place. Can you please point me in right direction so that I am able to contribute back in case I am able to fix it?

Not sure I follow what you are saying about nsupdate. The changes to nsupdate work fine, but they are specific to how the pfSense ACME package calls nsupdate and thus aren't a good candidate to submit upstream back into acme.sh.

If you are talking about changing the GoDaddy script in a similar way, then you can submit a PR to us for that. The files are under https://github.com/pfsense/FreeBSD-ports/tree/devel/security/pfSense-pkg-acme and the GoDaddy script specifically is at https://github.com/pfsense/FreeBSD-ports/blob/devel/security/pfSense-pkg-acme/files/usr/local/pkg/acme/dnsapi/dns_gd.sh