ACME pkg v0.7.4

kapranos

Thank you @jimp apprecite your support, will update as soon appears (not yet on 23.05) Captura de pantalla 2023-06-09 a las 23.22.31.png

johnpoz

@jimp said in ACME pkg v0.7.4:

RSA or ECC key?

Private key is set for 256bit ECDSA, I don't have any set for RCA any more.

JeGr

@jimp At first big thanks for updating the package.

Still get a bit of a problem with multiple SAN domains though as discussed in another topic as with the current parameter set, acme.sh still creates multiple TXT entries for DNS validation instead of one for multiple domains for the same certificate. And quite a few of providers have API limitations, that will trigger and stop the cert from going through the first time (so acme has to try and try again until it finishes eventually with more and more domains skipped because of already being checked).

Is there anything we could do about helping that? :)

Cheers
\jens

jmanes

Hey all, hope I'm on the right path here. I took this update and renewed my existing cert just fine. Went to create a new one today for a different domain name and got the following error. I tried EDCSA-256 and RSA-4096:

Personal-Index
Renewing certificate 
account: Personal-Index 
server: letsencrypt-production-2 

Fatal error: Uncaught TypeError: openssl_pkey_get_details(): Argument #1 ($key) must be of type OpenSSLAsymmetricKey, bool given in /usr/local/pkg/acme/acme.inc:1732
Stack trace:
#0 /usr/local/pkg/acme/acme.inc(1732): openssl_pkey_get_details(false)
#1 /usr/local/pkg/acme/acme.inc(1884): pfsense_pkg\acme\getCertificatePSK('https://acme-v0...', Array, '--obfuscated-for-forum-post--')
#2 /usr/local/www/acme/acme_certificates.php(69): pfsense_pkg\acme\issue_certificate('Personal-Index', true, true)
#3 {main}
  thrown in /usr/local/pkg/acme/acme.inc on line 1732
PHP ERROR: Type: 1, File: /usr/local/pkg/acme/acme.inc, Line: 1732, Message: Uncaught TypeError: openssl_pkey_get_details(): Argument #1 ($key) must be of type OpenSSLAsymmetricKey, bool given in /usr/local/pkg/acme/acme.inc:1732
Stack trace:
#0 /usr/local/pkg/acme/acme.inc(1732): openssl_pkey_get_details(false)
#1 /usr/local/pkg/acme/acme.inc(1884): pfsense_pkg\acme\getCertificatePSK('https://acme-v0...', Array, '--obfuscated-for-forum-post--')
#2 /usr/local/www/acme/acme_certificates.php(69): pfsense_pkg\acme\issue_certificate('Personal-Index', true, true)
#3 {main}
  thrown

jmanes

@jmanes Thought I'd follow up. I think this might be a bug elsewhere in pfSense as well. If renewing a cert fails, you have to rename the cert to something unique to try again. Alternatively, you have to delete the cert config for acme, then go to the system certs and delete it from there, then go back to the acme page and re-create the cert from scratch with your preferred name.

I dug into the PHP source code a bit and it seems the $cert['prv'] comes back as blank in this error case, and there is no check to verify this in the code: https://github.com/pfsense/FreeBSD-ports/commit/0a473e5f95748e58559aab107e8cd11e30c3e0b0#diff-eeb7356791b2ebd92a27afe3e87af51589f3faa347489e825761b7c132b6ec4eR1731

I didn't get much further than this, as I discovered a workaround and needed to get this working.

IonutIT

@jmanes
Hi, currently facing the exact same issue. My existing certificate failed to automatically renew, tried to renew it manually and got this:

Fatal error: Uncaught TypeError: openssl_pkey_get_details(): Argument #1 ($key) must be of type OpenSSLAsymmetricKey, bool given in /usr/local/pkg/acme/acme.inc:1732
Stack trace:
#0 /usr/local/pkg/acme/acme.inc(1732): openssl_pkey_get_details(false)
#1 /usr/local/pkg/acme/acme.inc(1884): pfsense_pkg\acme\getCertificatePSK('https://acme-st...', Array, 'pfsense.<domain>...')
#2 /usr/local/www/acme/acme_certificates.php(61): pfsense_pkg\acme\issue_certificate('pfsense.<domain>...', true)
#3 {main}
  thrown in /usr/local/pkg/acme/acme.inc on line 1732
PHP ERROR: Type: 1, File: /usr/local/pkg/acme/acme.inc, Line: 1732, Message: Uncaught TypeError: openssl_pkey_get_details(): Argument #1 ($key) must be of type OpenSSLAsymmetricKey, bool given in /usr/local/pkg/acme/acme.inc:1732
Stack trace:
#0 /usr/local/pkg/acme/acme.inc(1732): openssl_pkey_get_details(false)
#1 /usr/local/pkg/acme/acme.inc(1884): pfsense_pkg\acme\getCertificatePSK('https://acme-st...', Array, 'pfsense.<domain>...')
#2 /usr/local/www/acme/acme_certificates.php(61): pfsense_pkg\acme\issue_certificate('pfsense.<domain>...', true)
#3 {main}
  thrown

Unfortunately, I've tried to clear all ACME config, cleared all ACME certificates and Root CA from Certificate Manager, uninstalled ACME, reinstalled, reconfigured everythign from scratch and I got the same result.

What's going on?

jmanes

@IonutIT Odd. Deleting the entire acme config and then deleting all of the certs / private keys that were generated from Acme in the System > Cert Manager > Certificates section worked for me. I did not have to re-install acme or anything like this.

From my experience, as soon as the renewal fails once the entire setup is hosed. You have to go through this process every time a renewal fails. I wish I could be of more help but I'd need to dig into the source code and figure out how acme works. I do not have time to do this at the moment.

IonutIT

@jmanes

One question, how did you delete the acme config? I just deleted all certificate entries and authorisation keys. Is there another way to clear out everything?

johnpoz

@jmanes I use to run into issues some time ago where renews would fail, etc. Had to do with the dns-sleep I changed mine to 180 and haven't had any issues since. I use dns with cloudflare for the certs I have acme do.

jmanes

@IonutIT I had to delete the configs from Services > Acme Certificates > Certificates first. Only the ones effected. Then go to the System certs and wipe them out there. Then go back to System > Acme Certificates > Certificates and create a brand new config and ensure it worked right on the first attempt.

@johnpoz Just proposed a potential solution though so I'd try their DNS sleep config first. I'll do it on my end as well.

jrey

@johnpoz

Yes, exactly this. I noticed in the log the if the secondaries were slow to update and the field for DNS-Sleep is empty, it seems to only try about 10 times with little delay between each attempt and then just stops. This would seem to be different than the expectation stated: "The default behavior is to automatically poll public DNS servers for the records until they are found, rather than waiting a set amount of time."

Having entered a set amount of time, has worked every time with no issue.

It's been a while since I changed this setting and what I can't remember is if I rebooted, (assuming the script was hung, when field was empty) or not. I seem to recall that I did reboot, then entered a sleep value and haven't looked back. Has successfully updated the cert every time since the value was added.

JR