Unable To Renew Certs Since last ACME package Update

jimp

If that's also on CloudFlare it may be a different issue.

The one the update had a fix for is https://github.com/acmesh-official/acme.sh/issues/2888

costanzo

@raiderj said in Unable To Renew Certs Since last ACME package Update:

One for the wildcard cert, one for the regular cert. But they're both looking for the same key valu

Odd. Can you post a screen capture of the message show when issuing the cert. Be sure to blur out any sensitive data. I am not seeing this issue, but may be different for you.

Also, keep in mind generating too many certs under production will cap you out and you will need to wait a week. Best to use the staging option.

raiderj

@costanzo said in Unable To Renew Certs Since last ACME package Update:

@raiderj said in Unable To Renew Certs Since last ACME package Update:

One for the wildcard cert, one for the regular cert. But they're both looking for the same key valu

Odd. Can you post a screen capture of the message show when issuing the cert. Be sure to blur out any sensitive data. I am not seeing this issue, but may be different for you.

Also, keep in mind generating too many certs under production will cap you out and you will need to wait a week. Best to use the staging option.

I'll do that if I see it again. I can't replicate the issue at the moment. The only issue I have now, with both staging and production is that the second domain in the SAN list won't get an updated cert. Haven't tried switching to the DNS-Cloudflare option though.

costanzo

@jimp Thanks for the quick turn around! I can confirmed this also fixed it for me. I tested the cert gen using the staging.

raiderj

@raiderj said in Unable To Renew Certs Since last ACME package Update:

@costanzo said in Unable To Renew Certs Since last ACME package Update:

@raiderj said in Unable To Renew Certs Since last ACME package Update:

One for the wildcard cert, one for the regular cert. But they're both looking for the same key valu

Odd. Can you post a screen capture of the message show when issuing the cert. Be sure to blur out any sensitive data. I am not seeing this issue, but may be different for you.

Also, keep in mind generating too many certs under production will cap you out and you will need to wait a week. Best to use the staging option.

I'll do that if I see it again. I can't replicate the issue at the moment. The only issue I have now, with both staging and production is that the second domain in the SAN list won't get an updated cert. Haven't tried switching to the DNS-Cloudflare option though.

Ok, I believe it's working now with the original "DNS-Cloudflare" option. I think I can also remove the new API token I created as well. So, if I'm understanding this properly, all I need for cert generation is the global API key from Cloudflare.

Wildcard plus normal cert generation in the same request seems to still not work. I still only get the first domain in the SAN list.

asche

I'll hitch onto this, but my error seems a bit different:

running ACME with DNS challenge
using Cloudflare
DNS challenge seems to be working and certificate to be issued
but automatic renewal fails (as per pfsense email notification)

Manual renewal runs into the following issues: XMLRPC errors

pfsense error message (my domain masked with FQDN):

[...]
[Sun Jun  7 10:48:57 CEST 2020] Your cert is in  /tmp/acme/FQDN//*.FQDN/*.FQDN.cer 
[Sun Jun  7 10:48:57 CEST 2020] Your cert key is in  /tmp/acme/FQDN//*.FQDN/*.FQDN.key 
[Sun Jun  7 10:48:57 CEST 2020] The intermediate CA cert is in  /tmp/acme/FQDN//*.FQDN/ca.cer 
[Sun Jun  7 10:48:57 CEST 2020] And the full chain certs is there:  /tmp/acme/FQDN//*.FQDN/fullchain.cer 
[Sun Jun  7 10:48:57 CEST 2020] Run reload cmd: /tmp/acme/FQDN/reloadcmd.sh

IMPORT CERT FQDN, /tmp/acme/FQDN/*.FQDN/*.FQDN.key, /tmp/acme/FQDN/*.FQDN/*.FQDN.cer
update cert!
Fatal error: Uncaught XML_RPC2_InvalidUriException: Client URI 'https://admin:@:444/xmlrpc.php' is not valid in /usr/local/share/pear/XML/RPC2/Client.php:167
Stack trace:
#0 /usr/local/share/pear/XML/RPC2/Backend/Php/Client.php(80): XML_RPC2_Client->__construct('https://admin:@...', Array)
#1 /usr/local/share/pear/XML/RPC2/Client.php(238): XML_RPC2_Backend_Php_Client->__construct('https://admin:@...', Array)
#2 /etc/inc/xmlrpc_client.inc(92): XML_RPC2_Client::create('https://admin:@...', Array)
#3 /etc/inc/xmlrpc_client.inc(148): pfsense_xmlrpc_client->xmlrpc_internal('exec_php', 'require_once('s...', 240)
#4 /usr/local/pkg/acme/acme.inc(107): pfsense_xmlrpc_client->xmlrpc_exec_php('require_once('s...')
#5 /usr/local/pkg/acme/acme_command.sh(76): acme_xmlrpc_restart_service('haproxy', 'array (\n)')
#6 {main}
  thrown in /usr/local/share/pear/XML/RPC2/Client.php on line 167
PHP ERROR: Type: 1, File: /usr/local/share/pear/XML/RPC2/Client.php, Line: 167, Message: Uncaught XML_RPC2_InvalidUriException: Client URI 'https://admin:@:444/xmlrpc.php' is not valid in /usr/local/share/pear/XML/RPC2/Client.php:167
Stack trace:
#0 /usr/local/share/pear/XML/RPC2/Backend/Php/Client.php(80): XML_RPC2_Client->__construct('https://admin:@...', Array)
#1 /usr/local/share/pear/XML/RPC2/Client.php(238): XML_RPC2_Backend_Php_Client->__construct('https://admin:@...', Array)
#2 /etc/inc/xmlrpc_client.inc(92): XML_RPC2_Client::create('https://admin:@...', Array)
#3 /etc/inc/xmlrpc_client.inc(148): pfsense_xmlrpc_client->xmlrpc_internal('exec_php', 'require_once('s...', 240)
#4 /usr/local/pkg/acme/acme.inc(107): pfsense_xmlrpc_client->xmlrpc_exec_php('require_once('s...')
#5 /usr/local/pkg/acme/acme_command.sh(76): acme_xmlrpc_restart_service('haproxy', 'array (\n)')
#6 {main}
  thrown[Sun Jun  7 10:49:07 CEST 2020] Reload error for :

Couple of things to note:

Yes, I currently employ HAproxy, and my pfsense port has been changed to :444
NO, I do not use CARP nor sync nor HAProxy Sync (all are off / disabled)
The same error occurs when I disable HAProxy.
it seems that a valid certificate is created and - partly - updated into pfsense, because I can see an updated certificate in the pfsense certificate manager.
pfsense still uses the old (soon-to-expire) certificate, not the renewed one shown in the certificate manager (??)

PiBa

@asche
What 'actions' have you configured on the acme certificate configuration? Perhaps a "Restart Remote Service (XMLRPC)" action?

asche

@PiBa

@PiBa said in Unable To Renew Certs Since last ACME package Update:

@asche
What 'actions' have you configured on the acme certificate configuration? Perhaps a "Restart Remote Service (XMLRPC)" action?

You nailed it -- "Enabled haproxy Restart Remote Service (XMLRPC)"

Should I delete this?

PiBa

@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.