PANOS deploy plugin can't handle wildcard certs

[Jayman007]

I have been using acme with the panos deploy-hook to successfully issue/renew my LE certs and upload them to my Pano firewall. The issue is with wildcard certs. The certs issue fine and I can find them all in
/root/.acme/*.mydomain.com. The issue is with the deploy-hook panos. Pano does not like certs that begin with * and will through an error if you try and push one to it.

[Thu Sep 15 16:49:47 PDT 2022] certificate -> certificate-name '*.mydomain.com' is invalid]]> certificate -> certificate-name is invalid]]>
[Thu Sep 15 16:49:48 PDT 2022] private-key -> name '*.mydomain.com.key' is invalid]]> private-key -> name is invalid]]>

I am stuck with manually renaming the key to something like wildcard.mydomain.com and them manually importing them into the firewall. Obviously I would like to automate this process if possible. Is there a way to have the deploy-hook panos module rename the files from *.mydomain to wildcard.mydomain prior to trying to deploy them? I'm open to other solutions that might work.

[github-actions]

Please upgrade to the latest code and try again first. Maybe it's already fixed. acme.sh --upgrade If it's still not working, please provide the log with --debug 2, otherwise, nobody can help you.

[Jayman007]

Thanks bot. I already updated to the dev version to get namesilo working again.

[sg1888]

I have been using acme with the panos deploy-hook to successfully issue/renew my LE certs and upload them to my Pano firewall. The issue is with wildcard certs. The certs issue fine and I can find them all in /root/.acme/*.mydomain.com. The issue is with the deploy-hook panos. Pano does not like certs that begin with * and will through an error if you try and push one to it.

[Thu Sep 15 16:49:47 PDT 2022] certificate -> certificate-name '.mydomain.com' is invalid]]> certificate -> certificate-name is invalid]]> [Thu Sep 15 16:49:48 PDT 2022] private-key -> name '.mydomain.com.key' is invalid]]> private-key -> name is invalid]]>

I am stuck with manually renaming the key to something like wildcard.mydomain.com and them manually importing them into the firewall. Obviously I would like to automate this process if possible. Is there a way to have the deploy-hook panos module rename the files from *.mydomain to wildcard.mydomain prior to trying to deploy them? I'm open to other solutions that might work.

I just fixed this. Take a look at my pull request. Wildcard certs are now called WILDCARD_.my domain.com on the firewall. I added an underscore to handle edge cases where you have a subdomain called “wildcard”.

[Jayman007]

Thank you for taking the time to fix this. I have updated my acme and yet it still seems to be an issue for me. Forgive my ignorance with Github protocol but has the change you made been incorporated into the latest acme.sh? If not, I can I integrate your fix into my install?

[sg1888]

Thank you for taking the time to fix this. I have updated my acme and yet it still seems to be an issue for me. Forgive my ignorance with Github protocol but has the change you made been incorporated into the latest acme.sh? If not, I can I integrate your fix into my install?

Unfortunately the repo maintainer hasn’t incorporated the changes into the Dev branch yet. To get the updated code you can either pull my forked repo or just overwrite the file panos.sh from the one in my repo.

My fork is here: https://github.com/sg1888/acme.sh/tree/panos-ecc-fix

The panos.sh file is here: https://github.com/sg1888/acme.sh/blob/panos-ecc-fix/deploy/panos.sh

Overwrite the panos.sh file in your deploy folder. Let me know if it works for you.

[Jayman007]

I did as stated above and the script now works perfectly for me. Thank you again for addressing this.

There are a couple other tweaks that I need to make to the panos.sh but I don't have the skills to do it.

1 change is for certificate based login for the api account vs credentials. If that is not doable, then I would like to have the api key generated only the first time the script is run and set that key as a variable that is later reused rather than generating a new api every time the script is run. So basically, it only runs the keygen function when the variable doesn't exist.

The reason for this is that if cert auth is enabled, the keygen function can no longer be run using credentials. Cert auth could be turned off to generate the api key and then turned back on. Then subsequent requests could use the api key rather than trying to regenerate it every time.

[sg1888]

Not sure what you mean by 'cert auth' - is that related to the insecure uploads?

Pull my updated repo for the new code. Keys are now saved to the conf file. Saved keys are also tested on every deployment - if the saved key fails for some reason a new key is generated using the saved credentials. The new key is then saved to the conf file.

Also, pls create a new issue in Github to track this.

[sg1888]

I did as stated above and the script now works perfectly for me. Thank you again for addressing this.

There are a couple other tweaks that I need to make to the panos.sh but I don't have the skills to do it.

1 change is for certificate based login for the api account vs credentials. If that is not doable, then I would like to have the api key generated only the first time the script is run and set that key as a variable that is later reused rather than generating a new api every time the script is run. So basically, it only runs the keygen function when the variable doesn't exist.

The reason for this is that if cert auth is enabled, the keygen function can no longer be run using credentials. Cert auth could be turned off to generate the api key and then turned back on. Then subsequent requests could use the api key rather than trying to regenerate it every time.

I added an optional variable called PANOS_KEY that you can enter as an environment variable. The PANOS_USER and PANOS_PASS variables are still required as they are needed to generate a new key if PANOS_KEY is invalid, missing or expired.

Once a key is generated it is saved as a variable and will be used going forward. The script tests the saved key each time with an empty commit to check if the key is valid, and generates a new key only if needed. I believe this addresses the issue you mentioned.

Please test the code for your use case and let me know if the changes work for you.

[sg1888]

@Jayman007 Please close this issue. It has been resolved in the latest release.